PagerDuty MCP server: setup, auth, production

What is the PagerDuty MCP server?

A PagerDuty MCP server implements the Model Context Protocol and exposes PagerDuty's capabilities as typed tools an agent can discover and call in the middle of a task. On-call scheduling and incident response.

Observability systems are the highest-value, lowest-risk first MCP connection: an agent that can read your metrics, traces, and logs debugs alongside you instead of asking you to paste graphs. Keep it strictly read-only and the blast radius is near zero.

A real PagerDuty workflow

The agent summarizes active incidents, tells you who’s on call for the affected service, and drafts an incident timeline from the event stream — situational awareness assembled while you’re still reading the first alert.

What an agent can do with PagerDuty

• Have an agent summarize active incidents
• Pull who’s on call for a service during an investigation
• Draft an incident timeline from events

Read-only is the right default: let the agent observe and reason first, then grant specific write actions deliberately — each behind audit logging and, for anything high-impact, human approval.

Setting up the PagerDuty MCP server

Use a PagerDuty API token scoped to read access. Resist the urge to grant write: an agent should inform incident response, not act inside it.

Auth: A PagerDuty API token scoped to read access. Credentials belong in the environment or a secret store — never in the repo or the agent's sandbox. Wiring a server into Claude Code or Cursor is the same for every tool; the step-by-step lives in the MCP connection guide.

The risk to watch with PagerDuty

An agent that can acknowledge or resolve incidents can hide a live problem. Read-only, always — the on-call human owns acknowledge and resolve.

More broadly, a production-grade PagerDuty integration needs read scoping and never auto-acknowledging or resolving incidents. The MCP security checklist applies to every integration — we build servers with these controls baked in.