Secure Datadog access for AI agents
Metrics, logs, traces, dashboards, incidents, monitors, and notebooks via Datadog's official MCP server.
Through Datadog, agents can query metrics, search logs and APM traces, read dashboards, incidents, monitors, and notebooks, and walk your service topology. Every call runs through your policies and is logged for audit.
Server URL: https://mcp.datadoghq.com/v1/mcp
Credential modes
Datadog supports per-org dynamic registration only, so there is no app to create on Datadog's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.
Before you begin
- A Datadog account that can reach the metrics, logs, and dashboards your agents need.
- Administrator access to your Agent Authority workspace, to add the resource.
Setup
- In the Agent Authority console, go to Tools & Services and click Add Resource.
- Select Datadog from the catalog.
- On Choose how to install Datadog, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.
Dynamic client registration
When you add the resource, the gateway registers its own OAuth client with Datadog, the credential that lets it sign users in. Datadog's own organization and role-based permissions still apply, so an agent can only reach what the person who signed in could already reach.
Verify the connection
The gateway syncs the Datadog tools automatically. To check the connection end to end, ask your agent to run a request:
Search my Datadog monitorsIf your monitors come back, the connection is working.
How users connect
Access is per user. Each additional user connects their own Datadog account the first time their agent calls a Datadog tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.
Available tools
All tools are read-only.
| Tool | Tags | Description |
|---|---|---|
aggregate_events | read-only | Aggregate events (counts, sums, percentiles) grouped by field/time |
aggregate_rum_events | read-only | Aggregate RUM events (sessions, errors, load times) |
aggregate_spans | read-only | Aggregate APM spans (request counts, durations, error rates) |
analyze_datadog_logs | read-only | Run SQL analysis against a virtual logs table |
get_change_stories | read-only | Get change events (deploys, scaling, config) for an APM service |
get_datadog_dashboard | read-only | Get a dashboard's title, description, tags, and widgets |
get_datadog_incident | read-only | Get incident details, timeline, and follow-ups |
get_datadog_metric | read-only | Query metrics data (timeseries or scalar) |
get_datadog_metric_context | read-only | Get a metric's metadata, tags, and related assets |
get_datadog_notebook | read-only | Get a notebook by ID |
get_datadog_trace | read-only | Get an APM trace's spans by trace ID |
list_datadog_skills | read-only | List available Datadog skill guides |
load_datadog_skill | read-only | Load a Datadog skill guide |
search_datadog_dashboards | read-only | Find dashboards by title, widget, team, or author |
search_datadog_events | read-only | Search raw events |
search_datadog_hosts | read-only | Query the hosts inventory with SQL |
search_datadog_incidents | read-only | Search incidents by state, severity, team, or semantic query |
search_datadog_logs | read-only | Search raw logs or log patterns |
search_datadog_metrics | read-only | List available metrics |
search_datadog_monitors | read-only | Find monitors by title, status, team, or tag |
search_datadog_notebooks | read-only | Find notebooks by author, type, or content |
search_datadog_rum_events | read-only | Search raw RUM events |
search_datadog_service_dependencies | read-only | Get upstream/downstream service dependencies |
search_datadog_services | read-only | Find services by name or team |
search_datadog_spans | read-only | Search raw APM spans |
Required scopes
The gateway does not request a fixed scope list for Datadog. It registers the client without naming any scopes and records the ones Datadog returns.
Policy examples
Rules are evaluated top to bottom and the first match wins. Allow rules on their own restrict nothing: your org starts with a seeded Allow all rule, so any tool your allows don't cover still falls through to it. Narrowing access needs a catch-all deny scoped to this resource, ordered below the allows. New rules are inserted at the top of the list, so create them in reverse order or drag them into place. See Policies.
- Observability triage only. Allow
search_datadog_logs,search_datadog_incidents,get_datadog_incident, andsearch_datadog_monitors, then deny*below them so no other Datadog tool falls through to Allow all. - Keep Datadog out of an agent's reach entirely. Deny
*scoped to this resource and to that agent, above the seeded Allow all rule.
Since every Datadog tool is read-only, these examples limit what an agent can see rather than what it can change.
Next steps
- Create a policy – start from the triage pattern in Policy examples above.
- Policies – how rule order, scoping, and the seeded Allow all rule interact.
- Connections – manage the Datadog accounts your users have linked.