Datadog MCP Server: Logs and Metrics in Your Coding Agent

The Datadog MCP Server is Datadog’s own remote MCP server. You add its endpoint to Claude Code, Cursor, VS Code or another MCP client, sign in to Datadog with OAuth, and your coding agent can search logs, query metrics, read monitors and incidents, and pull traces and spans while it works on the code. It acts as you: Datadog forwards your own credentials to its APIs, so the agent sees only what you can see in the Datadog UI, and write tools need a separate permission. The most useful habit is order: have the agent read the failing trace and the error logs before it opens a file, and turn what it finds into a task before it changes anything.

Status: generally available, with preview parts

Datadog announced in a March 9, 2026 press release↗ (opens in a new tab) that its MCP Server is generally available. Its documentation has also moved: the pages that used to sit under Bits AI now live in their own Datadog MCP Server section, and the old addresses redirect. A few parts are still marked Preview:

• The Datadog app for ChatGPT, available to US1 customers only during the preview.
• Some toolsets, among them apm, cases, investigator, live-debugger and remote-actions. Preview toolsets are not included in toolsets=all; you request them by name, and some need a sign-up.
• The Datadog plugin for OpenCode and the Codex plugin.

It is not available on Datadog’s US government sites, and the documentation says the server is under significant development, so tool names change. get_logs, for example, is now search_datadog_logs.

What the tools cover

The Datadog MCP Server overview↗ (opens in a new tab) groups tools into toolsets. With no toolsets parameter you get core, which covers what a coding agent needs most:

• Logs: search_datadog_logs returns log lines by query, service, host and time; analyze_datadog_logs runs SQL for counts and aggregations, such as errors by service in the last hour.
• Metrics: get_datadog_metric queries a metric over time, get_datadog_metric_context lists its tags and values, and search_datadog_metrics finds metric names.
• Monitors and incidents: search_datadog_monitors shows statuses and thresholds, including which are alerting; search_datadog_incidents and get_datadog_incident read incidents, without timeline data.
• Traces: search_datadog_spans filters spans by service, resource and error, and get_datadog_trace fetches a whole trace by ID, truncated when it has thousands of spans.
• Context: search_datadog_events for deploys and alerts, search_datadog_hosts, search_datadog_dashboards, search_datadog_entities for service ownership and dependencies, and RUM search.
• Writes in core: create_datadog_notebook and edit_datadog_notebook, for writing up an investigation.

Other generally available toolsets add alerting, including create_datadog_monitor, dashboards, Error Tracking, Kubernetes, database monitoring, CI Visibility and more. Every tool definition costs context, so add only the toolsets the work needs; MCP token usage explains why.

https://mcp.datadoghq.com/v1/mcp                             # core tools
https://mcp.datadoghq.com/v1/mcp?toolsets=core,alerting      # core plus alerting
https://mcp.datadoghq.com/v1/mcp?toolsets=all&omit_tools=create_datadog_notebook,edit_datadog_notebook

The address comes from Datadog’s MCP server repository↗ (opens in a new tab). On another Datadog site, replace mcp.datadoghq.com with that site’s domain, such as mcp.datadoghq.eu. omit_tools is applied after toolsets, so it is how you remove the write tools from an otherwise full set.

Setup in Claude Code

Datadog recommends its plugin from Anthropic’s official marketplace, which bundles the server with skills. Run /plugin install datadog@claude-plugins-official, then /ddsetup to choose your Datadog site and sign in, and /ddtoolsets to turn toolsets on or off. After a change, run /reload-plugins. If you use the plugin, remove any manual Datadog entry first so the two do not conflict. Without the plugin, add the server by hand:

claude mcp add --transport http datadog "https://mcp.datadoghq.com/v1/mcp?toolsets=core,alerting"

Then type /mcp inside Claude Code, choose datadog and complete the browser sign-in. If a server will not connect, Claude Code MCP not working walks through the checks.

Setup in Cursor

