Suppressing alerts before a deploy and cancelling the suppression afterwards is routine operational work, and it is usually done by clicking because integrations stop at reading monitors. Having schedule, list-active-only, update and cancel means the whole maintenance-window pattern can happen from where the deploy is being run. The log digest is the other decision that makes this practical: raw Datadog log output would consume a context window in one call, and returning a summary keeps the tool usable. Worth being deliberate about the write surface — delete_monitor and delete_dashboard are permanent, and create_user adds someone to your account.
A Datadog administration and query client covering the four objects you configure — monitors, dashboards, downtimes and users — each with create, read, update and delete, alongside logs, metrics, hosts and incidents.
- search_logs returns a compact digest rather than raw log lines, which is what makes log search usable from a chat client at all.
- Monitors with a full lifecycle — list with filtering by name, tags and state, get the full configuration, create, update and delete.
- Dashboards likewise, including creating one with its widgets and layout rather than only reading existing ones.
- Downtimes as first-class objects: schedule one to suppress alerts for a scope, list active ones only, update and cancel.
- query_metrics supports multiple timeseries queries in one call.
- list_hosts and list_incidents cover the infrastructure and the incident record.
- User management included — create with email and role, read and update.
DD_API_KEY and DD_APP_KEY. The surface includes permanently deleting monitors and dashboards and creating users, so the application key's scope is the boundary.
One command plus a key — npm install -g mcp-datadog-server, then supply credentials