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.

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.

For a US5 org:

auth_data:
  type: oauth2
  grant_type: authorization_code
  authorization_url: https://us5.datadoghq.com/oauth2/v1/authorize
  token_url: https://us5.datadoghq.com/oauth2/v1/token
  registration_url: https://us5.datadoghq.com/api/v2/oauth2/register
  jwt_source: access_token
  code_challenge_methods_supported:
    - S256

All four URLs must use the same Datadog site. Mixing the generic datadoghq.com host with a non-US1 org is the most common cause of failure.

Step 5 — Allow-list the callback in Datadog. Under Organization Settings → Preferences, add TrueFoundry’s OAuth callback to MCP OAuth Redirect URLs — for a self-registered remote server, https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback [VERIFY — take the exact callback from your own server’s OAuth config rather than assuming it]. Confirm on the same page that MCP Access is enabled, MCP Write Access only if needed, and the Site top-right matches your region.

Step 6 — Authorize. Save the server, open its Tools tab and click Connect Now. Read Datadog’s consent screen rather than clicking through it — the permission count is high, and it is the clearest view of what you are opening — then Authorize.

Step 7 — Verify the tools. You return to the detail page, now showing a Remote tag, Auth Type OAuth2, and the full tool list with read-only and Destructive labels.

How authentication actually works

TrueFoundry separates inbound authentication — how a client proves itself to the gateway — from outbound, how the gateway proves itself to Datadog. The two are independent, and that is what makes per-user attribution possible.

Inbound — four supported methods:

Virtual Account tokens give every request identical access, so they cannot express per-user Datadog scope — use a PAT or an IdP token inbound instead.

Outbound — OAuth2 Authorization Code with PKCE, plus DCR. Each user authorizes their own Datadog account and TrueFoundry manages consent, token storage and refresh, injecting the right token per user on every call.

One subtlety in Datadog’s model is genuinely good news. Its MCP permissions grant no resource access on their own — mcp_read and mcp_write only unlock the MCP surface on top of the user’s existing Datadog role. An agent acting for an engineer who cannot see production logs in the UI cannot see them through MCP either. What the gateway adds is the layer Datadog cannot: which tools are reachable, who can reach them, and a call log naming the caller.

Scoping tools before you ship

The Tools tab is where a 200-plus-tool server becomes a workable one.

Per-tool toggles. Turn a tool off and it is omitted from tools/list entirely — clients never see it and it cannot be invoked. This is not prompt-layer filtering. An incident agent needs search_datadog_logs, get_datadog_metric, get_datadog_trace and search_datadog_monitors, not delete_datadog_dashboard, execute_code or Remote Actions. An agent that cannot call a tool cannot be talked into calling it, whatever a poisoned log line says.

Enable new tools by default. Left on, tools Datadog ships appear automatically. Datadog’s own docs call these tools subject to change, so turning it off is right — your capability surface then grows only when you decide it should.

Bulk Action. Switches every row to checkboxes with Select all. On a server this size: default mode off, Select all, uncheck, enable the dozen tools you need.

Click the pencil on any tool to change how the model sees it:

The Description override (up to 20,000 characters) steers selection between Datadog’s near-identical query tools — search_datadog_logs versus analyze_datadog_logs is the pair a model picks wrong. MCP Tool Annotations mark a tool Read-only or Destructive, setting readOnlyHint or destructiveHint — which is what lets the approval policies below work without enumerating names.

Who can do what: collaborator roles

Access control attaches to users, teams or virtual accounts on two dimensions: which servers an identity can reach, and which tools inside one it can call.

This maps onto how teams already work: platform holds Manager, on-call engineers hold User, the SRE lead holds Approver — the same MCP access control model applied across every server.

Ready to scope your first observability server?

Connect Datadog, keep only the read tools your agent needs, and put the rest behind approval.

Start free on TrueFoundry

Human approval for destructive tools

Disabling write tools is blunt. Sometimes you want an agent to create a monitor or upsert a dashboard mid-incident — just not unattended at 3am.

When a gated tool is called, the call is held, a request is created, and approvers are notified. Create policies under AI Gateway → Policies → MCP Tool Approval (Beta in the console).

Each policy names the servers it gates and picks an approval scope: named for a specific list, destructive for everything marked destructiveHint: true, or all. The most specific wins — named > destructive > all. Mark Datadog’s write tools Destructive once and gate the class rather than listing each by name.

