Servidor MCP de Datadog: herramientas, configuración y cómo conectarlo de forma segura

Qué es el servidor MCP de Datadog

ElServidor MCP de Datadoges un servidor remotoModel Context Protocol servidor alojado por Datadog. Expone tu organización como herramientas invocables: un agente solicita registros que coincidan con una consulta, una serie de métricas, una traza por ID o el estado de un monitor, y recibe datos estructurados a cambio.

Está organizado en conjuntos de herramientas que habilitas por conexión, de modo que solo consumes contexto del modelo en la superficie que necesitas. «core» es el valor predeterminado.

La referencia de herramientas de Datadog enumera más de doscientas herramientas; por eso existe el parámetro de conjuntos de herramientas y por eso la sección de delimitación de herramientas que aparece a continuación es importante.

Dado que es remoto y no local, no hay ningún contenedor que ejecutar: apuntas un cliente a una URL y te autenticas, con el mismo formato que los otros servidores MCP remotos que los equipos están estandarizando. Es el servidor MCP de observabilidad al que recurren primero la mayoría de los equipos de plataforma.

Qué hacen realmente los agentes con él

Las llamadas individuales no son lo interesante; get_datadog_metric por sí sola es una interfaz de Datadog peor. El valor aparece cuando las herramientas se encadenan:

• Triaje de incidentes en tiempo real. Se activa un monitor. El agente llama a search_datadog_monitors para conocer la condición de alerta, a get_datadog_metric para ver cuánto superó la señal el umbral, a search_datadog_spans para saber qué latencia de servicio se movió primero y, a continuación, a search_datadog_logs en ese servicio. Un solo turno, cuatro superficies correlacionadas.
• Correlación de despliegues. search_datadog_events para buscar despliegues en la última hora frente a la tasa de error de analyze_datadog_logs, respondiendo a la pregunta «¿causó esto el despliegue de las 14:02?» sin tener que comparar dos gráficos a ojo.
• De la traza a la causa raíz. Toma un ID de traza de un informe de cliente, llama a get_datadog_trace, encuentra el span lento y extrae su plan de explicación de Database Monitoring.
• Redacción de postmortems. get_datadog_incident, search_datadog_logs para el intervalo de tiempo, create_datadog_notebook para escribir la cronología.

La distinción entre lectura y escritura es fundamental. Casi todo lo útil aquí es de lectura. Las herramientas de escritura —crear monitores, actualizar o eliminar paneles, modificar casos, además de las Acciones Remotas y la Ejecución de Código— conforman un conjunto más reducido, pero con un impacto potencial mucho mayor, y TrueFoundry las etiqueta como Destructiva.

Por qué la conexión directa falla a escala de equipo

Que un ingeniero de SRE conecte Datadog a Claude Code durante un turno de guardia es aceptable. Que lo haga todo un departamento de plataforma, no.

Los registros (logs) son la vía de exfiltración y nadie los trata como tal. Este modo de fallo es específico de los servidores de observabilidad y debe ser la prioridad. Los registros de las aplicaciones son el lugar donde los secretos van a morir en silencio: una clave de API en una cabecera de solicitud registrada al completo, una cadena de conexión en una línea de inicio, la dirección de un cliente en un objeto de pedido serializado. Los equipos lo aceptan porque el acceso a los registros está protegido por el RBAC de Datadog, y un humano que busca contraseñas es una variable conocida. Un agente que llama a search_datadog_logs no lo es. Extrae líneas de registro sin procesar al contexto de un modelo, ese contexto puede llegar a un proveedor de inferencia de terceros y puede terminar citado en un resumen de Slack. No se robó ninguna credencial, no se infringió ninguna política; los datos simplemente se movieron a un lugar que nadie había contemplado.

El volumen de consultas conlleva un coste. Los precios de Datadog se basan en el uso y los agentes son expertos en crear bucles. Un agente de incidentes mal configurado puede llamar a search_datadog_logs veinte veces en una sola investigación, ampliando el intervalo en cada ronda. Sin un recuento de llamadas por herramienta, solo te enterarás al recibir la factura. [VERIFICAR: La documentación de Datadog no indica que las llamadas a herramientas MCP se midan por separado; trátalo como una consecuencia de la tarificación por consulta basada en el uso y confírmalo con tu contrato.]

