Datadog MCP server: setup per site, tools, and safe on-call use

When an alert fires at 3 a.m., most of the first ten minutes go to the same routine: open the monitor, find the service, pull the logs, check the last deploy, look at a trace. The Datadog MCP server lets an AI agent do that routine for you, from Claude Code, Cursor or another MCP client, using the same permissions you have in the Datadog UI. This guide covers the endpoint for each Datadog site, authentication, the toolsets, how to set it up in Claude Code and Cursor, and the controls you want before handing it to an on-call rotation. If MCP itself is new to you, start with what an MCP server is.

What the server is

Datadog's MCP server is remote and hosted by Datadog. There is nothing to run yourself unless your client cannot do remote auth, in which case Datadog offers a small local binary that proxies to the same remote tools.

Three properties matter for planning:

• It uses your identity. The server forwards the authenticated user's own credentials to Datadog's APIs. RBAC, Data Access Control and log restriction queries apply exactly as in the UI, and the server cannot reach anything the user cannot see.
• It does not call a model on your behalf, mostly. Datadog says the server receives only the tool name and its arguments, not your prompt, and does not send your Datadog data to a third-party AI provider. A few tools (semantic search, building a query from plain language) use AI models hosted by Datadog's providers. What reaches your model provider is decided by your AI client.
• Every call is audited. Tool calls land in Audit Trail under the event name MCP Server, with tool name, arguments, user and client.

Endpoints per Datadog site

Pick the endpoint that matches the site your organization lives on. Using the wrong one fails at login.

European teams on EU1 get an endpoint on the EU domain, so the tool calls go to the same site that already holds their data. If your organization signs in through a custom subdomain, add ?subdomain=<SUBDOMAIN> to the URL so the OAuth flow starts there instead of bouncing through the default login.

Setup in Claude Code

Datadog recommends its plugin from the official Anthropic marketplace. It bundles the MCP server with skills and slash commands for setup:

/plugin install datadog@claude-plugins-official

Then run /ddsetup, choose your Datadog site and finish the OAuth login in the browser. /ddtoolsets turns groups of tools on and off, and /ddconfig changes site or organization. After a configuration change, run /reload-plugins and re-authenticate from /plugin. If you already added the server by hand, remove that entry first to avoid two Datadog servers fighting.

If you prefer the plain MCP route, add the endpoint for your site directly (EU1 shown):

claude mcp add --transport http datadog-mcp https://mcp.datadoghq.eu/v1/mcp

Run /mcp in a session to complete the OAuth login. For a machine without a browser, the plugin also accepts key auth through environment variables. DD_MCP_DOMAIN is the bare domain, without https://:

DD_MCP_DOMAIN=mcp.datadoghq.eu \
DD_API_KEY=your-api-key \
DD_APPLICATION_KEY=your-application-key \
claude

Setup in Cursor

Install the Datadog plugin from the Cursor Marketplace, or from Cursor Settings, Plugins. Then type /ddsetup in the agent chat to pick your site and log in. The general steps for adding any remote server by URL are in our Cursor MCP guide if you want to configure it manually instead.

Authentication options

A token-based config for a client that reads mcpServers JSON looks like this:

{
  "mcpServers": {
    "datadog": {
      "type": "http",
      "url": "https://mcp.datadoghq.eu/v1/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_ACCESS_TOKEN>"
      }
    }
  }
}

For anything unattended, use a Service Access Token or keys from a service account that has only the permissions the job needs. Datadog's docs say the same. OAuth grants can be revoked per client under Personal Settings, Authorized Apps; a token already issued keeps working until it expires.

Toolsets and tools

Without a toolsets parameter you get core: logs, metrics, traces, dashboards, monitors, incidents, hosts, services, events and notebooks. Representative core tools include search_datadog_logs, analyze_datadog_logs (SQL-style counts and aggregations), get_datadog_metric, search_datadog_monitors, search_datadog_incidents, get_datadog_incident, get_datadog_trace, search_datadog_spans and search_datadog_events.

