MCP field guide / Datadog
// mcp field guide · observability
A bifurcated profile, and honesty means saying so. For how most teams run it — querying metrics, logs and traces — a guard is genuinely weak, same bucket as Sentry. But the official server has ~25 opt-in toolsets, and the non-default ones reach all the way to delete tools, code execution, and remote shell. The verdict depends on what you turn on.
DEFAULT / READ
WEAKQuery metrics/logs/traces, list monitors/dashboards. No mutation — gating is friction.
MUTE / DOWNTIME
MODERATEMuting a host or scheduling downtime can silently suppress real alerts — quiet and easy to miss.
NON-DEFAULT TOOLSETS
STRONGDelete dashboards/detection rules; Preview execute_code + remote shell — genuinely dangerous.
Official — Datadog MCP Server (hosted, OAuth 2.0, GA with several Preview toolsets). Default toolset is core; ~25 more are opt-in via a toolsets parameter. Described in its own docs as "under significant development."12 Community — @winor30/mcp-server-datadog (local, Apache-2.0, actively maintained): a focused, read-heavy slice with exactly four mutations and no deletes.3
| Tier | Tools |
|---|---|
| read-only | query metrics/logs/traces/spans, list & search monitors, dashboards, incidents, events, hosts, RUM, security signals — the dominant surface on both servers (official core + community) |
| mutating | community: mute_host/unmute_host, schedule_downtime/cancel_downtime. official (non-default): create_datadog_monitor, upsert_datadog_dashboard, update_datadog_security_detection_rule, feature-flag & case writes |
| destructive | official (non-default): delete_datadog_dashboard, delete_datadog_security_detection_rules, delete_rum_metric; and Preview execute_code + a restricted remote-shell run-command |
The premise most people have is right — with an asterisk. "Datadog MCP = read-only observability" holds for the community server and the official core toolset. It stops holding the moment you enable non-default toolsets: the official server ships create/update/delete tools and Preview execute_code / remote-shell actions. The exact delete/mutation inventory and each tool's GA-vs-Preview status evolve — verify per-account against the live tools reference.
Incident triage from chat. Pull the failing monitor, correlate error-tracking issues and recent logs/traces, summarize root cause — pure read.
Ops automation. Mute a noisy host or schedule maintenance downtime during a deploy; create/adjust a monitor.
Security investigation. Query security signals and RUM waterfalls; with the security toolset, triage or edit detection rules.
Dominant read surface → weak — say it plainly. The community server and the official core toolset are overwhelmingly read. Gating queries adds friction with little protective value. This is another honest low-risk read profile; we won't oversell it.
Mute / downtime → moderate. These don't destroy data, but they silently suppress real alerts. A diff — "this will silence alerting on prod-db-3 for 4h" — plus one human approval is exactly the quiet, easy-to-miss action worth a checkpoint.
Non-default delete / execute → strong. Once those toolsets are on, delete_datadog_detection_rules, execute_code, and remote-shell are destructive/arbitrary-execution — squarely justifying approval + honest irreversibility reporting. Deleting a detection rule or running a remote command isn't something a rollback can cleanly undo.
Bottom line: the guard's value here is conditional and scales with which toolsets you enable — near-zero for read-only observability, peaking at delete/execute tools the default config doesn't even expose. Match the control to the configuration, honestly.
ChronoMCP passes the read surface through, flags mute/downtime, and hard-gates delete/execute/remote-shell if those toolsets are on.
Read the quickstart → More MCP profilesProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Datadog, and @winor30/mcp-server-datadog is an independent, unofficial project. The official tools reference is "under significant development"; individual non-default tool names and GA/Preview status are point-in-time and should be re-verified per account. Risk groupings are our classification. Sources current as of Aug 2026.