Datadog MCP Server Setup for Cursor IDE (2026)

How do you set up the Datadog MCP server in Cursor? Generate a Datadog API key and Application key, add a datadog block to ~/.cursor/mcp.json with both keys plus your Datadog site, then restart Cursor. Once connected, your AI can query metrics, search logs, and check monitor status without you switching to the Datadog dashboard mid-debug.

Datadog's API has always split auth into two pieces — an API key (identifies your org) and an Application key (identifies the acting user and their permissions) — and MCP integrations for Datadog follow that same two-key pattern rather than a single token. If you've only ever used a single Datadog API key for a metrics-submission script, the Application key is the part you're likely missing here.

What You Can Do With Datadog MCP in Cursor

Once connected, Cursor can typically:

The exact tool surface depends on which Datadog MCP package or integration you install — some expose read-only monitoring tools, others add write access for creating monitors or muting alerts. Check the README of whichever package you install for the current tool list before assuming a capability exists.

Prerequisites

Step 1: Get Your Datadog API Key and Application Key

1. In Datadog, go to Organization Settings → API Keys
2. Copy an existing API key, or click New Key to create one
3. Go to Organization Settings → Application Keys
4. Click New Key, name it something like cursor-mcp, and copy it — Application keys are scoped to the user who creates them, so the MCP server inherits whatever that user can see in Datadog

Also note your Datadog site — this is easy to get wrong and a common source of "empty results" reports. US-based orgs are usually datadoghq.com, but Datadog also runs us3.datadoghq.com, us5.datadoghq.com, eu1.datadoghq.com, and others depending on where your org was provisioned. Check the URL you use to log into Datadog in your browser — that domain is your site.

Step 2: Add Datadog to Your MCP Config

Open ~/.cursor/mcp.json (or Settings → MCP in Cursor) and add a datadog entry. The general shape, matching how other API-key-based MCP servers on this site are configured, looks like:

{
  "mcpServers": {
    "datadog": {
      "command": "npx",
      "args": ["-y", ""],
      "env": {
        "DD_API_KEY": "your-api-key-here",
        "DD_APP_KEY": "your-application-key-here",
        "DD_SITE": "datadoghq.com"
      }
    }
  }
}

The DD_API_KEY, DD_APP_KEY, and DD_SITE variable names come directly from Datadog's own API client convention and are stable across Datadog's tooling. What isn't stable enough to print here with confidence is the exact npm package name — there's more than one Datadog MCP implementation in circulation (community-maintained and vendor-provided), and which one you should install, plus its exact args, depends on which one you choose. Check Cursor's MCP directory or Datadog's own documentation for the current recommended package before finalizing this block, and swap for the real one.

If the package you choose is remote-hosted rather than npx-based (increasingly common for vendor-run MCP servers — see how Cloudflare does this), the config will use a url field instead of command/args, closer to an OAuth-based setup than a local process.

Step 3: Restart Cursor and Verify

Fully quit and reopen Cursor. In chat, try:

List the monitors currently in an alert state

or

Show me the last 20 error-level logs for the checkout service

A response naming real monitors or log lines confirms the connection. If you get an empty or generic-sounding answer, re-check DD_SITE before assuming the keys are wrong — a valid key pair pointed at the wrong site returns empty results, not an auth error, which makes it look like a permissions problem when it's actually a region mismatch.

Step 4: Practical Workflows

Debug a service regression

Query the p99 latency for the payments-api service over the last 4 hours and tell me if it's degraded compared to yesterday at the same time

Triage active alerts

List every monitor currently in a Warn or Alert state, grouped by team tag, and summarize what each one is watching

Correlate a deploy with an error spike

Search logs for the checkout service for error-level entries in the last hour, and check whether the spike lines up with the deploy that went out at 2pm

Pull context before writing a fix

Find the monitor that's currently alerting for high memory usage on the worker-queue service, then check recent APM traces for that service to see if there's an obvious cause

Site Region Mismatches Are the Most Common Setup Bug

Because Datadog runs several regional instances under similar-looking domains, a config copied from a colleague on a different Datadog org (or from a generic example online) will often have the wrong DD_SITE for your account. The symptom isn't an error — it's silence. Queries succeed, monitors list as empty, logs return nothing. If your first test prompt comes back suspiciously empty, check DD_SITE against your actual login URL before touching the API keys.

Troubleshooting

Empty results with no error
Almost always a DD_SITE mismatch — see above. Confirm the domain matches where you actually log into Datadog.

"Forbidden" on some queries but not others
The Application key inherits the permissions of the user who created it. If that user can't see a particular dashboard or team's monitors in the Datadog UI, the MCP server can't either — this is a Datadog RBAC issue, not an MCP config issue.

Server won't start
Check that both DD_API_KEY and DD_APP_KEY are present — Datadog's API rejects requests missing either one, and some MCP wrappers surface that as a generic startup failure rather than a clear auth error.

Rate limited on heavy log queries
Datadog's Logs API has query-rate limits that vary by plan. For broad log searches, narrow the time range and add a service filter rather than pulling an unbounded query — the same practice you'd use directly in the Datadog UI.

Frequently Asked Questions

Q: Do I need both an API key and an Application key, or just one?
A: Both. The API key identifies your Datadog org; the Application key identifies the acting user and their permission scope. Datadog's platform requires this pair for essentially all API-based access, and MCP integrations inherit that requirement rather than working around it.

Q: Why does my query return an empty result instead of an error when something's misconfigured?
A: Usually a DD_SITE mismatch. A key pair that's valid for datadoghq.com but pointed at eu1.datadoghq.com (or vice versa) authenticates fine against the wrong region and just finds nothing there, rather than failing outright.

Q: Can this integration create or mute monitors, or is it read-only?
A: Depends on the specific package and the Application key's permissions. Read operations (querying metrics, logs, monitor status) are the common baseline; write operations (creating monitors, muting alerts) are package-dependent — check the tool list the server exposes after connecting rather than assuming either way.

Q: How does this compare to the Grafana MCP server also covered on this site?
A: They're not interchangeable. The Grafana MCP server queries whatever data sources are wired into your Grafana instance (commonly Prometheus and Loki). Datadog MCP talks directly to Datadog's own platform APIs. If your org uses Datadog as the primary observability platform rather than Grafana, this is the guide you want.

Q: Is there an official Datadog-maintained MCP server, or only community ones?
A: Both community and vendor-provided options exist in this space, and which is "official" at any given moment is worth verifying directly against Datadog's own docs or the Cursor MCP directory before standardizing a team config on one — this is an area that's moved quickly and package names have shifted.

Related Guides

---