PagerDuty MCP Server: AI Incident Response With Claude

If your team gets paged at 2am and the first ten minutes vanish into figuring out who's on call and what someone already tried, PagerDuty's MCP server exists to close that gap. This is PagerDuty's own integration, not a community wrapper. It drops incidents, on-call schedules, and escalation policies straight into a Claude conversation instead of yet another dashboard tab. MCPFind's monitoring category indexes 198 servers right now, PagerDuty's entry sitting among them next to Datadog, Grafana, and Sentry. New to MCP servers? The what-is-mcp guide walks through how a client like Claude connects to one. Below, I'll cover what PagerDuty's server actually exposes, how the local and hosted versions diverge, and where it lands in a wider on-call AI setup.

What Does the PagerDuty MCP Server Do?

PagerDuty's official MCP server covers more than 70 tools. They span incidents, on-call schedules, escalation policies, services, teams, users, event orchestrations, analytics, status pages, and webhooks. That's a lot of surface for one integration, and it mirrors PagerDuty's own API rather than some trimmed-down subset carved out just for AI agents.

Most of that surface never gets touched on a normal day. A typical session looks like Claude listing open incidents assigned to your team, pulling the on-call schedule for the next 48 hours, or checking whether an escalation policy really routes to the right person before you learn otherwise mid-outage. The server also ships five embedded React apps, among them an Incident Command Center and a Service Dependency Graph, so clients that support rendered UI get back more than plain text. It's licensed Apache-2.0 and sits at roughly 70 GitHub stars. Still early, given the incident volume PagerDuty itself handles.

Now compare that against the rest of MCPFind's monitoring category, which averages under one star per server. A young project isn't strange here. What counts for an incident-response tool, far more than star totals, is whether PagerDuty maintains it directly. And this one is a first-party repo under the PagerDuty GitHub organization, not a fork someone hacked together over a weekend. Worth verifying for any monitoring server before you aim it at production data, because the category is packed with abandoned side projects parked right next to actively maintained vendor integrations.

How Do You Set Up the PagerDuty MCP Server With Claude?

Setup begins with generating a PagerDuty API key scoped to what you actually need, then pointing Claude Desktop or Cursor at the local binary through your MCP client config. The server defaults to read-only. Nothing gets created, acknowledged, or resolved until you flip that on yourself.

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

Drop the --enable-write-tools flag for a pure query experience while you're still getting a feel for what Claude can see. Add it back once you trust the read output and genuinely want Claude acknowledging or escalating incidents for you. Restart your client after editing the config. Then ask it to list your open incidents as a first check that both the connection and the API key work.

What Is the Difference Between the Local and Hosted PagerDuty MCP Servers?

The local server installs on your machine and defaults to read-only, demanding an explicit flag before any write action fires. The hosted server, reachable at mcp.pagerduty.com/mcp, needs no install whatsoever. You connect from Cursor or VS Code, authenticate through OAuth, and get read and write tools live by default instead of gated behind a flag.

That default-write behavior on the hosted path deserves a pause before you wire it into a production PagerDuty account. It's convenient. Nothing to install, no API key to rotate. But it also means Claude can acknowledge or resolve an incident the instant you authorize the connection, not after you've decided you're ready for that. Want a slower rollout? Start with the local, read-only server, get comfortable with what it surfaces, and only move to hosted once write access is something you actually want switched on by default.

How Does PagerDuty Fit Into an AI On-Call Stack With Grafana and Datadog?

PagerDuty usually sits at the tail end of an incident chain, not the front. Monitoring tools detect and diagnose; PagerDuty routes the page and tracks the response. Pair its MCP server with others in the same category and Claude can move across that whole chain inside one conversation, rather than three separate dashboards.

Here's a concrete version. Grafana shows a metric spike in Prometheus, Datadog's APM traces point at the slow downstream call behind it, and PagerDuty confirms whether an incident already fired for that service and who's on call right now. Claude can walk that sequence on its own if all three servers are connected, then draft the incident summary from what it found instead of you copying details between tabs by hand. This pairing isn't unique to PagerDuty, either. Several other monitoring vendors, Datadog and New Relic included, now ship their own remote-hosted MCP servers, so the "detect, diagnose, escalate" pattern is becoming a common way multiple servers get chained together during a live incident.

None of this replaces the human decision to declare a major incident or pull in extra responders. What it strips out is the busywork wrapped around that decision: the minutes lost checking three tools before you even know whether the spike matters. Wire up PagerDuty alongside your monitoring stack and Claude can hand you a first draft of the situation the moment you ask, leaving the judgment call to whoever's actually on the hook for the response.