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.
The official server at PagerDuty/pagerduty-mcp-server has 56 stars, 27 forks, Apache-2.0 license, 267 commits, and 14 open issues. It’s written in Python and 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 the largest tool count of any observability-adjacent server we’ve reviewed — 67 tools, more than Datadog (50+), Grafana (40+), New Relic (35), or 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
31 of the 67 tools are read-only and enabled by default. The remaining 36 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 viaPAGERDUTY_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. This isn’t padding. 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. Compare this to Datadog MCP’s 50+ tools which span 10 different products — PagerDuty has comparable breadth within its focused domain.
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.
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 real community engagement. 267 commits, 27 forks, 14 open issues being actively triaged. Contributing guidelines, security policy, and code of conduct. 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.
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
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. Issue #78 requests OAuth token support. Currently the self-hosted server only accepts PagerDuty User API tokens via environment variables. The hosted server uses API tokens in headers. Neither supports the OAuth 2.0 browser flow that Sentry and Honeycomb provide. For interactive clients, this means managing API tokens manually.
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.
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.
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.
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 (7 stars, MIT, Python) focused on LLM integration with structured inputs and outputs. Covers incidents, services, teams, users, escalation policies, on-calls, and schedules with automatic pagination handling. Last updated July 2025 (v3.1.1). Narrower tool set but potentially more agent-friendly structured responses.
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
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