Datadog MCP Server: Tools, Setup, and How to Connect It Safely

What the Datadog MCP server is

The Datadog MCP server is a remote Model Context Protocol server hosted by Datadog. It exposes your org as callable tools: an agent asks for logs matching a query, a metric series, a trace by ID or a monitor’s state, and gets structured data back.

It is organised into toolsets you enable per connection, so you spend model context only on the surface you need. core is the default.

Datadog’s tools reference lists well over two hundred tools — which is why the toolsets parameter exists, and why the tool-scoping section below matters here.

Because it is remote rather than local, there is no container to run: you point a client at a URL and authenticate, the same shape as the other remote MCP servers teams are standardising on. It is the observability MCP server most platform teams reach for first.

What agents actually do with it

Single calls are not the interesting part — get_datadog_metric alone is a worse Datadog UI. The value shows up when tools chain:

• Live incident triage. A monitor fires. The agent calls search_datadog_monitors for the alert condition, get_datadog_metric for how far past threshold the signal went, search_datadog_spans for which service’s latency moved first, then search_datadog_logs on that service. One turn, four surfaces correlated.
• Deploy correlation. search_datadog_events for deployments in the last hour against the error rate from analyze_datadog_logs — answering “did the 14:02 deploy cause this” without eyeballing two graphs.
• Trace-to-root-cause. Take a trace ID off a customer report, call get_datadog_trace, find the slow span, then pull its explain plan from Database Monitoring.
• Postmortem drafting. get_datadog_incident, search_datadog_logs for the window, create_datadog_notebook to write the timeline back.

The read/write split matters. Almost everything useful here is read. The write tools — creating monitors, upserting or deleting dashboards, updating cases, plus Remote Actions and Code Execution — are a smaller set with a far larger blast radius, and TrueFoundry labels them Destructive.

Why connecting it raw breaks at team scale

One SRE wiring Datadog into Claude Code during an on-call shift is fine. A whole platform org doing it is not.

Logs are the exfiltration path, and nobody treats them that way. This failure mode is specific to observability servers, and it belongs first. Application logs are where secrets go to die quietly: an API key in a request header logged wholesale, a connection string in a startup line, a customer’s address in a serialised order object. Teams accept that because log access is gated behind Datadog RBAC, and a human who greps for password is a known quantity. An agent calling search_datadog_logs is not. It pulls raw log lines into a model context, that context may reach a third-party inference provider, and it may end up quoted in a Slack summary. No credential was stolen, no policy broken — the data simply moved somewhere nobody modelled.

Query volume has a bill attached. Datadog pricing is usage-based and agents are good at looping. A poorly-prompted incident agent calls search_datadog_logs twenty times in one investigation, widening the window each round. Without per-tool call counts you find that on an invoice. [VERIFY — Datadog’s docs do not state that MCP tool calls are metered separately; treat this as a consequence of usage-based query pricing and confirm against your contract.]

Region mismatch produces useless errors. Datadog is site-specific, and the MCP URL plus every OAuth endpoint must point at your site. Get one wrong and you see a generic “Authentication failed” with nothing pointing at a hostname.

No attribution when it matters most. Datadog’s audit trail records that a query ran, not that your incident agent ran it on a prompt from a PagerDuty webhook. During a postmortem the trail stops at an API token.

None of these argue against connecting Datadog. They argue for a control plane in front of it, which is what an MCP gateway is.

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

Connecting the Datadog MCP server through TrueFoundry

Datadog MCP setup does not run through the managed catalogue. It registers through Connect Official Remote MCP Servers — pre-vetted servers where the auth is templated but you own the connection. For Datadog that template includes OAuth2 with PKCE and Dynamic Client Registration (DCR): TrueFoundry registers the OAuth client automatically, so there is no OAuth app to build.

On the Datadog side you need MCP Access enabled on the org, mcp_read on your user (plus mcp_write for write tools), and your site domain. Government sites are not supported.

Step 1 — Open the picker. In MCP Servers, click Add new MCP Server and pick Connect Official Remote MCP Servers.

Step 2 — Find Datadog. Type data in the catalogue search and click the datadog card.

Official remote MCP catalogue search filtered to ‘data’, showing the datadog card next to medidata, ramp-data, cdata-connect-ai and databricks entries

Step 3 — Set your region in the URL. TrueFoundry pre-fills Name, Description and URL. The URL ships with a <region> placeholder that must be replaced with your Datadog site subdomain. Add yourself or your team under Collaborators as MCP Server Manager.

Add new MCP Server form showing Name datadog, the pre-filled description, the URL field containing a region placeholder, the Collaborators section, and Auth Data set to OAuth2

The shape is https://<mcp-host>/api/unstable/mcp-server/mcp?toolsets=all, with the host being mcp.datadoghq.com (US1), mcp.us3.datadoghq.com, mcp.us5.datadoghq.com, mcp.datadoghq.eu, mcp.ap1.datadoghq.com or mcp.ap2.datadoghq.com. The ?toolsets=all suffix is Datadog’s toolset selector — narrow it here (?toolsets=apm,core).

Step 4 — Confirm the OAuth2 / DCR details. TrueFoundry auto-populates the endpoints; click Refetch OAuth2 details if they are empty. Leave Client ID and Client Secret blank — DCR issues those at connection time.

OAuth2 config panel showing the Dynamic Client Registration banner, the Refetch OAuth2 details button, Grant Type set to Authorization Code, Authorization URL, Token URL, Registration URL, and Code Challenge Methods Supported set to S256

For a US5 org:

‍