Datadog MCP Server: Complete Setup Guide for AI Ops (2026)

TL;DR + what you actually need

Three things you will keep typing if you run the Datadog MCP server seriously:

• Two secrets: DATADOG_API_KEY (org-scoped) and DATADOG_APP_KEY (user-scoped). Generate both in your Datadog org under Organization Settings. The MCP server refuses to start without them.
• One site value: DATADOG_SITE = datadoghq.com (US1, default), datadoghq.eu (EU1), ap1.datadoghq.com (AP1), us3.datadoghq.com, us5.datadoghq.com, or ddog-gov.com (GovCloud). Pick the one your Datadog org actually lives in.
• One package: @winor30/mcp-server-datadog — the most-installed community implementation, Apache 2.0, ships ~20 tools across monitors, metrics, logs, incidents, dashboards, RUM, hosts, and downtimes. Run via npx, no global install needed.

Quick install commands, in case you only came for the copy-paste:

• Claude Code: claude mcp add datadog -e DATADOG_API_KEY=YOUR_KEY -e DATADOG_APP_KEY=YOUR_APP_KEY -e DATADOG_SITE=datadoghq.com -- npx -y @winor30/mcp-server-datadog
• Cursor / VS Code / Windsurf: paste the JSON block from the install card below into the client’s mcp.json / settings file
• Codex CLI: add a [mcp_servers.datadog] TOML block to ~/.codex/config.toml — exact snippet in the Codex section

The rest of this guide explains why those snippets look the way they do, how the dual-key auth actually works, what each tool does, and where the Datadog-charges-you-for-this edges are.

What Datadog MCP actually does

Datadog is a metrics-logs-traces SaaS your services already write into. The Datadog MCP server is a stdio process that exposes the read paths of Datadog’s REST API as MCP tools. Your agent calls get_monitors and the server fires a GET /api/v1/monitor against the right Datadog site, parses the JSON, and hands the result back as a tool response the model can reason over.

What that buys you in practice: an agent that knows what your dashboards already show. When you ask “has p99 latency on the checkout service moved in the last hour?” the model calls query_metrics with the right tag filter and gets an actual time series back — no hallucinated “your latency might be elevated because…”. When an alert fires, you can ask “list the monitors that are red, and pull the last 100 log lines from any service they cover” and get a triage summary in 30 seconds.

The server itself does no observability work. It doesn’t store metrics, doesn’t cache logs, doesn’t add intelligence on top of Datadog. It is a thin tool adapter: agent calls in, Datadog API calls out. Two consequences. First, every quota that applies to your Datadog org applies to the MCP connection — 429s, retention windows, scope restrictions on the Application Key. Second, you cannot use this server without a paid Datadog org behind it. There is no “hosted Datadog MCP” running against a demo dataset.

The most-installed implementation lives at github.com/winor30/mcp-server-datadog (Apache 2.0). A second implementation by geli2001 covers a smaller surface (read-only, no RUM or downtimes) under MIT. We use winor30 in every snippet below; swap the package name if you prefer MIT. Datadog itself does not (at the time of writing) ship a first-party MCP server — both options are community-maintained against Datadog’s public API.

Auth model: API key + Application key (the friction point)

The single biggest source of “why doesn’t this work” questions on the Datadog MCP server is auth. Not because it’s hard — because Datadog splits credentials across two tokens, and most MCP tutorials skip the why.

Datadog issues two kinds of tokens, and you need both for the MCP server.

The API key — organization-scoped, identifies the org

The API key is the older of the two. It identifies the Datadog organization to the API. Datadog’s own docs say: “Requests that write data require reporting access and require an API key.” In practice the API key is what your agents and services use to ping metrics in, ship custom events, push logs from a daemon. It’s organization-scoped — every API key is tied to a Datadog org, not a specific human user.

You generate it in the Datadog UI at Organization Settings → API Keys → New Key. A Datadog org can have between 1 and 50 API keys (you can request more from support if you somehow need them). Best practice is one API key per service or per use case so you can rotate the MCP one without breaking your log shipping; we treat the MCP key like any other production secret — generate it, name it “mcp-server-claude-code”, paste into the env var, never check into git.

