Datadog MCP Server

About

The Datadog MCP Server is Datadog's official, vendor-hosted Model Context Protocol endpoint — not a package. Each Datadog site has its own URL of the form https://mcp.<your-site>/api/unstable/mcp-server/mcp (US1: mcp.datadoghq.com, EU1: mcp.datadoghq.eu), and OAuth 2.0 is the recommended way in; a Personal or Service Access Token as an Authorization bearer header is the documented fallback for CI, with DD_API_KEY plus DD_APPLICATION_KEY headers as a third option. Datadog ships first-party client integrations rather than expecting hand-written config: a Claude Code plugin (/plugin install datadog@claude-plugins-official, then /ddsetup and /ddtoolsets), a Claude connector from the Connectors Directory, plugins for Cursor, VS Code/Copilot, JetBrains and OpenCode, and a ChatGPT app in Preview for US1. Tools are grouped into toolsets selected with a ?toolsets= query parameter, and only `core` — logs, metrics, traces, dashboards, monitors, incidents, hosts, services, events, notebooks — loads by default; two dozen more cover alerting, DBM, DDSQL, RUM, profiling, security, Kubernetes, error tracking, feature flags, cost management and data observability, with apm, cases, code-exec and remote-actions in Preview and excluded from toolsets=all. Access requires the mcp_read or mcp_write role permission in addition to the normal resource permission, which is why a working connection can still return no data. Limits at time of writing are 50 requests per 10 seconds of tool-call burst and 50,000 tool calls per month, and the server is not GovCloud compatible.

Installation

claude mcp add --transport http datadog-mcp https://mcp.datadoghq.com/api/unstable/mcp-server/mcp

Connecting to the Datadog MCP Server

1. 1.Check your site is supported

   The MCP Server is not GovCloud compatible — it is unavailable on app.ddog-gov.com and us2.ddog-gov.com. Everything else (US1, US3, US5, EU1, AP1, AP2, UK1) is supported. Your endpoint is the mcp. host for your own site, so a US1 org uses https://mcp.datadoghq.com/api/unstable/mcp-server/mcp and an EU1 org uses https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp. Getting this wrong is the usual cause of an auth loop that never completes: the org you log into has to be the org the host belongs to.

2. 2.Grant yourself mcp_read (and mcp_write if you want writes)

   Datadog gates MCP behind two role permissions of its own, on top of the normal resource permissions. `mcp_read` covers reading tools, `mcp_write` covers anything that creates or modifies. The Standard Role has both already; a custom role needs the MCP Read / MCP Write checkboxes ticked under Organization Settings → Roles. The resource permission still applies as well — reading monitors needs `mcp_read` *and* Monitors Read, which is why a correctly connected server can still answer "no monitors found".

3. 3.Claude Code — install the plugin, not a raw server entry

   The plugin bundles the server with Datadog's own skills and auto-updates. After installing, `/ddsetup` picks your site and runs the OAuth flow, `/ddtoolsets` turns on product toolsets, and `/reload-plugins` applies changes. If you had added the server by hand before, delete that entry first.

   Claude Code

   /plugin install datadog@claude-plugins-official
   /ddsetup
   /ddtoolsets

4. 4.Claude (desktop and web) — use the directory connector

   Install the Datadog connector from the Claude Connectors Directory via + → Add Connector, then complete OAuth. It includes MCP Apps for in-product visualisations, which a custom connector pointed at the same URL does not get. Again: if Datadog is already there as a custom connector, remove it to avoid conflicts.

5. 5.Any other client — add the endpoint over HTTP

   For clients with no plugin, add the endpoint as a streamable-HTTP server and let the client run OAuth. Append `?toolsets=` to the URL to pick tool groups — this only works on the remote/OAuth path, and the Codex CLI wants the `X-Datadog-MCP-Toolsets` header instead of the query parameter.

   shell

   claude mcp add --transport http datadog-mcp "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=core,dbm"

6. 6.CI or a server, where OAuth cannot run — use a token header

   Header auth is the documented fallback. A Personal Access Token (for a user) or Service Access Token (for a service account) as a bearer token is preferred, and needs no API key at all. The older form — `DD_API_KEY` plus `DD_APPLICATION_KEY` as HTTP headers — still works, and is worth knowing because it is what almost every third-party write-up about this server describes as *the* way in.

   mcp.json

   {
     "mcpServers": {
       "datadog": {
         "type": "http",
         "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp",
         "headers": { "Authorization": "Bearer <YOUR_ACCESS_TOKEN>" }
       }
     }
   }

Toolsets, and the tools worth knowing in each

Only `core` loads by default. Generally-available toolsets are alerting, audit-trail, cost, dashboards, data-observability, dbm, ddsql, error-tracking, feature-flags, kubernetes, llmobs, networks, onboarding, product-analytics, profiling, reference-tables, rum, security, software-delivery, synthetics, widgets and workflows. Four more are in Preview and are excluded from `toolsets=all` — ask for `apm`, `cases`, `code-exec` or `remote-actions` by name. `omit_tools=` drops individual tools after toolsets resolve, which is how you keep a toolset but remove its write half.

What people use it for

Which one should you use?

The alternatives here are not other Datadog servers — they are the other observability endpoints your agent might reach for.

Categories

Works With

Frequently Asked Questions

Related Guides