MCP field guide / PagerDuty
// mcp field guide · incident / on-call
Reading incidents is safe. The consequential part isn't the API call — it's the human on the other end of a page. Triggering an incident wakes a real on-call person, possibly at 3am, and a page can't be un-sent. Resolving one can hide an active outage; a schedule override changes who gets paged. It's Slack — but the notification wakes someone up.
GUARD FIT · READS (default)
PASS-THROUGHList/get incidents, schedules, on-calls, escalation policies. No external effect. Write tools are off unless enabled.
GUARD FIT · PAGE-AFFECTING WRITES
STRONGTrigger an incident (pages a human), resolve (masks an outage), schedule override (reroutes pages).
Overall fit: MODERATE → STRONG — concentrated on the three page-affecting mutations.
PagerDuty/pagerduty-mcp-server is PagerDuty's official server (Apache-2.0, Python). It runs as a managed/hosted endpoint (mcp.pagerduty.com/mcp) and self-hosted locally, over incidents, services, schedules/on-call, escalation policies, teams, and status pages (55 tools across 14 domains on the hosted service). Crucially, it is read-only by default — mutating tools require the explicit --enable-write-tools flag — so an agent can triage safely before any write is even exposed.12
| Tier | Tools |
|---|---|
| read-only | list_incidents, get_incident, get_past_incidents, list_oncalls, list_schedules/get_schedule, list_escalation_policies, list_services, list_teams, list_log_entries |
| mutating | add_note_to_incident, add_responders, manage_incidents (status/urgency/assignment — acknowledge = status acknowledged), create_service/update_service, create_schedule/update_schedule, create/update_escalation_policy |
| consequential | create_incident (pages the on-call responder — possibly at 3am), manage_incidents → resolved (can mask an active outage by silencing paging), create_schedule_override (reroutes who gets paged) |
The consequence isn't the record — it's the person. On a service with an escalation policy (especially high urgency), create_incident follows PagerDuty's normal notification path and pages a specific human. That page — sleep interrupted, alert fatigue, false-alarm trust erosion — is real and not cleanly reversible: the person was already woken. (The exact notification step is PagerDuty platform behavior inferred from its escalation model, not spelled out in the tool doc.) No verified snooze tool appears in the official list.
Incident triage. List active incidents, pull related/past incidents and alerts, summarize — read-only.
Assisted response. Acknowledge an incident, add an investigation note, pull in a responder while a human drives the fix.
On-call ops. Query who is on call, create a schedule override to cover a swap or PTO gap.
Reads → weak. Listing incidents, schedules and on-calls is inspection with no external effect.
The three page-affecting mutations → strong. It's "Slack, but the notification pages a real human":
create_incident — the sharpest edge. Like a Slack post, the side effect leaves the system — but here it's a page to a specific on-call person, with real human cost. A wrong or duplicate trigger can't be un-sent. Approve before commit, with an honest "irreversible: person will be paged" note.manage_incidents → resolved) — the opposite danger: it can hide an active outage by silencing paging while the problem continues. Approval protects against an agent "cleaning up" a still-live incident.The honest core: don't gate reads; gate the page-affecting writes. A page, once sent, can't be un-sent — compensation ≠ reversal, with the "irreversible" thing being a human's interrupted night. Credit PagerDuty's read-only-by-default design: it already removes the risk until you opt into writes.
ChronoMCP passes the read surface through and holds create_incident, incident-resolve and schedule overrides for a human — flagging the page as irreversible.
--enable-write-tools, tool names): github.com/PagerDuty/pagerduty-mcp-serverProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with PagerDuty. Tool names are from the official repo; that create_incident pages a responder is grounded in PagerDuty's escalation model rather than the tool doc, and no snooze tool was found. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.