The Application key — user-scoped, identifies you

The Application key is the newer abstraction, and the one you actually read with. Datadog’s docs: “Requests that read data require full access and also require an application key.” Application keys are attached to a specific Datadog user — the user that created the key — and they inherit that user’s permissions. If your user cannot see the payment-team dashboards in the UI, your Application key cannot read them through the API either.

You generate it at Organization Settings → Application Keys → New Key (also reachable from Personal Settings → Application Keys). The feature worth knowing about: scoped Application keys. Modern Datadog lets you restrict an Application key to a list of authorization scopes — monitors_read, dashboards_read, metrics_read, events_read, logs_read_data, incident_read, etc. For an MCP server that’s only doing observability reads, this is the principle of least privilege in action: scope the Application key to the read scopes you actually use, deny everything else, and the worst thing a leaked key can do is read data the agent could already see in your console.

Why MCP needs both, and why both go in env vars

The MCP server reads — so it needs the Application key. The Application key alone doesn’t identify the Datadog org to the API endpoint — so it also needs the API key. Both ship as plain HTTP headers (DD-API-KEY and DD-APPLICATION-KEY) on every request. The MCP server picks them up from DATADOG_API_KEY and DATADOG_APP_KEY in its environment, or (in the geli2001 fork) DD_API_KEY and DD_APP_KEY. They behave identically — the names just differ.

A working env block for the winor30 server looks like:

DATADOG_API_KEY=dd_api_key_abc123...
DATADOG_APP_KEY=dd_app_key_xyz789...
DATADOG_SITE=datadoghq.com  # or datadoghq.eu, ap1.datadoghq.com, etc.

Five auth mistakes we see repeatedly:

1. Mixing keys across regions. Keys generated in your US Datadog org will not authenticate against the EU API base. The org lives in one region; the keys live with it.
2. Using only the API key. A common reflex from people who already script Datadog ingestion — they paste the API key and skip the Application key. Result: 403 Forbidden on every read tool. The fix is to generate an Application key and add it.
3. Application key with insufficient scope. If you scoped a key to monitors_read only and your agent tries query_metrics, you get a 403 on metrics but a 200 on monitors. The MCP server returns the Datadog error verbatim, which is helpful.
4. Pasting keys into a shared config. An Application key is user-scoped. Two engineers pasting their personal Application keys into a shared repo’s .mcp.json file is exactly the kind of mistake the user-scope model exists to prevent. Use a per-user secrets manager (1Password CLI, direnv, your client’s built-in env-var picker) and keep keys out of source control.
5. Forgetting to rotate. Application keys outlive the user that created them by default — until the user is deprovisioned, the key keeps working. When someone leaves the team, audit Application Keys for keys they own and delete them.

If you only remember one thing from this section: both keys, both as env vars, never in the JSON config file you check into git. The MCP install card on this page outputs the JSON shape; you hand-edit the env values in before saving locally.

US vs EU vs AP regions — the DATADOG_SITE value

Datadog runs each region as a fully independent deployment. Data does not replicate between sites; you cannot query US data from the EU API base. Pick wrong, and you authenticate but every tool call returns empty results — your agent will cheerfully report “no monitors exist” on a wide-awake production org because it’s talking to the wrong region.

The full mapping, current at time of writing:

How to know which one you’re on: open your Datadog UI in the browser and look at the address bar. app.datadoghq.eu is EU1. ap1.datadoghq.com is AP1. The web URL pattern always matches the DATADOG_SITE value — they share the same subdomain. If you log into app.datadoghq.com you’re on US1 and you leave DATADOG_SITE as the default (or set it explicitly to datadoghq.com).

The EU case trips people up the most. A typical pattern: an engineer joins a team that operates in Frankfurt, the team picked Datadog EU1 for GDPR reasons, the engineer installs the MCP server copying a tutorial that hard-codes datadoghq.com, and every tool call returns a 403 because the US API doesn’t know about their EU-org keys. Fix: set DATADOG_SITE=datadoghq.eu, restart the MCP client, the tools work. We get one of these questions a week — hence the dedicated FAQ entry.

