Reported issues for datadog-mcp
Pod holds 12 of 12 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to datadog-mcp.
Most discussed
monitors get/update: expose the options object
Summary
The monitors tool's action: get returns a simplified monitor view that omits the options object (notify_audit, renotify_interval, notify_no_data, no_data_timeframe, timeout_h, include_tags, escalation_message, silenced groups, etc.). Datadog's own GET /api/v1/monitor/{id} returns these, so they're being stripped by the MCP layer.
This makes action: update dangerous in practice because you can't see the current option values before changing them.
Repro
{ "actio
[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/51) · 2026-04-22 · closed · 4 comments
### slos get/update: `query` (numerator/denominator) is omitted from get, but required by update — round-trip edits impossible
## Summary
The `slos` tool's `action: get` returned SLO metadata (name, type, thresholds, timeframe, tags, status) but **omitted the `query` object** (`numerator` / `denominator` for metric SLOs, or `monitor_ids` for monitor SLOs). Datadog's own [GET /api/v1/slo/{slo_id}](https://docs.datadoghq.com/api/latest/service-level-objectives/#get-an-slos-details) returns these, so they were being stripped at the MCP layer.
This made `action: update` unusable for any field-level edit (tags, name, descr
[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/55) · 2026-05-13 · closed · 2 comments
### UX feedback from extended investigation session — DX improvements
## Context
Collected during a ~4h extended DevOps investigation session (Nginx 5XX monitor tuning). Session involved creating SLOs + burn-rate monitors, analyzing 60-day metrics, and auditing 30-day events. What worked well and what slowed the workflow down.
## What worked well
- `monitors`, `slos`, `events`, `metrics` action-based API is coherent and predictable
- Parallel calls work cleanly (created SLO + 2 monitors in one message)
- Events search returns structured JSON (jq-friendly)
- SLO
[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/49) · 2026-04-21 · closed · 2 comments
### preview action rejects valid Datadog is_match / is_exact_match tag conditionals
## Summary
The `monitors` tool `preview` action rejects monitor messages that use Datadog's **tag-variable conditionals** `{{#is_exact_match "...""...}}` and `{{#is_match "...""...}}`, even though these are valid, documented Datadog monitor message syntax.
## Error
MCP error -32603: EUNSUPPORTED_TEMPLATE_SYNTAX: loops are not supported (found {{#is_exact_match "tag.name" "value"}}). Supported syntax is {{variable.name}} and conditionals {{#name}}...{{/name}} / {{^name}}...{{/name}} where
Read the thread · 2026-06-17 · closed · 1 comment
monitors update: config parameter is a free-form object — no schema, no guidance on which Monitor options pass through
Problem
The monitors action=update (and create) tool accepts a config: object, additionalProperties: {} parameter. There is no schema, no enum of supported keys, and no documentation about what fields make it through to Datadog's underlying PUT /api/v1/monitor/{id}.
For common alert-tuning workflows — adjusting thresholds, renotify cadence, notify_audit, notification preset, escalation message, evaluation delay, etc. — callers can't tell whether the MCP will:
- Accept the field and
Read the thread · 2026-05-05 · closed · 1 comment
Events API doesn't expose monitor-alert-event / monitor-audit-event sources — counting actual monitor fires is impossible
Problem
Counting how many times a monitor actually fired (state transitions OK→Alert, equivalently the Slack notifications it sent) is the most common operational question for alert-hygiene work. None of the existing actions answer it correctly:
| Tool | Returned for one always-Alert SLO burn-rate monitor over 7d | Issue |
|---|---|---|
monitors action=top |
162 | Datadog logs an event every time the monitor re-evaluates while in Alert (≈1/min). Most aren't notifications. |
| `events ac |
Read the thread · 2026-05-05 · closed · 1 comment
Add tools for Logs Pipelines, Indexes, and Archives configuration
Summary
The MCP currently exposes runtime logs access (logs search/aggregate), but not the configuration of Datadog's log management (pipelines, indexes, archives). These configs have fully-documented public APIs and would close a real investigation gap.
Motivation
When investigating why certain logs are missing from monitors, alerts, or Watchdog analysis, operators need to verify:
- Which pipeline processors are applied to a service's logs (grok parsing, remappers, lookups)
Read the thread · 2026-04-22 · closed · 1 comment
fix: SLO list action returns null for sli/errorBudgetRemaining/state
Problem
The slos tool list action returns null for all status fields:
{
"status": {
"sli": null,
"errorBudgetRemaining": null,
"state": "unknown"
}
}
Meanwhile the Datadog UI shows the real values (e.g. SLI: 99.696%, error budget: -203%).
The history action correctly returns the SLI value, so the data is accessible — it's just missing from list.
Root cause
The Datadog [List SLOs API](https://docs.datadoghq.com/api/latest/service-level-objectives/
Read the thread · 2026-02-10 · closed · 1 comment
Most recent
Feature: traces action=dependencies — return caller→callee edges instead of re-deriving the graph from aggregate
There is no first-class way to ask "who calls whom". Dependency direction is the main input for cascade root-cause analysis — deciding whether the alerting service is the cause or a victim of something downstream — and today every consumer has to re-derive it.
What works today, and what it costs
traces action=aggregate with groupBy: ["service", "peer.service"] does produce caller→callee edges with counts. But getting there requires the caller to already know three things:
- that `pee
Read the thread · 2026-07-27 · open · 0 comments
traces action=aggregate silently truncates groupBy buckets — no cursor, no truncation flag in meta
traces action=aggregate with a groupBy can return a partial bucket list with nothing in the response indicating it is partial. A truncated aggregation is byte-for-byte indistinguishable from a complete one, so a consumer reads "this group has no rows" when the group simply was not in the returned page.
Observed
groupBy: ["service", "peer.service"],limit: 100→ 39 buckets returned, ordered alphabetically by the first key and cut off partway through the alphabet. Every service
Read the thread · 2026-07-27 · open · 0 comments
monitors action=mute ignores 'scope' param — mutes the entire monitor instead of the group
Summary
monitors tool, action=mute with a scope argument does not mute the targeted multi-alert group scope — it mutes the whole monitor.
Steps to reproduce
Call the mute action on a multi-alert monitor with a group scope:
monitors action=mute id=123456 scope=host:web-01
Expected
Only the host:web-01 group is silenced:
"silenced": { "host:web-01": null }
(equivalent to Datadog POST /api/v1/monitor/{id}/mute?scope=host:web-01)
Actual
The entire mo
Read the thread · 2026-07-15 · open · 0 comments
datadog_url in traces/logs results opens in live 'past 15 min' instead of the queried time window
The traces and logs tools return a datadog_url so users can open the query in the Datadog UI. The URL includes the time range (start/end for APM, from_ts/to_ts for logs), but it does not lock the time picker, so the UI opens in live mode and immediately resets to the default Past 15 minutes window — the queried range is lost. This is especially visible when querying historical windows (e.g. several days ago): the link lands on "now − 15 min", showing no data.
Cause
T
Read the thread · 2026-06-30 · open · 0 comments
The remaining reports are on the project's issue tracker.