obsdog
Platform and pricing

MCP Server

The MCP Server (Datadog MCP Server) is the bridge that stands between AI agents supporting the Model Context Protocol (MCP) and Datadog's observability data. It lets AI agents pull metrics, logs, traces, and more through tool calls.

About 6 min read

Overview

The MCP Server is Datadog's implementation of the Model Context Protocol (MCP), the connection point through which AI agents such as Cursor and Claude Code pull Datadog data via tool calls. The connection is made with an OAuth login, and the permissions of the user who made the call apply as is, so information that person cannot see in the UI cannot be retrieved. This entry is based on the official documentation as of September 2026, and because the documentation itself explicitly states that it is under heavy development, the supported agents, tools, and usage limits may change. It matters when you want to let AI agents work with Datadog and when you decide the scope of their permissions.

A bridge between AI agents and Datadog

The MCP Server is the bridge that stands between AI agents supporting the Model Context Protocol (MCP) and the observability data in Datadog. The official documentation explains it as providing structured access to Datadog's context, features, and tools, so that observability insights can be pulled directly from AI-powered development environments. MCP is a common convention for AI agents to connect to external tools and data, and Datadog provides the server side of it. The official documentation explicitly states that it is "under heavy development," and the supported agents and the set of tools may change, so check the official setup page when you adopt it (as of September 2026, Source: Datadog MCP Server).

From which agents, and how to connect

The connection procedure for each agent is collected on the official setup page (as of September 2026, Source: Set Up the Datadog MCP Server). The targets include Cursor, Claude Code, Gemini CLI, VS Code, Codex, ChatGPT, Claude, and Kiro. The skeleton is the same for all: register the MCP Server endpoint corresponding to your Datadog site in the agent and complete the OAuth login. Tools are divided into toolsets by product; you select the groups to enable with the toolsets parameter in the endpoint URL and can remove individual tools with omit_tools. This is a mechanism to avoid loading tools for products you do not use into the AI's context. Many tools also have a max_tokens parameter, so the caller can adjust the volume of the response (as of September 2026, Source: Datadog MCP Server).

Tools are divided into groups by product

The toolset each tool belongs to, the required permissions, and example prompts are listed on the official tools page (as of September 2026, Source: Datadog MCP Server Tools).

Toolsets and examples of representative tools
ToolsetRepresentative tools
Core toolssearch_datadog_logs / get_datadog_trace / search_datadog_monitors / get_datadog_metric
Alertingcreate_datadog_monitor / validate_datadog_monitor / search_datadog_slos
APMapm_search_spans / apm_latency_bottleneck_summary / apm_search_watchdog_stories
OthersPer-product groups such as Dashboards / Database Monitoring / RUM / Security / Workflows
Source: Datadog official documentation Datadog MCP Server Tools (as of September 2026, excerpt)

Most are search and retrieval, but there are also tools that create monitors and notebooks. Write tools are subject to the permission checks described in the next section. The tools page also explicitly states that the set of tools is "under heavy development and may change."

Whose permissions it runs with, and how to narrow them

The MCP Server calls the Datadog API with the credentials of the authenticated user. The data flow is left to the table in the explanation of Bits AI. The means the official documentation lists are three: granting permissions per role with RBAC, restricting who can read sensitive data (logs and APM spans) with Data Access Control, and narrowing the logs a role can read with log restriction queries. Write tools require the corresponding permission such as monitors_write, which is checked on every call, and calls from read-only users are rejected (as of September 2026, Source: Datadog MCP Server). Before cutting a separate key for AI, the proper course is to get in order what that user's role can see. Depending on the agent, some procedures ask you to enter an API Key and an Application key (as of September 2026, Source: Set Up the Datadog MCP Server).

Three things to watch after enabling it, and the difference from Bits AI

