MCP servers that can list incidents
3 verified servers expose a tool that can list incidents
When something is on fire, the first question an agent asks is the same one a responder asks: what's open right now? These servers answer it with a single read, returning the current incidents so the agent can summarize on-call status, triage what's active, or draft a report for the channel.
Grafana, PagerDuty, and Better Stack each expose a list call. The shape of what comes back differs, and so does where the data originates.
Grafana
Grafana Labs
Grafana Labs' official MCP server: query dashboards, Prometheus, Loki, incidents, alerts, and OnCall from your agent.
list_incidents
Reads from Grafana Incident, so list_incidents returns the active set alongside the dashboards and alert rules in the same workspace, useful when the agent is already pulling metrics there.
PagerDuty
PagerDuty
PagerDuty's official MCP server exposes incidents, services, schedules, teams, and orchestrations — 64 tools, read-only by default, with an OAuth-hosted option.
list_incidents
The on-call and alerting system of record: PagerDuty's list_incidents shows what actually paged someone and how it routed, which is the view you want for summarizing who is responding to what.
Better Stack
Better Stack
Better Stack's official MCP server: query logs, metrics, and traces, manage monitors and incidents, and drive on-call from one remote endpoint.
uptime_list_incidents
uptime_list_incidents takes filtering options, letting the agent scope to a status or time window, and it sits next to Better Stack's uptime monitoring so an incident lines up with the check that opened it.
What to know
All three return the live incident set, but they sit at different points in the stack. PagerDuty is the alerting and on-call layer, so list_incidents there reflects what paged a human and who it routed to. Grafana's list_incidents reads from Grafana Incident, tied to the dashboards and alert rules already in the same workspace. Better Stack pairs incidents with uptime monitoring, and uptime_list_incidents accepts filtering options, so the agent can narrow to a status or window instead of paging the whole history. A read like this is safe to hand an agent freely: it changes nothing, and the worst case is a stale snapshot.
Listing is a snapshot, and an agent that only sees the snapshot keeps rediscovering the same ground. One that remembers an incident on this service last week, or that a given alert is a known false positive the team agreed to mute, writes a triage summary that distinguishes a recurrence from a first-time page. The incident API hands back what's open; the judgment about whether it's noise comes from what happened before.
Questions
- Can the agent filter the incident list?
- Better Stack's uptime_list_incidents exposes filtering options directly, so the agent can request a status or window rather than the full set. Grafana and PagerDuty return the list through their own list_incidents call; you narrow the result by reading the fields it gives back. For a long incident history, the Better Stack filters keep the response small enough to reason over in one pass.
- Is listing incidents safe to run without supervision?
- Yes. Listing is read-only, so it touches nothing and the worst outcome is a stale snapshot between the read and now. The credential still matters: an incident list can name affected services and responders, so scope the token to the data you are comfortable putting in front of the agent and the channel it posts to.