One footnote on the geli2001 fork: it splits the site value across DD_SITE, DD_LOGS_SITE, and DD_METRICS_SITE. Set all three to the same value (e.g. all to datadoghq.eu) unless you have a multi-region setup where logs and metrics live in different orgs. The winor30 server uses a single DATADOG_SITE and routes accordingly.

Install (every client)

The Datadog MCP server is stdio-only at the moment — no remote endpoint to point at. Every install path runs npx -y @winor30/mcp-server-datadog as a subprocess of your MCP client with the three env vars set.

The install panel below pulls its configs from the canonical /servers/datadog catalog entry, so it stays in sync with the package name and env-var shape. Tap your client’s row, copy the snippet, paste into the right config file, fill in your two keys and the site, restart. Around 30 seconds end-to-end if your keys are already in hand.

One-line install · Datadog

Open server page

Install

Cursor

One-click install

VS Code

One-click install

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

A handful of client-specific notes that don’t fit cleanly in the panel:

• Claude Code reads the env block from the claude mcp add command flags or from the JSON file. The one-line form is: claude mcp add datadog -e DATADOG_API_KEY=… -e DATADOG_APP_KEY=… -e DATADOG_SITE=datadoghq.com -- npx -y @winor30/mcp-server-datadog. Add --scope project if you want the server registered in the repo’s .mcp.json rather than your user-level config. See /clients/claude-code for the full flag reference.
• Cursor reads MCP servers from ~/.cursor/mcp.json. Paste the mcpServers JSON block from the install card, fill in env values, restart Cursor. The Datadog tools appear in the agent’s tool list. See /clients/cursor for the config-file location.
• VS Code with the GitHub Copilot agent or any MCP extension reads from the workspace or user settings depending on extension. Use the JSON snippet the install card emits.
• Windsurf reads from ~/.codeium/windsurf/mcp_config.json. Same JSON shape.
• Gemini CLI uses gemini mcp add --name=datadog -- npx -y @winor30/mcp-server-datadog. Pass env vars through your shell environment before launching Gemini, or use a shell wrapper.

Codex CLI (the searched path)

Codex CLI looks for MCP servers in ~/.codex/config.toml. The TOML block for Datadog:

[mcp_servers.datadog]
command = "npx"
args = ["-y", "@winor30/mcp-server-datadog"]

[mcp_servers.datadog.env]
DATADOG_API_KEY = "dd_api_key_abc123..."
DATADOG_APP_KEY = "dd_app_key_xyz789..."
DATADOG_SITE = "datadoghq.com"

Restart Codex (kill any running session and re-run codex) and the Datadog tools register. The exact format above works for current Codex CLI; see /clients/codex for the config-file location on your platform and thecodex mcp list command to confirm registration. If you prefer not to keep secrets in TOML, leave the env table out and export the env vars in the shell that launches Codex — Codex inherits them.

Browse every supported client and its config path at mcp.directory/clients. For a comparison of how Datadog MCP fits alongside Grafana and Sentry, jump to our three-way observability comparison.

Tools walkthrough

The winor30 server ships around 20 tools across seven Datadog product areas. We will walk the ones agents actually call, grouped by what they do.

Monitors

get_monitors lists monitors in your org with filter parameters for name, tags, monitor type (metric, log, APM, RUM, etc.), and status (Alert, Warn, OK, No Data). Returns the full monitor object including query, message, thresholds, and the current evaluation state. This is the single most-called tool in our usage — “what’s on fire?” maps to a get_monitors call with status=Alert.

Metrics

query_metrics runs a Datadog metrics query against a time window and returns the time series. The query argument is the same string you’d paste into the Datadog UI’s metric query bar — avg:trace.http.request.duration{service:checkout-api} by {resource_name}, e.g. The model handles this DSL reasonably well when you give it example queries; less well when you expect it to compose one from scratch (Datadog’s metric DSL has less training-data coverage than PromQL).

Logs

get_logs runs a Datadog logs search and returns matching entries with timestamps, tags, and attributes. Take time windows seriously — the difference between “last 15 minutes” and “last 24 hours” on a busy service is two orders of magnitude in cost and in the size of the response. Tight queries first; widen only if needed.

Traces (APM)