Install the Datadog plugin from the Cursor Marketplace, or from Cursor Settings, then Plugins, and type /ddsetup in the agent chat. The plugin includes the MCP server. Many clients, Cursor among them, also accept a plain entry with the endpoint as a url:

{
  "mcpServers": {
    "datadog": { "type": "http", "url": "https://mcp.datadoghq.com/v1/mcp" }
  }
}

Setup in VS Code

For GitHub Copilot in VS Code, Datadog points to its Copilot plugin. The alternative is the Datadog extension for VS Code: install it, sign in, restart the editor, and run Datadog: Open MCP Configuration Assistant from the Command Palette. Datadog notes that the MCP connection belongs to Copilot, not to the extension, so you authorize the server separately. Where VS Code stores the entry is in the VS Code mcp.json guide.

Sign-in options

The setup page↗ (opens in a new tab) lists four ways to authenticate, in order of preference:

• OAuth 2.0, recommended: the client runs the browser flow and you hold no long-lived credential. If your organization signs in on a custom subdomain, add subdomain= to the endpoint.
• A personal or service access token, sent as a bearer token in the Authorization header, for servers and CI where no browser is available.
• An API key and application key in DD_API_KEY and DD_APPLICATION_KEY headers. Datadog advises keys from a service account that has only the permissions it needs.
• A local binary, datadog_mcp_cli, which signs in once and runs over stdio, for clients where remote sign-in is unreliable.

A key in a config file is a secret on disk, so keep it out of anything you commit. How the browser flow works is in how MCP sign-in works.

Permissions and data sensitivity

• Two role permissions gate the server: mcp_read for tools that read and mcp_write for tools that create or change things, such as creating monitors or muting hosts. Each tool also needs the ordinary permission for its resource. The Datadog Standard Role has both MCP permissions by default; custom roles need them added.
• Administrators can switch MCP access, and write capability, on or off for the whole organization, and an IP allowlist limits where connections can come from.
• To limit what the agent can read, use the controls you already have: role-based access, Data Access Control for sensitive logs and spans, and log restriction queries.
• Where data goes: Datadog says the server does not send your data to a third-party AI provider, but your client sends whatever the tools return to its own model. A few tools, such as natural-language query builders, use models hosted by Datadog’s AI providers. Datadog also keeps usage data about the server, including prompts that led to a tool call, for 120 days.
• Every tool call is recorded in Datadog Audit Trail with the tool, arguments, user and client, and the datadog.mcp.tool.usage metric counts calls by user and tool.
• Treat log lines as untrusted. Anyone who can reach your API can put text into your logs, including instructions aimed at an agent; see indirect prompt injection.

For a coding agent, read tools are usually enough. Leave out alerting and dashboard writes, or remove them with omit_tools, unless the session is for setting up monitoring. The wider checklist is in MCP security best practices.

From alert to task

An alert says something is wrong; a task says who will fix what. Between them sits a short investigation, which is exactly what the agent is good at. The full tool list in Datadog’s tools reference↗ (opens in a new tab) includes example prompts for each tool. A prompt that reads before it writes:

List the monitors alerting for service:checkout-api. For the worst one, pull
the error logs and two failing traces from the last hour, and check for a
deploy event just before it started. Tell me the likely cause and the file.
Then search the fenbs board. If no task covers it, file a bug with the
monitor link, the evidence and your guess at the cause, using the monitor
ID and group as the key. Do not change any code yet.

With fenbs connected as a second MCP server at https://fenbs.ai/api/mcp, the bug lands in To Do with a BUG- reference, a note that states the problem, and room for a plan, a test status and a priority from 1 to 10. fenbs_create_item takes a key from an automated source, so a monitor that fires again returns the existing task instead of filing a duplicate. When the fix ships, the assistant sets the test status and test notes from what the metrics show and moves the task to Completed. History records each step under the assistant’s name. fenbs does not watch Datadog or receive alerts itself; the agent carries them across.

The same pattern with errors rather than telemetry is in Sentry MCP. Watching what your agents themselves do is a different job, covered in AI agent observability and MCP server logging.