Datadog MCP
ReviewAudited by ClawScan on May 10, 2026.
Overview
This appears to be a legitimate Datadog integration, but it uses sensitive Datadog keys and can expose production observability data to the agent.
This skill is coherent and purpose-aligned for Datadog observability. Before installing, create a dedicated least-privilege Datadog application key, select only the MCP toolsets you need, avoid enabling workflow execution unless you want the agent to trigger automation, and prefer the Datadog-hosted MCP endpoint over the optional unpinned local npm package.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the agent is configured with a powerful Datadog app key, it can access whatever Datadog data and actions that key allows.
The skill requires Datadog API and application keys, and the documentation correctly discloses that those keys can carry organization-level access based on the creating user's permissions.
- API keys grant read access to your Datadog org — treat them as secrets - Application keys inherit the permissions of the user who created them - Use scoped application keys with minimal permissions for production
Use a dedicated, scoped Datadog application key with the minimum read permissions needed, and avoid write permissions unless required.
Production logs, traces, host details, and incident information may be visible to the agent and may appear in chat context or transcripts.
The skill retrieves logs and traces into the agent's working context. That is purpose-aligned, but observability data can contain sensitive details or user-controlled strings.
| `logs` | `get_logs` | Search and retrieve log entries | | `traces` | `list_spans`, `get_trace` | Investigate distributed traces |
Query narrowly, avoid pulling unnecessary sensitive records, and treat returned log content as data rather than instructions.
If workflows are enabled with write-capable credentials, the agent may be able to trigger automation that affects Datadog or connected systems.
The skill documents an optional capability to execute Datadog workflow automation, which may be state-changing depending on the user's Datadog workflows and key permissions.
- **Trigger workflows** — execute Datadog Workflow Automation
Do not enable the workflows toolset unless needed, use scoped credentials, and require explicit human confirmation before executing workflows.
Using the local option means trusting the npm package you run with your Datadog credentials.
The optional local stdio setup runs a community npm package through npx and passes Datadog credentials to it. This is user-directed and disclosed, but the package version is not pinned in the example.
npx datadog-mcp-server \ --apiKey "$DD_API_KEY" \ --appKey "$DD_APP_KEY"
Prefer the Datadog-hosted remote MCP server, or pin and verify the npm package before using the local stdio option.
Users might underestimate that query results are still delivered into the agent's context, even if the MCP server itself is hosted by Datadog.
The architecture correctly shows that selected data is returned to the agent, while also using broad wording that could be read as saying no data leaves Datadog at all.
6. **Agent receives context** — uses the data to answer the user ... **Data stays in Datadog** — logs/traces/metrics never leave the platform
Interpret the privacy claim as meaning no third-party MCP host is involved, and handle returned Datadog data as sensitive agent context.