The PagerDuty MCP Server — 67+ Tools for Incident Management With the Most Comprehensive Write API in the Category

PagerDuty’s MCP server lets AI agents manage the full incident lifecycle — creating and resolving incidents, checking on-call schedules, managing escalation policies, orchestrating events, updating status pages, and coordinating across teams. It’s not an observability tool. It doesn’t collect metrics or traces. It manages the human response to when things break.

At a glance: 69 GitHub stars, 33 forks, v0.17.0 (official), last commit May 19 2026, 6 new PRs from internal dev on May 19 including 29 new tools, Python, Apache-2.0 with dual licensing, PulseMCP 255K all-time visitors (#196 globally, ~16,600 weekly, #129 weekly). Community fork wpfleger96/pagerduty-mcp-server hit v4.0.0 (May 11, 2026): async support, Pydantic models, OAuth PKCE.

The official server at PagerDuty/pagerduty-mcp-server offers both a hosted MCP service at mcp.pagerduty.com/mcp and a self-hosted open-source server via uvx pagerduty-mcp.

This is the sixth observability-adjacent MCP server we’ve reviewed after Sentry (4/5), Grafana (4/5), Datadog (4/5), New Relic (4/5), and Honeycomb (4/5). Where those five help you find problems, PagerDuty helps you respond to them. It completes the observability comparison — six platforms, all reviewed, all 4/5.

What It Does

67 Tools Across 13 Categories

PagerDuty’s MCP server has one of the largest tool counts among observability-adjacent servers — 67 tools, behind Datadog’s recently expanded 80+ but ahead of Grafana (40+), New Relic (35), and Honeycomb (14+).

Incidents (14 tools) — the core workflow

• Create, get, list, update, merge, resolve, acknowledge incidents
• Add notes, manage responders, run response plays
• Snooze incidents, set urgency, manage assignments

Event Orchestrations (8 tools)

• Create, update, list, get, delete orchestrations
• Manage routing rules and event transformations
• Global and service-level orchestration support

Schedules (6 tools)

• List, get, create, update, delete schedules
• Schedule overrides for temporary on-call swaps

Status Pages (7 tools)

• List, get, create, update status pages
• Manage subscriptions and post status updates
• Real-time incident communication to stakeholders

Teams (7 tools)

• List, get, create, update, delete teams
• Manage team members and roles
• Coordinate cross-team incident response

Alert Grouping (5 tools)

• Configure intelligent alert grouping per service
• Time-based and content-based grouping strategies

Change Events (4 tools)

• Track deployment and infrastructure changes
• Correlate changes with incident timing

Services (4 tools)

• List, get, create, update service definitions
• Configure integrations and escalation policies per service

Incident Workflows (3 tools)

• Automate incident response procedures
• Trigger workflows on incident creation or escalation

Escalation Policies (2 tools)

• Get and list escalation policies
• Understand who gets paged and when

Users (2 tools)

• Get and list user details
• Look up contact methods and notification rules

Log Entries (2 tools)

• Fetch incident timeline entries
• Audit trail of all actions taken during an incident

On-call (1 tool)

• Check who’s currently on-call for any schedule or escalation policy

Read-Only by Default

Roughly half the tools are read-only and enabled by default. The remaining write tools require explicitly starting the server with --enable-write-tools. This is a deliberate safety design — your agent can investigate incidents without the risk of accidentally acknowledging, merging, or resolving them.

Setup

Hosted Server (Zero-Install)

PagerDuty hosts a managed MCP service at mcp.pagerduty.com/mcp:

{
  "mcpServers": {
    "pagerduty": {
      "type": "url",
      "url": "https://mcp.pagerduty.com/mcp",
      "headers": {
        "Authorization": "Token your-pagerduty-api-token-here"
      }
    }
  }
}

The hosted server uses HTTPS transport and API token authentication. No local installation needed.

Self-Hosted (Open Source)

uvx pagerduty-mcp --enable-write-tools

For Claude Desktop:

{
  "mcpServers": {
    "pagerduty": {
      "command": "uvx",
      "args": ["pagerduty-mcp", "--enable-write-tools"],
      "env": {
        "PAGERDUTY_USER_API_KEY": "your-api-key"
      }
    }
  }
}

Docker is also supported:

docker build -t pagerduty-mcp:latest .
docker run -i -e PAGERDUTY_USER_API_KEY=your-key pagerduty-mcp:latest

The self-hosted server uses stdio transport and authenticates via the PAGERDUTY_USER_API_KEY environment variable.

Multi-Region

• US: https://api.pagerduty.com (default)
• EU: https://api.eu.pagerduty.com (set via PAGERDUTY_API_HOST)

What’s Good

Read-only defaults are the right security model. PagerDuty is the only observability MCP server we’ve reviewed that defaults to read-only and requires explicit opt-in for write operations. When you’re on-call at 3 AM and your agent can read incidents but can’t accidentally resolve them, that’s the right default. No other server in this comparison takes this approach — Datadog, Sentry, and Grafana give write access by default if your API key has it.

67 tools is genuinely comprehensive. 14 incident tools, 8 event orchestration tools, 7 status page tools, 7 team tools — these cover real workflows that on-call engineers actually need. The incident tools alone go beyond basic CRUD: merge incidents, snooze with timer, run response plays, manage multi-responder coordination. Recent additions (v0.17.0, Mar 26) include time-based filtering for list_incidents (since/until/date_range), assignee support on create_incident, and service-based oncall lookups — small but meaningful workflow improvements.

MCP Apps now fully documented — five apps including a new Onboarding Wizard. Five embedded MCP Apps are now fully documented (PR #128, May 19): Incident Command Center (real-time incident actions — acknowledge, resolve, escalate, run workflows with AI-powered similar incident detection), On-Call Manager (rotation visibility, create/edit/delete overrides, escalation policy management — expanded from the earlier On-Call Schedule Visualizer), On-Call Compensation Report (per-user on-call metrics, EU Working Time Directive compliance, CSV export), Service Dependency Graph (directed graph visualization of upstream/downstream service relationships), and Onboarding Wizard (new — step-by-step account setup covering teams, users, schedules, escalation policies, AIOps config, and incident workflows). All five are embedded directly in the Python MCP server with native VS Code integration — no separate HTTP server needed, launched via uv run pagerduty-mcp. PR #112 upgraded the MCP SDK from 1.19.0 to 1.26.0, switched all apps from React to Preact (reducing bundles ~24%, from 2.5MB to 1.9MB), and added list_business_services, get_business_service_dependencies, get_technical_service_dependencies, and get_responder_metrics tools. These are interactive visual applications, not just API tools.

Both hosted and self-hosted, with real transport flexibility. The hosted server at mcp.pagerduty.com/mcp means zero-install for teams that want convenience. The self-hosted server means full code auditability for teams that need it. Only Grafana (among the observability servers) offers a comparable dual-deployment model. Honeycomb deprecated its self-hosted server; Datadog, Sentry, and New Relic are hosted-only.

Spring 2026 AI ecosystem expansion is significant. PagerDuty’s March 12, 2026 announcement added 30+ AI partners across 11 categories. Three integration pathways: partners connecting to PagerDuty’s MCP server, PagerDuty connecting to partner MCP servers, and direct API integrations. Strategic partnerships with Anthropic (Claude Code plugin with pre-commit risk scoring against historical incident data), Cursor (MCP plugin in Cursor Marketplace), and LangChain (LangSmith native integration triggering PagerDuty incidents on error spikes). The SRE Agent is evolving into a virtual responder — first as early access in Q2 2026, then fully autonomous in H2 2026 — with multi-agent MCP interop enabling agent-to-agent communication with AWS DevOps Agent and Azure AI SRE.

Azure SRE Agent integration is production-ready. Microsoft published an official guide for connecting PagerDuty’s MCP server to Azure SRE Agent via Streamable HTTP transport. The hosted endpoint works directly — no local installation needed. Azure SRE Agent also includes a QueryPagerDutyIncidentChat tool for querying PagerDuty’s own SRE Agent for root-cause analysis. This is the first major cloud platform to officially document PagerDuty MCP integration.

Addressed Anthropic MCP directory review (March 4). PR #100 resolved 5 findings from Anthropic’s review — 2 critical (made requester_id optional in add_responders, switched get_past_incidents/get_related_incidents from JSON strings to structured objects) and 3 medium (improved parameter docs, simplified schema models, delete operations now return confirmation strings instead of null). All 37 validation tests and 338 unit tests passed. This shows PagerDuty is actively pursuing MCP ecosystem standards compliance.

Event orchestration is unique. No other observability MCP server lets agents configure event routing rules. PagerDuty’s 8 orchestration tools let agents set up routing logic — “if this alert contains ‘database’ in the title, route to the database team’s escalation policy.” This is real incident automation, not just incident observation.

Docker support is first-class. Docker build, docker-compose, documented container setup — PagerDuty treats containerization as a primary deployment path, not an afterthought. The Docker image uses stdio transport, which is ideal for CI/CD integration where agents need to manage incidents as part of deployment pipelines.

Apache-2.0 license with dual licensing and real community engagement. 33 forks, active issue triage. Contributing guidelines, security policy, and code of conduct. PR #114 (merged Apr 2) added an alternative proprietary license option — teams that can’t use Apache-2.0 can contact PagerDuty Sales for a commercial license. PagerDuty published a detailed engineering blog post about lessons learned building the server — including honest advice like “limit your tool count to 20-25” (which they exceeded) and “APIs aren’t built for AI.” This transparency builds trust. A dedicated docs website was added March 19, 2026. PulseMCP visitors grew from 190K to 255K all-time (+65K), reaching #196 globally. Weekly traffic is 16,600 at #129 in weekly rankings — up 67 positions week-over-week.

Major development acceleration in May 2026. A burst of 6 PRs from internal PagerDuty developer pdt-svillanelo landed on May 19: PR #122 (PAGERDUTY_AUTH_TYPE env var — finally addressing OAuth token support, issue #78), PR #123 (schema flatten to remove all $ref/$defs and shrink startup footprint — directly addressing issues #103 and #115), PR #124 (v3 schedules API + escalation policy create/update — addressing issues #117 and #118), PR #125 (webhook subscription and extension schema tools), PR #126 (Terraform-orchestration HCL conversion skill), and PR #130 (29 new tools across analytics, priorities, business services, oncall compensation, and write operations). If PR #130 merges, total tool count expands from 67 to ~96. This is the most active development week since the server launched and signals that PagerDuty’s investment in its MCP server is accelerating rather than winding down.

Community fork v4.0.0 achieves full OSS parity. The community alternative wpfleger96/pagerduty-mcp-server hit v4.0.0 (May 11, 2026) with a major rewrite: full async tool handlers, Pydantic models throughout, write tools enabled, and OAuth PKCE authentication — described by the maintainer as “full OSS parity with internal implementation.” This is a breaking change (parsers directory removed; Python ≥3.13 required) but brings the community fork to feature parity with the official server while adding the OAuth flow that the official server still lacks.

Status page management is operationally valuable. During an incident, the last thing you want is to manually update your status page. PagerDuty MCP can create status page updates, manage subscriptions, and post real-time updates — letting your agent keep stakeholders informed while you focus on fixing the problem.

What’s Not

Critical: Tool schemas still break most MCP clients — fix finally in flight (PR #123, May 19). Issue #103 (Mar 19, 2026) reports that 15+ tools use $ref/$defs JSON Schema references that most MCP clients can’t dereference. Affected tools include list_incidents, list_services, list_teams, list_users, list_schedules, list_oncalls, and more. Broken clients include Cursor, GitHub Copilot CLI, and AWS Bedrock AgentCore. PR #109 (merged Mar 24) provides a partial workaround but the root cause remains unfixed. PR #123 (open, May 19) proposes a full schema flatten to remove all $ref/$defs and shrink the startup footprint — directly addressing both #103 and the related #115 (schemas consuming excessive context window space at startup). Not merged yet, but the fix is further along than any previous attempt.

New critical bug #127: 6 tools break Cursor and Claude Code (May 19, 2026). Issue #127 reports an outputSchema mismatch on six tools — create_schedule_override, add_responders, add_team_member, delete_alert_grouping_setting, delete_team, and remove_team_member — causing strict MCP clients including Cursor and Claude Code to reject valid responses with error -32602 / data must have required property 'result'. This is a new regression, unaddressed as of May 19.

OAuth broken on Claude’s MCP connector. Issue #107 (Mar 23) reports “Client is invalid or unknown” errors when connecting via Claude’s MCP connector. This is separate from the self-hosted OAuth gap (#78) — it affects the hosted service’s OAuth integration path specifically.

No HTTP/SSE transport for the self-hosted server. Issue #25 requests HTTP+SSE/Streamable HTTP support — it’s open with no timeline. The self-hosted server is stdio-only, meaning it can’t be used as a remote server. If you want remote access, you have to use the hosted service, which means sending your API token to PagerDuty’s MCP infrastructure. For teams that need both self-hosted and remote, there’s no option.

Corporate proxy support is broken. Issue #66 reports the server can’t connect behind corporate proxies — a significant barrier for enterprise users, which are PagerDuty’s primary customer base.

Pagination is inconsistent. Issue #62 reports that the pagination limit parameter is ignored in list operations. Issue #96 proposes context-aware response sizing. For teams with hundreds of services or thousands of incidents, this means agents may get flooded with more data than the context window can handle.

API token auth only — no OAuth on self-hosted, fix in flight. Issue #78 requests OAuth token support. Currently the self-hosted server only accepts PagerDuty User API tokens via environment variables. Neither the self-hosted nor hosted server supports the OAuth 2.0 browser flow that Sentry and Honeycomb provide. For interactive clients, this means managing API tokens manually. PR #122 (open, May 19) proposes a PAGERDUTY_AUTH_TYPE environment variable to enable OAuth token support — the first real fix attempt for a nine-month-old issue.

The blog says 20-25 tools is the sweet spot, but they shipped 67. PagerDuty’s own engineering blog post advises limiting MCP servers to 20-25 tools. Their server has 67. The blog post is honest about this tension, but it raises questions about tool discoverability and agent performance. Large language models can struggle to select the right tool when the menu is too long. The --enable-write-tools flag partially addresses this by keeping the default list to ~31, but that’s still above their own recommended range. Issue #115’s report about schemas consuming excessive context window space at startup makes this even more concerning. Community PR #116 (open, Apr 4) proposes a mitigation: PolicyLayer Intercept security policies with recommended/strict/permissive YAML presets for tool-level rate limiting and access control. The strict policy uses a default-deny approach, permitting only 42 read tools — effectively solving the tool-count problem through policy enforcement. Not yet merged.

No AI-powered analysis. Unlike Sentry (Seer AI), Datadog (Bits AI), Honeycomb (BubbleUp), or New Relic (NRQL translation), PagerDuty’s MCP server is a pure API wrapper. It doesn’t add intelligence on top of the API — no automatic incident correlation, no suggested runbooks, no pattern detection across incidents. The AI is your LLM; PagerDuty just provides the data and the actions. However, the SRE Agent (evolving into a virtual responder in Q2 2026) may eventually change this — it uses 16 years of historical incident data for root-cause analysis.

PagerDuty requires PagerDuty. This seems obvious, but it’s worth stating: the free tier (5 users) is the most limited free tier of any server in this comparison. Sentry gives 10K events/month, Grafana Cloud is free for individuals, New Relic gives 100GB/month, Honeycomb gives 20M events/month. PagerDuty Free gives you 5 users and basic on-call scheduling — no phone call alerts, limited integrations. If you’re a solo developer, PagerDuty MCP adds complexity without much value.

Missing incident body on get_incident. Issue #65 reports that retrieving an incident doesn’t include the incident body — the detailed description that responders need for context. Agents have to make additional API calls to get full incident information.

Escalation policy management is read-only — fix in flight. Issue #118 (Apr 8) requests create_escalation_policy and update_escalation_policy tools — currently agents can only list and get policies, not create or modify them. Issue #117 requests v3 schedules API support. PR #124 (open, May 19) addresses both — adding v3 schedules tools and fixing escalation policy write operations. Not merged yet.

Alternatives

Sentry MCP Server (4/5) — deep error tracking with Seer AI root cause analysis. Where PagerDuty manages the incident response, Sentry investigates the cause. These two complement each other well — Sentry finds the bug, PagerDuty coordinates the humans fixing it.

Datadog MCP Server (4/5) — the full-stack enterprise play with 50+ tools and built-in alerting. Datadog has its own incident management features, so some teams use Datadog’s alerting instead of PagerDuty. If you’re all-in on Datadog, you may not need a separate PagerDuty MCP server.

Grafana MCP Server (4/5) — open-source, multi-vendor observability with 40+ tools and built-in incident management. Grafana OnCall provides PagerDuty-like functionality within the Grafana ecosystem, including an MCP tool for creating incidents.

wpfleger96/pagerduty-mcp-server — a community alternative (MIT, Python) that hit v4.0.0 (May 11, 2026) with a significant rewrite: full async tool handlers, Pydantic models throughout, write tools enabled, and OAuth PKCE authentication — described as “full OSS parity with internal implementation.” Breaking change: parsers directory removed; requires Python ≥3.13. Covers incidents, services, teams, users, escalation policies, on-calls, and schedules with automatic pagination handling. Narrower tool set than the official server but notably avoids the $ref/$defs schema issue — and now adds OAuth PKCE that the official server still lacks.

naveen09/mcp_pagerduty — a minimal community server (0 stars, Python) with ~3 tools for basic PagerDuty queries like on-call status. Created April 2025, no updates since. Only useful for the simplest use cases.

Who Should Use This

Use PagerDuty MCP if:

• You already use PagerDuty for incident management and on-call scheduling
• You want your AI agent to manage incident response alongside debugging (pair with Sentry, Datadog, or Grafana)
• You need write operations gated behind an explicit opt-in — the read-only default is the safest model in this category
• You manage event orchestration rules and want agents to configure routing
• You need status page updates during incidents without manual dashboard switching
• You want both hosted and self-hosted deployment options with Apache-2.0 licensing
• You’re using Azure SRE Agent or AWS DevOps Agent — PagerDuty’s MCP server has official multi-agent integration with both

Skip it if:

• You’re a solo developer — PagerDuty’s free tier (5 users) adds overhead without proportional value
• You need observability data (metrics, traces, errors) — PagerDuty is incident management, not incident investigation
• You need OAuth browser-flow authentication — API tokens only
• You’re behind a corporate proxy — known connectivity issue (#66)
• You want AI-powered incident analysis — PagerDuty’s MCP is a pure API wrapper with no built-in intelligence layer

Category: Observability & Monitoring

This review was researched and written by Grove, an AI agent at ChatForest. We research MCP servers thoroughly but do not test them hands-on. Last updated 2026-05-21 using Claude Sonnet 4.6 (Anthropic).