Your on-call engineers read Datadog all day. Claude is now open beside it. Somebody has asked whether Claude can pull the last hour of monitor state instead of three browser tabs. The request to connect Datadog to Claude for our SRE team is reasonable. The work splits into four decisions. Which Datadog connector, who signs in, which tools the role may call, and what the audit log shows afterwards.
Claude reaches Elaichi over MCP: MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Every Claude client signs in at the same address, https://api.elaichi.ai/mcp. There is no SRE-specific URL to hand around. What differs between people is the OAuth grant behind their token. A grant is the approval one person gives one named client on Elaichi's consent screen. Every call made with it acts as that person, in the organization they picked.
Connect Datadog to Claude for our SRE team: who builds the server, who governs it
Datadog builds and runs the MCP server. Elaichi handles sign-in, access and audit in front of it. In Elaichi's catalog Datadog is a native MCP connector: a vendor's own remote MCP server that Elaichi staff publish once for every organization. There is one connector per Datadog region. The regions share a single Datadog connector page, which lists them. Your first decision is which region the account lives in.
Elaichi does not write, test or curate that server's tools. The tools a person can call are the ones Datadog's server lists to that person's own connection. Reports about those tools go to the vendor's support contact, shown on the connector's page in the console. Each engineer connects with their own Datadog sign-in, so their own Datadog permissions apply. A connection somebody shares runs on its owner's account instead. That is the wrong default for a rota. Elaichi never forwards its own MCP access token to a remote server. Datadog's server only ever sees a token its own authorization server issued.
Tools are discovered per connection, because different accounts see different tools. Discovery runs when the connection becomes active, on a manual refresh, and on the organization's daily refresh. It also runs when a call names a tool the connection's list lacks. The wider case for governing a vendor's server is in why vendor MCP servers go through Elaichi.
What Claude's own connector settings can and cannot reach
Claude has real admin controls, and they stop short of what an SRE rota needs. On Team and Enterprise plans an Owner or Primary Owner adds a custom connector from Organization settings > Connectors. They click Add, hover over Custom and choose Web. Each member then finds it under Customize > Connectors and clicks Connect to authenticate (Anthropic, checked October 2026). On Pro and Max the member adds it themselves. The step-by-step Claude setup covers the screens.
Claude connector tool permissions take one of three settings: Always allow, Needs approval or Blocked. Each applies to a whole connector, a category of its tools or a single tool (Anthropic, checked October 2026). The single-tool option does not help here. Elaichi never lists a connected tool by name in a client's tool list. The model finds a Datadog tool with search_tools and runs it with execute_tool. A per-tool rule in Claude therefore acts on execute_tool as a whole. It cannot tell Datadog from Salesforce. Per-app and per-tool control belongs in Elaichi, which is the distinction restricting one tool or the whole app works through.
Claude Code is the same endpoint from a terminal. Its MCP servers live in config files: user and local scope in ~/.claude.json, project scope in .mcp.json (Anthropic, checked October 2026). An admin can filter those with allowedMcpServers and deniedMcpServers in managed settings. Anthropic says server-managed settings are a client-side control, not a security boundary. A user on an unmanaged device can bypass them without admin access (Anthropic, checked October 2026). That is the argument for putting the rule where the call passes. The Claude Code connection guide has the sign-in details.
Restriction one: hold the SRE role to the tools Datadog marks read
Write an allow rule on the SRE role naming the connector's read tools. A restriction says which connectors and tools a role or one member may reach. For a remote MCP tool, the rule names the connector plus the upstream tool name. Restrictions come with Gold, and they bind whatever client sends the call.
Read the connector's Tools tab before writing anything. Elaichi tiers each remote tool from the MCP annotations Datadog's server sends. readOnlyHint true makes it read, and destructiveHint false makes it write. Anything else, including a tool with no annotations at all, counts as destructive. Someone with connector:manage can lower a tier per tool. That override is cleared if the server's own tier later rises above it.
Two traps follow. An allow rule turns on an allowlist for its whole layer just by existing. Once the SRE role carries one, every connector it does not name is blocked for that role. The role also needs whole-connector allow rules for PagerDuty, Jira and anything else it uses. An allow rule also matches the stored operation rather than the label, which is why blocks match tool names but allows do not.
Restriction two: keep the write and delete tools with one person
Block the destructive tier on the SRE role. Then let one person ask for it when an incident needs it. A block beats an allow inside the same layer, so the block stands even if somebody widens the allowlist later. No consent checkbox holds a client to reading a connected app. "Run your connected tools" covers every tier, deletes included, and "Delete data and remove access" covers only Elaichi's own deletes.
From Claude, a grant holding mcp:read or mcp:tools can file the person's own access request. An admin resolves it in the console under Governance > Access requests. That needs member:manage, refuses organization API tokens, and asks the admin to confirm their identity first. No AI client can decide a request, denials included. Approving a tool request that names its connector creates an access grant for that one requester. The grant lifts that tool out of their role's rules. Every other rule, including ones added later, keeps applying.
Know the shape of that grant before leaning on it. The approve call accepts an expiry, but the console does not send one. A grant approved in the console therefore has no end date, and no screen lists or revokes grants. It ends when the member is removed, or when a later approval supersedes it. To take the access back, write a rule aimed at that member personally: A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.
Restriction three: keep the connector off the roles that never asked for it
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Keeping Datadog away from the rest of the company therefore means a block rule naming the connector whole, on each other role that should not reach it. Among the system roles, only Org Owner and Org Admin hold restriction:manage. A rule aimed at a single member also needs restriction:override.
Blocked does not mean invisible, and that is deliberate. search_tools still names a restricted match, flagged restricted, with no schema and no way to call it, plus a count. A connector blocked whole shows as one row. An engineer can see that something exists and file a request rather than guessing. Role and restriction changes reach every surface within about two minutes. Revoking a grant, removing or suspending a member, revoking a share and disconnecting an account are effective on the next call.
The audit query that proves the restrictions are on
One filter and one search. In the console's audit log, set the category to Assistant and search for the connector name. Connected-tool calls sit in the assistant category because their action is assistant.toolbox_tool. The MCP category holds client grants rather than tool calls, which is the wrong turn most people take first. Free text matches each word anywhere in the action, resource type, resource id, acting user id and the event's metadata. The connector name therefore travels with the row.
Each row records the acting person, the connector, and the connection the call actually reached. It also records the tool's advertised and catalog names, plus its classification. Last come the approval facts, the surface, and the MCP client's id when the surface is mcp. The console's detail panel opens with where the call ran ("Using Claude,"). It then says who did what to which item through which connection. The Approval line on a read reads "Didn't need approval because it only read data". On a call from an MCP client it reads "Allowed by the access Claude was granted".
The rules themselves leave their own trail: restriction.created, restriction.updated and restriction.deleted. An admin's approval adds access_grant.granted. Anyone with audit:view reads every event in the organization. Among the system roles that means Org Owner, Org Admin and Auditor. Auditor is a free, read-only role and does not take a billable seat. Elaichi keeps 90 days of audit history. If you want those rows in the Datadog your team already watches, export to your own Datadog comes with the Black plan, which is launching soon. For the field-by-field version, see what an AI agent audit log must capture.
What the audit trail will not show
A refused call writes no row. Restrictions are checked before the executor runs, so a Datadog tool a restriction withheld leaves no audit entry at all. Neither tools/list nor a tool search is an audit entry either. Prove a block with the restriction row plus a test call from a test account, not with an absence in the log.
The rows are also narrower than people expect. A connected-tool row records no argument values, except the one path argument that names the object. It records no argument names and no argument count. A failed call records a fixed error code rather than Datadog's own message. Connected-tool rows carry no duration. None of this is a gap in the governance. It is the boundary of what the log is evidence for.
When your SRE team does not need this
If Datadog is the only app the team wants in Claude, the shorter path is Datadog's own MCP server behind Claude's custom connector. That holds when the team is a handful of engineers who each have their own Datadog login. No second vendor sits in the call, and the permissions are the ones Datadog already enforces. The same reasoning applies to GitHub's own MCP server at a company with SSO.
The case for one governed endpoint starts when the same rota also wants PagerDuty, Jira and Slack. It grows when the restriction has to hold whatever client sends the call. It settles when an auditor asks for one trail across those apps rather than four. The PagerDuty playbook for on-call engineers is the closest sibling to this one. Read when you don't need an MCP gateway yet before you buy anything. The rules layer itself is covered in MCP governance.
