PagerDuty for incident response
PagerDuty's official MCP server gives an agent read-only access by default to incidents, services, schedules, and orchestrations across 64 tools, with an OAuth-hosted option. For incident response it is our first pick of four because response starts where the incident lives: an agent has to see what is firing, who is on call, and the incident's current state before it can compress the loop to resolution.
The value at 3 a.m. is not tabbing between five tools. PagerDuty answers the orientation questions in seconds, which incident is active, what alerts triggered it, what recently changed, so the responder spends the time on the fix rather than the gathering.
How PagerDuty fits
list_incidents surfaces the active incidents an agent should be driving, and list_alerts_from_incident plus get_alert_from_incident expose the alerts behind a given one so the agent knows what tripped. Correlating with recent changes is often the fastest route to a cause: list_change_events, get_change_event, list_service_change_events, and list_incident_change_events let the agent line up deploys and config changes against the incident timeline. The alert grouping tools, list_alert_grouping_settings and get_alert_grouping_setting with their create, update, and delete counterparts, control how noisy alerts collapse into one incident so responders are not chasing duplicates.
The limit is real: PagerDuty drives the response and holds the paging state, but it does not contain the error detail or the telemetry. To close the loop you correlate it with the systems that do. Sentry is the stronger pick for the stack trace and root-cause analysis, Datadog for metrics and traces across the stack, and Better Stack for logs and status-page updates that keep stakeholders informed. Start from PagerDuty to anchor the active incident and on-call, then pull in the error tracker and observability layer to find and prove the fix.
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
- What does PagerDuty's server contribute to incident response that the others do not?
- It holds the live incident, the on-call schedule, and the alerts attached to the incident via list_alerts_from_incident. That orientation, what is firing and who owns it, is the starting point of response; Sentry and Datadog then supply the error and telemetry detail.
- Can an agent investigate without making the incident worse?
- Yes. The server is read-only by default, so list_incidents, the alert tools, and the change-event tools let an agent gather context and correlate recent deploys without altering incident state.
- How does the agent connect an incident to a recent deploy?
- The change-event tools do this: list_change_events and get_change_event across the workspace, plus list_service_change_events and list_incident_change_events scoped to a service or incident, let the agent line up changes against the incident timeline.