La discrepancia de región genera errores inútiles. Datadog depende de la ubicación, por lo que la URL de MCP y cada punto de conexión OAuth deben apuntar a tu sitio. Si te equivocas en uno, verás un mensaje genérico de “Error de autenticación” sin ninguna referencia al nombre de host.

Falta de atribución cuando más importa. El registro de auditoría de Datadog indica que se ejecutó una consulta, pero no que tu agente de incidentes la ejecutó a partir de una notificación de un webhook de PagerDuty. Durante un análisis post-mortem, el rastro se detiene en un token de API.

Nada de esto es un argumento en contra de conectar Datadog. Es un argumento a favor de contar con un plano de control que lo gestione, que es precisamente lo que un pasarela MCP es.

Want to see this end to end?

Register the Datadog MCP server, disable the write tools, and hand your on-call team a read-only incident agent in one sitting.

Get started free

Conexión del servidor MCP de Datadog a través de TrueFoundry

La configuración de MCP para Datadog no se realiza a través del catálogo gestionado. Se registra mediante Conectar servidores MCP remotos oficiales — servidores previamente validados donde la autenticación está basada en plantillas, pero tú mantienes el control de la conexión. Para Datadog, esa plantilla incluye OAuth2 con PKCE y Registro dinámico de clientes (DCR): TrueFoundry registra el cliente OAuth automáticamente, por lo que no hay ninguna aplicación OAuth que crear.

En el lado de Datadog, necesitas Acceso MCP habilitado en la organización, mcp_read en tu usuario (además de mcp_write para herramientas de escritura) y tu dominio de sitio. Los sitios gubernamentales no son compatibles.

Paso 1: abra el selector.EnServidores MCP, haga clic enAñadir nuevo servidor MCP y selecciona Conectar servidores MCP remotos oficiales.

Paso 2: busca Datadog. Escribe data en la búsqueda del catálogo y haz clic en la tarjeta datadog .

Búsqueda en el catálogo de MCP remotos oficiales filtrada por "data", mostrando la tarjeta de datadog junto a las entradas de medidata, ramp-data, cdata-connect-ai y databricks

Paso 3: establece tu región en la URL. TrueFoundry rellena automáticamente el nombre, la descripción y la URL. La URL incluye un marcador de posición <region> que debe reemplazarse por el subdominio de tu sitio de Datadog. Añádete a ti mismo o a tu equipo en ColaboradorescomoGestor del servidor MCP.

Formulario de añadir nuevo servidor MCP que muestra el nombre datadog, la descripción prellenada, el campo URL que contiene un marcador de posición de región, la sección de Colaboradores y los datos de autenticación configurados en OAuth2

El formato es https://<mcp-host>/api/unstable/mcp-server/mcp?toolsets=all, donde el host es mcp.datadoghq.com (US1), mcp.us3.datadoghq.com, mcp.us5.datadoghq.com, mcp.datadoghq.eu, mcp.ap1.datadoghq.com o mcp.ap2.datadoghq.com. El sufijo ?toolsets=all es el selector de conjuntos de herramientas de Datadog; puedes restringirlo aquí (?toolsets=apm,core).

Paso 4: confirma los detalles de OAuth2 / DCR. TrueFoundry rellena automáticamente los puntos de conexión; haz clic en Volver a obtener detalles de OAuth2 si están vacíos. Deja ID de clienteySecreto de cliente vacío: DCR los emite en el momento de la conexión.

Panel de configuración de OAuth2 que muestra el banner de Registro Dinámico de Clientes, el botón para volver a obtener los detalles de OAuth2, el tipo de concesión establecido en Código de autorización, la URL de autorización, la URL de token, la URL de registro y los métodos de desafío de código admitidos establecidos en S256

Para una organización US5:

‍