list_traces returns recent APM traces with span-level latency and resource breakdown. Useful for “why is this endpoint slow” debugging when paired with query_metrics for the p99 trend.

Incidents

list_incidents and get_incident read your incident management board — open incidents, their severity, the responder list, the timeline. If your team uses Datadog Incident Management (vs PagerDuty or Incident.io), this is the tool that pulls the current state of the firefight into the agent’s context. Stack with get_monitors to ask “what triggered this incident?”.

Dashboards

list_dashboards and get_dashboard are retrieval-only. They return dashboard metadata (title, ID, author, last modified) and the full widget tree. Useful for summarising what a dashboard shows without opening it. The winor30 server does not ship a dashboard-create tool today — if you want the agent to author dashboards, draft the JSON spec in the agent and apply it through Datadog’s API separately (see Recipe 3 below).

Hosts & downtime

list_hosts, get_active_hosts_count, mute_host, unmute_host, list_downtimes, schedule_downtime, cancel_downtime. The host-mute and downtime tools do write to Datadog — they require an Application key with the right scope (typically monitors_downtime). Be aware you’re crossing from read to write here; treat these like any other side-effectful tool and gate them behind explicit user approval if your client supports it.

RUM (Real User Monitoring)

get_rum_applications, get_rum_events, get_rum_grouped_event_count, get_rum_page_performance, get_rum_page_waterfall. The RUM tools give the agent visibility into front-end performance and user-side errors. Useful when an alert is “p99 LCP regressed” and you want the agent to find which pages and which geographies are affected.

Recipes

Seven workflows where the Datadog MCP server earns its install. We assume the server is registered at user scope in your client of choice with valid keys and the correct DATADOG_SITE.

Recipe 1 — Find a slow endpoint without opening the UI

You ship a deploy. Someone says “feels slow”. Prompt the agent: “Compare avg and p99 of trace.http.request.duration on the checkout-api service over the last 30 minutes vs the previous 30 minutes, grouped by resource_name. Tell me the top three regressions.” The agent calls query_metrics twice (once per window) and diffs the result. Beats six tabs in the Datadog UI and three minutes of squinting at line charts.

Recipe 2 — Set up an alert (the agent drafts, you apply)

Read-mostly servers can’t create monitors, but they can absolutely design them. Prompt: “Look at how the existing monitors on checkout-api are configured (get_monitors with tag:service:checkout-api), then draft a new monitor JSON for ‘p99 latency > 800ms for 5 of the last 10 minutes’ following the same conventions our other alerts use.” The agent reads existing monitor objects, mimics the team’s tagging and message-template style, and hands you back ready-to-POST JSON. You apply it via POST /api/v1/monitor in your own tooling, in Terraform, or in the Datadog UI.

Recipe 3 — Create a dashboard from MCP (the long way)

The most-installed servers don’t expose create_dashboard. The agent-friendly workaround: ask the agent to draft the dashboard JSON using get_dashboard on an existing dashboard as a template. Example prompt: “Pull the ‘Payments overview’ dashboard via get_dashboard. Use its widget structure as a template, but swap the service tag from payments-api to checkout-api and rename the title to ‘Checkout overview’. Output the resulting JSON.” Apply the JSON to Datadog via POST /api/v1/dashboard using your own script. Why we don’t let the agent POST directly: dashboards are public-facing, named artefacts; a typo creates an orphan called “Test Dashboard 7” that haunts your org for a year. Human-in-the-loop is cheap insurance.

Recipe 4 — Incident triage in 30 seconds

Alert pages you. Prompt: “List incidents that are currently active. For each, pull the monitor that triggered it via get_monitor, the last 50 log lines from any service it covers (get_logs), and the p99 latency for that service over the last hour (query_metrics). Summarise in three bullets per incident.” The agent makes the right API calls in sequence and hands you a triage report. Beats clicking through the Datadog UI at 3 a.m. We trust the summary as a first read; we still open the UI for the deep-dive once we know what to look at.

Recipe 5 — Log aggregation across services

Bug report: “some users see checkout fail”. You don’t know which service. Prompt: “Search logs across all services in the checkout flow (checkout-api, payments-api, fraud, inventory) for status:error in the last 30 minutes. Group by service and show the top three error message strings per service.” The agent runs get_logs (or aggregate-logs on the geli2001 fork) with the right filter and returns a clean breakdown. Useful as the first read on a vague bug report.

