Durante mucho tiempo, la única forma seria de automatizar Dynatrace era la API REST. Construías tus scripts en Python, manejabas la autenticación con tokens, la paginación, los reintentos… todo a mano. Funciona. De hecho, sigue siendo la base de muchas automatizaciones productivas.
Pero en los últimos meses el ecosistema ha cambiado notablemente. Dynatrace ha publicado dos herramientas que abren un mundo de posibilidades nuevas: el servidor MCP oficial para conectar agentes de IA, y dtctl, una CLI inspirada en kubectl para operar la plataforma desde el terminal.
Este artículo no descarta nada. La API REST sigue siendo indispensable. Pero ahora tienes tres opciones encima de la mesa, y elegir bien entre ellas —o combinarlas— marca la diferencia entre remendar scripts y construir automatizaciones que de verdad escalan.
1. La época de la API REST
Si llevas tiempo con Dynatrace, todo esto te sonará familiar. Para obtener la lista de hosts, llamas a /api/v2/entities con entitySelector=type(HOST). Para los problemas activos, /api/v2/problems. Para las vulnerabilidades, /api/v2/securityProblems.
El patrón es siempre el mismo: construyes la URL, añades el token en la cabecera Authorization, manejas la paginación con nextPageKey, procesas el JSON que te devuelve. Repites para cada endpoint que necesites.
Ventajas reales:
- Máxima flexibilidad — cualquier endpoint de la plataforma es accesible
- Compatible con cualquier entorno, incluyendo Dynatrace Managed on-premises
- Sin dependencias externas — Python y
requestsson suficientes - Control total sobre qué se lee y qué se escribe
Limitaciones:
- Hay que conocer la documentación de cada endpoint y sus parámetros
- La gestión de errores, reintentos y paginación va por cuenta del desarrollador
- Para un agente de IA, consumir directamente la API implica mucha fricción: descubrir endpoints, construir payloads, manejar la autenticación…
Un ejemplo típico en Python de lo que hacemos con la API:
import requests
url = "https://mi-entorno.live.dynatrace.com/api/v2/problems"
headers = {"Authorization": f"Api-Token {TOKEN}"}
params = {"problemSelector": "status(OPEN)", "pageSize": 50}
resp = requests.get(url, headers=headers, params=params)
problemas = resp.json()["problems"]
Este código funciona perfectamente. La pregunta ahora es: ¿siempre tiene que ser así de manual?
2. MCP: el protocolo que habla el idioma de los agentes
¿Qué es MCP?
MCP (Model Context Protocol) es un estándar abierto publicado por Anthropic en 2024 que define cómo los agentes de IA interactúan con herramientas externas. La analogía que usa Dynatrace es bastante buena: MCP es a la IA lo que HTTP es a la web.
Sin MCP, cada agente de IA tenía que aprender a hablar con cada herramienta de forma distinta. Con MCP, se define un esquema común: el servidor declara qué herramientas ofrece, con qué parámetros, y el agente puede descubrirlas y usarlas sin documentación adicional.
La idea es elegante: en lugar de que el agente construya llamadas HTTP a mano, el servidor MCP expone herramientas de alto nivel. El agente dice «investiga el problema P-12345» y el servidor MCP sabe qué llamadas hacer internamente.
El servidor MCP oficial de Dynatrace
Dynatrace publicó su servidor MCP en enero de 2026 como parte de Dynatrace Intelligence. Está disponible en GitHub (dynatrace-oss/dynatrace-mcp) y soporta los siguientes casos de uso desde el primer día:
- Generar y ejecutar queries DQL con lenguaje natural
- Explicar una query DQL existente
- Investigar problemas activos y obtener análisis de causa raíz
- Analizar vulnerabilidades de seguridad
- Revisar eventos de Kubernetes
- Hacer forecasting y análisis de series temporales
- Buscar documentación y guías de resolución
- Resolver nombres e IDs de entidades
La integración funciona con los MCP clients más usados del mercado: GitHub Copilot en VS Code, Claude Desktop, Cursor, Amazon Kiro, Windsurf… Básicamente, cualquier herramienta que soporte MCP puede conectarse a Dynatrace con unos minutos de configuración.
Casos de uso prácticos con MCP
| Caso de uso | Lo que le pides al agente | Lo que hace el MCP server |
|---|---|---|
| Investigar un problema | «¿Qué ha pasado en producción en la última hora?» | Consulta problemas activos, extrae root cause y blast radius |
| Escribir una query DQL | «Dame los errores HTTP 5xx de los últimos 30 min» | Genera, valida y ejecuta la query DQL. Devuelve resultados. |
| Analizar vulnerabilidades | «¿Hay CVEs críticos sin remediar?» | Consulta Security Problems API y resume el estado |
| Revisar Kubernetes | «¿Hay pods con OOMKilled esta mañana?» | Analiza eventos K8s y los correlaciona con problemas activos |
| Forecasting | «¿Cuándo voy a agotar el disco en este servidor?» | Analiza time series y proyecta la tendencia |
Lo que hace especialmente interesante el MCP de Dynatrace es la combinación con Grail y Smartscape. El agente no solo ejecuta queries: accede a datos con contexto completo de dependencias, topología y causa raíz. No son respuestas genéricas, son respuestas fundamentadas en el modelo de datos de tu entorno real.
Configuración básica del MCP server
Para entornos SaaS, la configuración en VS Code es tan sencilla como crear un fichero .vscode/mcp.json con esto:
{
"servers": {
"dynatrace-mcp": {
"url": "https://{tenant}.apps.dynatrace.com/platform-reserved/mcp-gateway/v0.1/servers/dynatrace-mcp/mcp",
"headers": {
"Authorization": "Bearer TU_TOKEN"
}
}
}
}
Para Dynatrace Managed existe también dynatrace-managed-mcp-server, un paquete npm de la comunidad oficial (dynatrace-oss) que permite conectar entornos on-premises. La configuración es similar pero apunta a la URL del servidor Managed.
MCP vs. el asistente Davis AI que ya viene en Dynatrace
Esta es una pregunta que aparece siempre: si Dynatrace ya tiene Davis AI y Dynatrace Assist integrados en la interfaz web, ¿para qué necesito el MCP server?
La diferencia es de contexto y de flujo de trabajo. Davis AI y Dynatrace Assist trabajan dentro del portal de Dynatrace: tú abres el navegador, vas a la plataforma, y preguntas ahí. Es útil, pero te obliga a cambiar de contexto.
El MCP server lleva Dynatrace a donde ya estás trabajando: tu IDE, tu terminal, tu cliente de chat, tu pipeline de n8n. No tienes que ir a Dynatrace; Dynatrace viene a ti. Y el agente puede combinar datos de Dynatrace con datos de otras fuentes (Git, Jira, Slack…) en el mismo flujo de trabajo.
3. dtctl: el kubectl de Dynatrace
¿Qué es dtctl?
dtctl (Dynatrace control) es una CLI open-source publicada por el equipo de Dynatrace en marzo de 2026. Está escrita en Go, tiene licencia Apache 2.0 y su inspiración directa es kubectl. Si sabes usar kubectl o git, ya sabes por dónde van los tiros.
La sintaxis es siempre verbo + recurso:
dtctl get workflows # listar workflows
dtctl get workflows --watch # monitorización en tiempo real
dtctl edit dashboard "Production Overview" # editar en $EDITOR
dtctl query "fetch logs | limit 10" # ejecutar DQL
dtctl apply -f workflow.yaml # aplicar configuración
dtctl diff -f workflow.yaml # comparar local vs remoto
dtctl doctor # verificar conexión y permisos
No es un reemplazo de la API ni del MCP. Es una capa más cómoda encima, diseñada para dos perfiles: el ingeniero que prefiere el terminal, y los agentes de IA que necesitan ejecutar comandos con mínimo overhead.
¿Por qué una CLI en lugar de seguir con la API?
La respuesta tiene que ver con el overhead de cada capa. Cuando un agente de IA usa MCP, hay un proceso de negociación de esquema en cada llamada: el agente descubre las herramientas disponibles, negocia los parámetros, valida la respuesta. Es necesario cuando quieres control y auditoría. Pero añade tokens y latencia.
La CLI se salta todo eso. Ejecutas un comando, recibes el resultado, actúas. Para bucles de iteración rápida —probar una query, modificar un workflow, verificar un SLO— la CLI es imbatible en velocidad.
Además, dtctl tiene una característica que lo hace especialmente apto para agentes de IA: cuando detecta que se está ejecutando dentro de un contexto automatizado, cambia su formato de salida a JSON estructurado que los agentes pueden parsear directamente, incluyendo sugerencias de próximos pasos y contexto de errores.
Recursos que gestiona dtctl
| Comando | Qué hace |
|---|---|
dtctl get workflows | Lista todos los workflows del entorno |
dtctl get workflows --watch | Monitorización en tiempo real de workflows |
dtctl edit dashboard "Overview" | Abre el dashboard en YAML en tu $EDITOR |
dtctl query "fetch logs | limit 10" | Ejecuta una query DQL directamente |
dtctl apply -f workflow.yaml | Aplica la configuración del fichero (como kubectl apply) |
dtctl diff -f workflow.yaml | Compara el fichero local contra lo que hay en remoto |
dtctl get slos | Lista todos los SLOs del entorno |
dtctl config set-context prod ... | Configura un contexto de entorno (dev/staging/prod) |
dtctl doctor | Verifica que la conexión y los permisos están bien |
Gestión de múltiples entornos
Una de las funcionalidades más útiles de dtctl es la gestión de contextos, directamente inspirada en kubectl. Puedes configurar varios entornos y cambiar entre ellos con un solo comando:
# Configurar entorno de desarrollo
dtctl config set-context dev \
--environment "https://abc12345.apps.dynatrace.com" \
--token-ref dev-token
# Configurar entorno de producción
dtctl config set-context prod \
--environment "https://xyz99999.apps.dynatrace.com" \
--token-ref prod-token
# Cambiar de contexto
dtctl config use-context prod
dtctl get workflows # ahora apunta a producción
dtctl y los agentes de IA: el skill de Copilot y Claude Code
dtctl incluye en el propio repositorio un «skill» para agentes de IA: un conjunto de instrucciones que le enseñan a GitHub Copilot, Claude Code o Cursor cómo usar dtctl correctamente. Se instala copiando la carpeta skills/dtctl al directorio de configuración del agente:
cp -r skills/dtctl ~/.github/skills/ # para GitHub Copilot
cp -r skills/dtctl ~/.claude/skills/ # para Claude Code
Con esto, el agente puede operar tu entorno Dynatrace completo: descubrir workflows, modificar dashboards, ejecutar queries DQL, gestionar SLOs… todo desde el IDE, sin salir del flujo de trabajo de desarrollo.
4. Las tres opciones comparadas
| API REST | MCP | dtctl (CLI) | |
|---|---|---|---|
| ¿Qué es? | Llamadas HTTP directas | Protocolo agente ↔ herramienta con esquema declarado | Binario CLI inspirado en kubectl |
| Ideal para | Endpoints no cubiertos, máxima flexibilidad | Agentes de IA con auditoría y control de acceso | Iteración rápida, scripting, agentes con baja latencia |
| Overhead | Alto: paginación, tokens, reintentos manuales | Medio: negociación de esquema por llamada | Mínimo: ejecución directa |
| Autodescubrimiento | No — documentación manual | Sí — esquema declarado antes de cada llamada | Sí — dtctl describe en runtime |
| Curva de entrada | Alta | Media | Baja |
| Dynatrace Managed | Sí — base de todo lo que ya hacemos | Parcial — versión OSS específica para Managed | Parcial — probar con dtctl doctor |
La clave está en que estas tres opciones no se excluyen. En la práctica, los equipos que mejor aprovechan Dynatrace terminan usando las tres:
- API REST para las automatizaciones con lógica compleja, endpoints no cubiertos por las otras capas, o entornos Managed donde MCP y dtctl tienen soporte limitado
- MCP para dar observabilidad contextual a los agentes de IA que ya usan en el IDE o en plataformas de automatización
- dtctl para operaciones cotidianas desde el terminal, scripts de mantenimiento, y como interfaz de agentes en bucles de iteración rápida
5. ¿Y si usas Dynatrace Managed?
Esta es la pregunta que más cambia el panorama. dtctl y el MCP server oficial de Dynatrace están diseñados principalmente para Dynatrace SaaS (entornos *.apps.dynatrace.com). Muchas de las funcionalidades más potentes —DQL, workflows modernos, dashboards v2— son características de la plataforma SaaS.
Sin embargo, Dynatrace ha publicado también dynatrace-managed-mcp-server, un servidor MCP específico para entornos Managed on-premises. Disponible en GitHub (dynatrace-oss/dynatrace-managed-mcp), permite conectar agentes de IA a entornos self-hosted, aunque con un subconjunto de las funcionalidades disponibles en SaaS.
Para dtctl en Managed, la recomendación es pragmática: instalar el binario, configurar el contexto con la URL del entorno Managed, y ejecutar dtctl doctor para ver exactamente qué responde y qué no. Los recursos que funcionan dependen de qué APIs v2 tenga habilitadas la instalación concreta.
En cualquier caso, si el entorno principal es Managed, la API REST sigue siendo la herramienta más universal y fiable. Las otras dos son un complemento que irá ganando relevancia a medida que Dynatrace unifique su plataforma.
6. Resumiendo
Durante años, automatizar Dynatrace significaba scripts Python contra la API REST. Era —y sigue siendo— un enfoque sólido. Pero el ecosistema ha madurado y ahora hay dos opciones más encima de la mesa que cambian el juego.
El MCP server abre Dynatrace a los agentes de IA de forma estructurada y gobernada: GitHub Copilot en el IDE puede investigar un problema de producción mientras el desarrollador trabaja en el código. Claude Desktop puede analizar vulnerabilidades críticas en lenguaje natural. Todo sin cambiar de contexto.
dtctl lleva la operativa de la plataforma al terminal con la misma ergonomía de kubectl: comandos predecibles, gestión de contextos, watch mode, soporte nativo para automatizaciones. Para quien vive en el terminal o quiere integrar Dynatrace en pipelines de CI/CD, es una herramienta que va a dar mucho juego.
Lo más relevante de todo esto no es ninguna herramienta en particular. Es el cambio de paradigma: Dynatrace está dejando de ser una herramienta que se opera desde su portal web para convertirse en una plataforma que se integra en cualquier flujo de trabajo, con cualquier agente, en cualquier contexto.
Y eso, para quien lleva años construyendo automatizaciones de observabilidad, es un cambio que vale la pena entender bien.
Referencias
- Dynatrace Blog: dtctl — The Dynatrace observability CLI that’s built for AI agents and humans (marzo 2026)
- Dynatrace Docs: Dynatrace MCP server
- Dynatrace Blog: Dynatrace MCP Server — empower your AI assistants (enero 2026)
- GitHub: dynatrace-oss/dtctl
- GitHub: dynatrace-oss/dynatrace-mcp
- GitHub: dynatrace-oss/dynatrace-managed-mcp