Validity is Once or time-based in minutes, and the most restrictive wins — Once beats 10 minutes beats 30. A 30-minute window suits incident work: it covers an investigation without leaving a grant open overnight.

Approvers are notified over Email, Slack, PagerDuty or MS Teams, and review requests in the console.

Each request shows the tool, policy, requester, validity window and actual arguments — so an approver sees which dashboard an agent wants to delete before waving it through. While pending, the caller gets a JSON-RPC result carrying _meta.approval_status: "pending" rather than an error, so a well-behaved agent retries. Grants are per requester; a denial blocks nobody permanently, so to durably block, disable the tool or remove the user.

Testing in the Tool Playground

Click Try next to a tool on the server detail page. For search_datadog_logs, supply a query and a time window, hit Execute Tool, and read the JSON in the right-hand panel; Try is disabled for any tool you turned off.

Do this with a logs tool on day one and read what comes back — those lines are what will sit in your model’s context on every incident.

Using it from your IDE

Open the How To Use tab for your tenant-specific Gateway URL and paste-ready snippets.

It covers Claude Code, VS Code, Claude Web, Claude Desktop, Cursor, Windsurf, Codex, and the Python and TypeScript MCP SDKs. Add MCP to Cursor writes the config; Show API Key reveals the token if your client needs one in a header. Take the URL from this tab — a hand-built endpoint is the commonest cause of a client that lists no tools.

What you get once it’s behind the gateway

Post-tool guardrails. The control that matters most for Datadog. Guardrail hooks run at mcp_pre_tool, before a tool is invoked, and mcp_post_tool, after it returns. The post-tool hook is where you enforce policy on log content — catching a secret or PII field in a response before it reaches the model. If you configure one guardrail on one observability server, make it this one.

Tool-level metrics. The MCP Metrics dashboard breaks down requests per second, P50/P75/P90/P99 latency, failure rate by error type, and a ranked request count per tool.

For most servers this is a performance tool; for Datadog it is also the fastest way to find the agent querying search_datadog_logs forty times per investigation.

Full-request observability. Every tool call is traced with caller identity, tool name, inputs and latency, exported over OpenTelemetry — including, pleasingly, back into Datadog.

Low overhead. The gateway adds roughly 3–4 ms and handles 350+ RPS on one vCPU.

One registry. With several servers registered you can bundle a subset of their tools behind one endpoint using a Virtual MCP Server — so an on-call agent gets exactly the Datadog, GitHub and Slack tools it needs.

Revoking access

Tenant admins can wipe every stored credential on the server from the three-dot menu next to Edit.

Revoke all tokens deletes every auth override and stored OAuth token for all users and virtual accounts on that server, takes effect on the next request, and is recorded in Activity Logs. It is irreversible, and tenant-admin only.

One limit: it clears tokens at the gateway only, not the grant at Datadog. In an actual incident, also disable MCP Access in Datadog’s Organization Settings, which shuts the upstream surface org-wide.

Gotchas worth knowing

The region trap is the whole ballgame. Before debugging anything else, read the Site in Datadog’s top right and check all four URLs against it.

Toolsets are a cheaper lever than toggles. The ?toolsets= parameter filters at the source, so those tools never enter the schema list — which keeps the list small enough that clients do not degrade.

MCP Write Access is an org-wide switch, not a per-user one. Enabling it unlocks the write surface for every user whose Datadog role already permits those actions. Leave it off unless you need write tools, and use gateway-side approval policies instead.

Related reading

• What Is an MCP Gateway: Architecture and Use Cases — the architectural primer
• MCP Access Control: Securing AI Agents with an MCP Gateway — tool- and server-level permissions
• MCP Server Security Best Practices — hardening, including data-egress controls
• Virtual MCP Server Explained — one endpoint for an on-call agent
• MCP Authentication: OAuth, Tokens and Identity — OAuth2 and DCR mechanics

Conclusion

The Datadog MCP server is the most useful server most platform teams can connect this year, because incident response is the shape of problem agents are good at: correlate four data sources fast, under pressure, at 3am. It is also where the standard security framing misleads you. The risk is not that an agent deletes a dashboard. It is that an agent reads a log line containing a production credential and moves it somewhere you never modelled.

That is solvable in a specific place: post-tool guardrails on the response, per-tool scoping, per-user OAuth so Datadog’s RBAC still binds, approval gates on the writes, and a traced call log with real caller identity. Running Datadog through TrueFoundry’s MCP Gateway gives you all five without building any of it.

Connect the Datadog MCP server on TrueFoundry

Free to start