PagerDuty for incident management
PagerDuty's official MCP server exposes incidents, services, schedules, teams, and orchestrations across 64 tools, read-only by default, with an OAuth-hosted option. For incident management it is our top pick of four because it owns the part the others do not: the paging and on-call layer that decides which incident is open, who is responsible, and how alerts group into it.
When an alert fires, the first questions are which incident it belongs to and who is on call. PagerDuty is the system that holds those answers. The read-only default matters here too, an agent can investigate the live incident aggressively without any risk of changing its state.
How PagerDuty fits
The investigation tools map straight to the management surface. list_incidents pulls the open and recent incidents, and list_alerts_from_incident with get_alert_from_incident drill into the specific alerts that triggered one. Alert grouping is where noise becomes a single actionable incident: list_alert_grouping_settings and get_alert_grouping_setting show how alerts are bundled, while create_alert_grouping_setting, update_alert_grouping_setting, and delete_alert_grouping_setting let an agent tune that grouping. To establish what changed around an incident, list_change_events, get_change_event, list_service_change_events, and list_incident_change_events correlate deploys and config changes with the timeline.
The honest limit is that PagerDuty holds the incident and the paging state, not the underlying error or telemetry. It will not show you a stack trace or a metric. That is why it pairs with the siblings: Sentry is the stronger pick for the error tracker with root-cause detail and the actual exception, Datadog for metrics, traces, and the broad observability picture, and Better Stack for logs and uptime monitors. Reach for PagerDuty first to anchor the incident and the on-call context, then bring in the others for the diagnosis.
Tools you would use
| Tool | What it does |
|---|---|
| list_alert_grouping_settings | Lists alert grouping settings. |
| get_alert_grouping_setting | Gets a single alert grouping setting. |
| create_alert_grouping_setting | Creates an alert grouping setting. |
| update_alert_grouping_setting | Updates an alert grouping setting. |
| delete_alert_grouping_setting | Deletes an alert grouping setting. |
| list_alerts_from_incident | Lists the alerts associated with an incident. |
| get_alert_from_incident | Gets a single alert from an incident. |
| list_change_events | Lists change events. |
| get_change_event | Gets a single change event. |
| list_service_change_events | Lists change events for a service. |
FAQ
- Is the PagerDuty MCP server safe to run during a live incident?
- Yes. It is read-only by default, so an agent can list incidents, inspect their alerts, and correlate change events without altering incident state. Alert grouping settings can be created or updated through dedicated tools when you choose to enable writes.
- Can it tell me what actually broke?
- Not the error itself. PagerDuty holds the incident, the alerts attached to it via list_alerts_from_incident, and change events that may correlate, but the stack trace lives in Sentry and the metrics in Datadog. Pair PagerDuty with one of those for the diagnosis.
- How does an agent see how alerts roll up into an incident?
- list_alerts_from_incident and get_alert_from_incident show the alerts on an incident, and the alert grouping tools (list_alert_grouping_settings, get_alert_grouping_setting, and the create/update/delete variants) expose and tune how alerts are bundled.