Add more with a query parameter:

https://mcp.datadoghq.eu/v1/mcp?toolsets=core,alerting,software-delivery

Generally available toolsets include alerting, dashboards, dbm, ddsql, error-tracking, kubernetes, llmobs, rum, security, synthetics, software-delivery, workflows, cost and code-exec, among others. toolsets=all enables every GA toolset. Preview toolsets such as apm, cases, investigator and remote-actions are not part of all and must be named explicitly; some need a preview sign-up.

Remove individual tools with omit_tools:

https://mcp.datadoghq.eu/v1/mcp?toolsets=all&omit_tools=create_datadog_notebook,edit_datadog_notebook

Fewer tools is better for the agent too. Every tool definition takes context window space, which is why Datadog suggests all only for clients that filter tools, such as Claude Code.

On-call and incident workflows

These are the routines where the server earns its place:

• First look at an alert. "Monitor X is alerting. Show its current state, the error logs for that service in the last 30 minutes, and any deployment events in the last two hours."
• Incident catch-up. "Summarise incident ABC123 and list related monitors that are alerting." Note that get_datadog_incident does not include timeline data, per Datadog's tool reference.
• Log statistics. "Count error logs by service over the last hour and show the top five." This goes to analyze_datadog_logs rather than paging raw lines.
• Trace from a code change. In Claude Code or Cursor, inside the repo: "Find slow traces for the checkout service and point me at the code path in this repo."
• Monitor coverage. With alerting: "Which of our services have no monitor on error rate?" then a draft monitor (see below).

Repeated routines like the alert triage belong in a skill so every engineer on the rotation runs the same steps.

Read-only vs write

Write access is layered:

1. Datadog permissions. Tools need mcp_read or mcp_write plus the normal resource permission, for example mcp_read and Monitors Read to read monitors. A read-only user calling a write tool is rejected. The Standard role has both MCP permissions by default; custom roles need them added.
2. Organization controls. Admins can manage global MCP access and write capabilities from Organization Settings, and the IP allowlist can restrict where connections come from.
3. Tool selection. Leave write-heavy toolsets out, or drop specific tools with omit_tools.
4. Client approval. In Claude Code, auto-allow search and get tools and keep a confirmation on anything that creates, updates or deletes.

Some write tools are deliberately conservative. create_datadog_monitor creates the monitor in draft mode, with notifications off and priority 5; a human publishes it in the UI. Others, like dashboard upsert and delete or workflow execution, act directly, so they deserve an approval step.

Treat returned data as untrusted input. Log lines and event text can contain anything a user or attacker managed to write into them, including instructions aimed at an agent. Do not combine broad log access with tools that can send data out of the company in the same session without approval. The general rules are in MCP security best practices.

Query volume and cost

Datadog documents fair-use limits of 50 tool calls per 10 seconds and 100,000 tool calls per month, subject to change. An agent in a loop can burn through a burst quickly, so prefer aggregate tools over paging raw logs, keep time windows tight, and use the max_tokens parameter most tools accept when you only need a summary. Responses are truncated by default and tell the agent how to ask for more.

To see who is using it, Datadog emits datadog.mcp.tool.usage and datadog.mcp.session.starts, tagged with user, client and tool. Because the usage metric is a distribution, count it like this:

count:datadog.mcp.tool.usage{*} by {user_email}.as_count()

On the model side, the cost is tokens: large log results are tokens your AI provider bills for, which is one more reason to aggregate first.

Running it for a whole team

Per-user setup works for a few engineers. For a rotation of twenty, you want the same toolsets, the same write policy and one log across Datadog, your ticketing system and whatever else the agent touches. That is the job of an MCP gateway. Walma AI Hub runs approved MCP servers like Datadog behind one policy and one audit log, with the models running in the customer's own Azure tenant in an EU region, which pairs naturally with an EU1 Datadog site. See how the AI Hub works if you are rolling agents out to an engineering team.