Your agent reads Datadog.
Only what you could, and on the record.
The Datadog MCP Server makes Datadog a tool for the agents you already use. Claude Code, Cursor, Codex and the rest ask it for the logs, the traces, the monitors and the dashboards, instead of you copying them in. It runs with the user's own credentials, cannot grant more than the user has, and writes every tool call to Audit Trail. We set it up, scope the toolsets and the data each role can reach, and review each month what the agents asked.
Quick facts
Related
- Agent Observability, observing the agents that use this server
- Access Control, the roles that bound what the agent can read
- Pup CLI, the same access from the terminal and the pipeline
The context the engineer was pasting in, fetched instead
An engineer is debugging in their IDE with an assistant. The assistant needs the error logs. The engineer opens Datadog, searches, copies forty lines, pastes them, and the assistant asks for the trace. The MCP Server removes the copying: the assistant asks Datadog directly, as that engineer, for exactly what the engineer could have searched for.
Datadog as a set of tools. Search logs, query metrics, list monitors, read a dashboard, fetch a trace, look up a security signal, run a Bits Investigation. The tools are grouped into toolsets, and the code execution tool lets an agent run a script across several of them in one call.
The user's credentials, and no more. The server uses the signed-in user's own credentials for every Datadog API call. It cannot grant access the user does not have. RBAC, Data Access Control and log restriction queries narrow what comes back, exactly as they would in the browser.
Writes are checked, per call. The server is not read-only. A few tools change things, and each checks the specific permission, such as the one for writing monitors, before it runs. Which toolsets are enabled is set in each client's configuration, with only the core toolset on by default, so someone has to own that choice.
Every call on the record. Each tool call is written to Audit Trail with the tool name, the arguments, the user and the MCP client that made it, and two metrics track sessions and tool usage. What the agent read is a search, not a guess.
Every toolset on, an admin's credentials in a developer's IDE, and an Audit Trail nobody searches
How it bills. Datadog's documentation and pricing list no meter for the MCP Server itself. The documentation describes fair-use limits on tool-call bursts and on tool calls per month, which can be raised through support. Work that another product meters is metered there whichever client asked for it, so a Bits Investigation started through MCP draws on AI Credits. Datadog describes the server as under significant development, and a few toolsets, including APM, are still in Preview. We publish no rates. The levers are which toolsets are enabled and which roles the connecting users hold.
The configuration traps. The server is connected by whoever had the broadest role, and their IDE assistant now reads everything that role can. Every toolset is enabled, including the ones that write, because the setup guide listed them. Data Access Control was never configured, so a question about one customer's session returns every customer's. The Audit Trail records every call faithfully and nobody has a saved view or a monitor on the MCP Server event, so the first review of what the agents read happens during the first incident. The code execution tool runs agent-written scripts across several products, which is efficient and also the broadest single thing a tool can do. Each of these is the server doing exactly what the role allows, with the role set for a person and not for the agent acting as them.
Field noteThe most common gap we see is the role, not the server. The MCP Server respects permissions exactly. The permissions were set years ago for a platform team that needed everything, and the agent inherits that view the moment the team lead connects it.
Field noteThe pattern we keep finding is the agent nobody knew was connected. A developer set it up from the documentation in an afternoon, it worked, and the only evidence it exists is the Audit Trail entries nobody has searched for.
Field noteThe client is configured with the all alias because it was quicker than choosing, and with it come the tools that update and delete dashboards. An assistant asked to tidy up deletes the one the on-call rota uses. The permission check passed. The person had the permission. The agent was never meant to use it.
Field noteThe teams that get the most from the server are the ones who built the saved Audit Trail view first. They can answer "what did the agent read?" in a search, which is the question every security review asks and the question the agent's output never answers.
Scope the roles. Enable the toolsets you mean. Save the Audit Trail search before the first client connects.
We start with a Datadog HealthScan, read-only and fully automated, which reports which users have connected an MCP client, which toolsets are enabled, what the Audit Trail shows them asking and what the usage metrics show. The setup then runs within Managed Observability onboarding.
- Decide who connects, and as what. The users and teams who should have an agent reading Datadog, and the roles they hold. A role designed for a person browsing is reviewed before an agent inherits it.
- Set Data Access Control and log restrictions. Restriction queries and data access rules so an agent asking about one customer, one environment or one team gets that and nothing else, regardless of which engineer is signed in.
- Enable the toolsets deliberately. Read toolsets for the products the teams use. Write toolsets off by default, and on only for a named role that has agreed what an agent may change. The code execution tool is a separate decision.
- Build the Audit Trail view and monitor. A saved search on the MCP Server event, a dashboard from the session and tool-usage metrics, and a monitor on unexpected clients, unexpected users or write tools being called.
- Connect the clients. Claude Code, Cursor, VS Code, JetBrains or whatever the teams use. Each user connects with their own credentials from the official setup. The configuration is checked into the team's standard tooling, so nobody improvises it.
- Hand over the register. Who is connected, with which client, under which role, which toolsets are on and why, and the saved searches that answer "what did the agent read?" in one query.
Access is admin on the Datadog organisation for roles, toolsets and Audit Trail. Each user connects their own client with their own credentials; we specify the configuration and hold no credential of yours.
A server under significant development changes what a tool can do between one month and the next
New tools appear, toolsets are reorganised, a client gains a capability. The roles that bound the agent were set against last month's tool list. Managed Observability is the monthly service that reads the Audit Trail, checks the scope and keeps the register true.
Every month, the Audit Trail is read. Tool calls by user, by client and by tool, against the register. New clients, new users and write calls are investigated. A pattern of the same question is a dashboard somebody should have.
Scope follows the org chart. When teams change, the roles the agents inherit are checked, and Data Access Control is updated in the same week. A person who left is a client that should have stopped calling.
The toolsets are kept honest. New tools Datadog adds are reviewed before they are enabled, not after an agent has used them. Write toolsets are confirmed quarterly with the role that owns them.
The agent's question can become our incident. When what an agent surfaces needs fixing in the runtime we operate, it becomes a work item and under Critical Support our engineer takes it. The agent read the data. A person acts on it.
We operate the stack. You own the product.
We connect our own agents to Datadog through the same server, under the same rules we set for customers. A role designed for the agent. Write tools off unless someone owns them. An Audit Trail search that answers what was read. An implementation partner follows the setup guide and leaves. A managed partner reads the Audit Trail every month. We are the second kind. The roles, the toolsets and the register stay in your Datadog, and you can take it in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
The Datadog MCP Server, answered plainly
Is the Datadog MCP Server generally available?
Datadog describes the server as under significant development. Most toolsets are generally available; a few, including the APM toolset, are in Preview and have to be requested by name. It is in use with Cursor, OpenAI Codex, Claude Code, VS Code, JetBrains IDEs, Claude, Copilot CLI and other clients, and it is not available on the Datadog government sites. The tool list and the toolsets change between releases, which is why we review what is enabled every month rather than once at setup. The separate Code Security MCP Server runs locally for code scanning and is a different product.
How is the Datadog MCP Server billed?
Datadog lists no meter for the server itself. It documents fair-use limits on tool-call bursts and on tool calls per month, which can be raised through support. Work that another product meters is metered there, so a Bits Investigation started through MCP draws on AI Credits. We do not publish prices. We decide which toolsets are enabled and which roles may connect, which is what bounds the usage.
Can an agent see more than the engineer who connected it?
No. The server uses the signed-in user's own credentials for every Datadog API call, cannot grant access the user does not have, and applies RBAC, Data Access Control and log restriction queries exactly as the browser would. The practical risk is the reverse: the engineer's role was designed for a person browsing, and the agent inherits all of it. We review the roles that agents inherit before the first client connects, and set data access rules so a question about one customer returns one customer.
Can an agent change things through the MCP Server?
Some tools can. The server is not read-only: a few tools write, and each one checks the specific permission, such as the one for writing monitors, on every call. Which toolsets are enabled is set in each client's configuration, with only the core toolset on by default, so someone has to own that choice. We leave the tools that write off by default and enable them only for a named role that has agreed what an agent may change. Every call, read or write, is recorded in Audit Trail with the tool name, the arguments, the user and the client, so what an agent did is a search rather than a guess.
What does Critical Cloud do with the MCP Server every month?
Under Managed Observability we read the Audit Trail: tool calls by user, client and tool against the register, with new clients, new users and write calls investigated. We check the roles the agents inherit against the current org chart and update Data Access Control. New tools Datadog has added are reviewed before they are enabled, and the write toolsets are confirmed quarterly with the role that owns them. Where what an agent surfaces needs fixing in the runtime we operate, it becomes a work item and under Critical Support our engineer takes it.
- Datadog products: every product, and how we implement and run each one
- Claude and MCP for Datadog: what it looks like in practice
- Datadog HealthScan: read-only and fully automated, reports who has connected an MCP client and what the Audit Trail shows them asking
- Agent Observability: tracing the agents that call this server
- Audit Trail: where every tool call is recorded
An agent that reads what you could, on the record.
Tell us which assistants your engineers use and who has already connected one. We will show you what the Audit Trail says they have read, what the roles should be, and which toolsets should be on.