Recipe 6 — Find unmonitored services

Coverage gap detection. Prompt: “List all services that appear in our APM traces in the last 24 hours (list_traces) but have zero monitors targeting them (cross-reference with get_monitors). Output the orphan list.” The agent does the join in-context and returns services that are shipping traces but have no alert coverage. Drop it into your weekly observability review.

Recipe 7 — Snooze noisy alerts cleanly

A monitor pages you three times in an hour for the same known issue. Rather than disabling it (which you’ll forget to undo), schedule a focused downtime. Prompt: “Schedule a downtime for monitor ID 12345 starting now, ending in 2 hours, with the message ‘known issue X, see incident INC-9876’.” The agent calls schedule_downtime (write operation — your Application key needs the right scope). Best done with a confirmation step in your MCP client because it’s side-effectful.

Rate limits + cost

Two cost dimensions to keep an eye on. The MCP server itself is free; what isn’t free is Datadog API quota and Datadog data charges.

API rate limits

Datadog rate-limits per endpoint and per organization, not per key. The metrics-query endpoint has more headroom than the monitors-list endpoint, which has more headroom than the logs-search endpoint with a wide time window. When you hit the limit, the API returns 429 Too Many Requests, the MCP server surfaces it, and the agent sees the failure. A misbehaving agent that loops on get_monitors can chew through the limit in minutes — we’ve seen it.

Three defences worth applying. First: in your prompt / system message, tell the agent to batch queries — “list all monitors once and filter in-context, don’t call get_monitor 50 times”. Second: set sane defaults on time windows. Default to the last 15 minutes for log searches and the last hour for metrics; widen deliberately. Third: if your team is running multiple concurrent MCP-driven agents against the same Datadog org, use scoped Application keys so a single runaway agent doesn’t kneecap quota for the team.

Cost

Read operations on Datadog don’t typically charge against your data plan — they consume API quota, not ingestion or retention quota. The dollar cost of MCP usage is essentially zero. What is not zero is the indirect cost: a chatty agent that keeps logs in long retention buckets for analysis can shift your usage profile (more queries against indexed logs vs flex logs, more APM trace searches, etc.). Most teams won’t notice; if you’re on a usage-heavy plan, monitor the Datadog “Usage” page for changes after rolling out MCP.

Troubleshooting

When to switch to something else

Datadog MCP is the right tool when your org already pays Datadog and the data you need lives there. It’s the wrong tool when the answer is somewhere else.

• You self-host Prometheus / Grafana, not Datadog: use the Grafana MCP server. It exposes PromQL/LogQL/TraceQL through the same MCP shape and the model handles PromQL more accurately than Datadog’s metric DSL because PromQL has far more training-data coverage.
• You want application-level error triage with release context: use Sentry MCP (Sentry’s first-party remote server, no install). Sentry’s issue-grouping and release-aware stack traces are still the strongest in the “what broke and in which release” shape of question.
• You want one MCP that covers all three: there isn’t one — they all wrap product APIs and the products genuinely differ. Most teams run two: Datadog MCP for infra/APM observability and Sentry MCP for error monitoring. The MCP protocol lets you have both registered simultaneously and the agent picks the right one per question.

We covered the three-way trade-off in detail in our Datadog vs Grafana vs Sentry MCP comparison — read that if you haven’t picked yet, or if you’re considering switching off Datadog entirely.

FAQ

Sources

• Most-installed MCP implementation: github.com/winor30/mcp-server-datadog (Apache 2.0, maintained by winor30)
• Alternative MIT-licensed implementation: github.com/geli2001/datadog-mcp-server
• Datadog API authentication docs: docs.datadoghq.com/api/latest/authentication
• Datadog API and Application Keys reference: docs.datadoghq.com/account_management/api-app-keys
• Datadog sites & regions reference: docs.datadoghq.com/getting_started/site
• Canonical MCP.Directory entry: /servers/datadog
• Three-way comparison: /blog/datadog-vs-grafana-vs-sentry-mcp-2026