How to keep watch after enabling it is also in the official documentation (as of September 2026, Source: Datadog MCP Server).

  • Search for the event name MCP Server in Audit Trail and follow the tool name, arguments, user, and client used
  • Look at the metrics datadog.mcp.session.starts (session starts) and datadog.mcp.tool.usage (tool calls) grouped by user_email or client. The latter is a distribution metric, so count occurrences with count plus .as_count() rather than sum
  • Check whether you are approaching the fair use limits (a burst of 50 requests per 10 seconds, and 50,000 tool calls per month). The documentation explicitly states that the limits may change, and you can consult support if needed
Source: Datadog official documentation Datadog MCP Server (as of September 2026)

To put the difference from Bits AI in one sentence: Bits AI is the AI that runs inside Datadog, and the MCP Server is the opening that hands Datadog to AI agents outside. You care about the MCP Server when you want to pull from Datadog directly from the AI agents developers use, and when you decide who gets to see how much before allowing that; the three points above are how you protect it.

Share

Related terms

Role-Based Access Control (RBAC)API KeyOrganization

Related products

Bits AIAPMLog Management

Related articles

Datadog Adoption Checklist - Judging the Payoff by Scale and RequirementsThis article breaks down the structure behind the reputation that "Datadog is expensive" and organizes it into a form that lets you judge which kinds of organizations, at which scale, can recover the investment. It includes a step-by-step expansion procedure that starts from the Free plan and a checklist of items to settle before adoption.Datadog Annual Contracts vs On-Demand - How to Read the Three Unit Price ColumnsDatadog's price list shows three unit prices side by side: annual contract, monthly contract, and on-demand. Following the official documentation, this article organizes what the three columns mean, the reality that how the gap is set changes with the type of SKU, how usage beyond the contracted volume is treated, and the order in which to build an estimate. For current unit prices, refer to the official pricing page.Datadog Cost Review in the 30 Days Before Contract Renewal - A 10-Item Reduction ChecklistFor organizations whose annual contract renewal is one month away, this article rearranges the work of lowering the bill into four checkpoints: 30 days before, 14 days before, 7 days before, and the day itself. The 10 reduction items show only the key points and where each is delegated, leaving the procedures for checking the numbers to the existing explanations. It also places, up front, the one question you should pass through before cutting anything.How to Decode Datadog's Pricing Structure - Billing Units by SKU and How to Prevent Billing AccidentsThis article lays out the order in which to decode Datadog's pricing structure, where each product has a different billing unit. Beyond how to read the price list, it goes into the rules for counting usage and the typical patterns of billing accidents that throw estimates off.How to Check Your Datadog Costs - The Usage Screen and Usage AttributionYour Datadog bill is not something you learn for the first time from the invoice at month end. This article organizes the three places to check - the Plan & Usage usage screen, Usage Attribution for allocating by tags, and the usage metrics you can put on monitors - as a procedure, down to what to look at in what order.

Similar terms / articles

Bits AIA family of generative AI features that lets you question the monitoring data stored in Datadog in natural language and delegate alert investigation, code fixes, and first-pass security triage. This article draws the line between what to delegate and where a human decides, within the scope of the official documentation.Fleet AutomationFleet Automation is a Datadog feature that lets you get a grip on the Datadog Agents and OpenTelemetry Collectors scattered across your environment from a single screen and API, and remotely check configurations, upgrade, and send diagnostic information for support. You use it when the number of Agents has grown to the point where you can no longer look after them one at a time.LLM ObservabilityLLM Observability records a single request to an application with an embedded LLM as a trace, tracks the inputs and outputs, tokens, latency, and errors of each model call, and turns response quality into numbers through evaluations. The only thing billed is the LLM span, which represents a model call.WatchdogWatchdog is the automatic anomaly detection feature built into Datadog. Without the user configuring any conditions or thresholds, it learns a baseline of the normal behavior of metrics and logs, finds movements that stray from it, and lets you know. Its role is to watch the area outside the net of the monitors you build yourself.