Find Noisy Datadog Monitors

The run has no repository. Datadog is a connection the org admin saves once: POST /me/connections with type mcp, name datadog, url https://mcp.datadoghq.com/api/unstable/mcp-server/mcp and auth mode oauth. That call answers 202 with an authorize_url the same person opens while signed in to the console. When GET /me/connections shows status connected, the session body names it as connections: ["datadog"]. A key run receives only the connections it names; a name still pending is 422 CONNECTION_NOT_READY. The catalog entry is the US1 site. Another Datadog site is a different server URL, not this one.

The agent starts with search_datadog_monitors, which needs Monitors Read and returns each monitor's status, threshold and alert condition. It then calls search_datadog_events, which needs Events and Timeseries, and keeps the events that are monitor alerts over the last 30 days. Those two reads are the whole inventory: the definition says what would page someone, and the events say what actually did. It does not open dashboards or logs unless a monitor's query is too thin to interpret the threshold.

Ranking is arithmetic on those events, not a guess. Alert count is how many times the monitor entered an alerting state. A monitor is marked recovered-on-its-own when most of those alerts are followed by an OK event inside 5 minutes. Flapping is the same pair repeating: alert, OK, alert, OK, with no longer quiet stretch between them. A monitor with no notification target is one whose definition names no recipient. The top 10 by alert count each get a suggested threshold or a longer window, taken from the condition search_datadog_monitors already returned, so the suggestion is a change to that query rather than a new monitor.

The prompt forbids edits. create_datadog_monitor and validate_datadog_monitor exist on the same server, and a write needs monitors_write, but this run does not call them. The only file it writes is monitor-audit.md in the sandbox. Datadog's own fair-use limit on the MCP server is 50 tool calls in 10 seconds and 100,000 a month, so a large org is read in batches of monitors rather than one call per group.

What comes back is the file monitor-audit.md on the session, as an artifact with a name, a mime type and a url on api.prix.dev. That url downloads the file with no key for an hour (url_expires_at). Reading the session again returns a fresh url. GET /o/{org}/sessions/{id}/artifacts/monitor-audit.md with the key also works. The run's result text on the session is the short answer; the markdown file is the audit.

The report is a ranked list. Each row names the monitor, its alert count over the 30 days, whether most alerts recovered within 5 minutes, whether it flapped, whether it has a notification target, and, for the top 10, the current threshold and the suggested one with the reason taken from the events. It does not claim a page was deleted. Nothing in Datadog changes.

A reviewer checks three things before anyone edits a monitor by hand. The recovery mark has to be a majority of that monitor's alerts, not a single quiet night. The suggested threshold has to be a change to the query the monitor already runs. And a monitor that pages a real incident stays on the list as context, not as something to mute. The trajectory on the session keeps each tool call and the monitor ids it returned.

A scheduler you already run, cron or a CI job, POSTs this body every Monday to https://api.prix.dev/o/{org}/sessions with an Idempotency-Key of the week, so a retry does not start a second audit. The same key with a different body is 409 IDEMPOTENCY_CONFLICT. There is no repository in resources, so the run needs no GitHub App installation.

Set a webhook URL on the API key (an admin session does this, not the key itself). Rush POSTs run.completed when the turn finishes, within about 30 seconds, signed per Standard Webhooks. data.result holds the answer up to 16 KiB; the audit file is larger than that, so the handler reads the session and downloads the artifact. A key allows at most max_concurrent runs at once, 4 by default, and the next start answers 429.

Doing this on a laptop means exporting monitor events, or clicking through the monitor status page, and the spreadsheet is stale by the time it is shared. The sandbox calls search_datadog_monitors and search_datadog_events itself, and the session keeps every call with its output, so the ranking can be checked against the events rather than against someone's memory of last week's pages.

On-call weeks pile up. One org can start this audit for each team tag as its own session, each writing its own monitor-audit.md, without a checkout or a shared screen. The sandbox parks when the turn ends, costs nothing while parked, and is kept for 7 idle days, so a follow-up the next morning (POST the session's messages with a new input) can ask about one monitor without running the 30 days again.

Will it mute or edit any monitor?

Which Datadog site does this reach?

What if the sign-in expires?

How do I get the file after the hour-long link expires?