PagerDuty MCP Server Setup for Cursor IDE (2026)

How do you set up the PagerDuty MCP server in Cursor? Generate a REST API key from PagerDuty, add a pagerduty block to ~/.cursor/mcp.json with that key, then restart Cursor. Once connected, your AI can pull open incidents, check who's currently on call, and read escalation policies without you opening the PagerDuty app mid-incident.

PagerDuty's API keys come in two flavors that matter here: a general REST API key (account-wide, scoped by the role of whoever generates it) and a narrower user token for actions tied to one specific person, like acknowledging an incident as yourself. Most read-focused MCP setups use the REST API key; if your setup needs to acknowledge or resolve incidents as a specific user rather than a generic integration, check whether the package you're using expects the narrower token instead.

What You Can Do With PagerDuty MCP in Cursor

Once connected, Cursor can typically:

The practical value is skipping the context switch during an incident: instead of tabbing to PagerDuty to see who's on call before pinging them, you ask Cursor directly while you're still looking at the code or logs that triggered the page.

Prerequisites

Step 1: Generate a PagerDuty REST API Key

1. In PagerDuty, go to Integrations → API Access Keys
2. Click Create New API Key
3. Give it a description like cursor-mcp so it's identifiable later
4. Choose read-only if the package you're installing only needs to query incidents and schedules — use full access only if you specifically want the AI able to acknowledge or resolve incidents
5. Copy the key immediately — like most platform API keys, it's shown once

Step 2: Add PagerDuty to Your MCP Config

Open ~/.cursor/mcp.json (or Settings → MCP in Cursor) and add a pagerduty entry. The general shape, consistent with how other REST-API-key MCP servers on this site are configured, looks like:

{
  "mcpServers": {
    "pagerduty": {
      "command": "npx",
      "args": ["-y", ""],
      "env": {
        "PAGERDUTY_API_KEY": "your-rest-api-key-here"
      }
    }
  }
}

PAGERDUTY_API_KEY reflects PagerDuty's own naming for this credential type, but as with other newer observability and incident-management integrations, there's more than one PagerDuty MCP package in circulation and the exact package name, args, and whether it expects PAGERDUTY_API_KEY versus a differently-named variable varies by implementation. Check Cursor's MCP directory or PagerDuty's own developer docs for the current recommended package before finalizing this block, and swap for the real one — don't guess at a package name and paste it in blind.

Step 3: Restart Cursor and Verify

Fully quit and reopen Cursor. In chat, try:

List all currently open incidents

or

Who's on call right now for the backend team?

A response naming real incidents, schedules, or people confirms the connection. An empty result where you expected data usually means the API key's role doesn't have visibility into the team or service you asked about — check the key's permissions in PagerDuty before assuming the config is broken.

Step 4: Practical Workflows

Start an incident response with context

List all open incidents with a status of triggered, and for each one tell me which service it's on and how long it's been open

Find who to page before you do

Who's on call for the payments team right now, and who's next in the escalation policy if they don't acknowledge within 15 minutes?

Pull incident history while debugging

Show me the timeline and notes for incident #4521 — I want to see what's already been tried before I dig in further

Cross-reference an incident with a recent deploy

Find any incidents opened on the checkout-service in the last 2 hours, and tell me if the timing lines up with a deploy

If you're also running the Datadog MCP server or the Grafana MCP server, this is where combining tools pays off — pull the PagerDuty incident, then query the underlying metrics or logs in the same conversation instead of jumping between three separate dashboards.

Troubleshooting

"Unauthorized" on every request
Double-check the key was copied without trailing whitespace, and confirm it's a REST API key from Integrations → API Access Keys, not a webhook signing secret or an app OAuth token — PagerDuty has several credential types that look similar but aren't interchangeable.

Some incidents or schedules don't show up
REST API keys inherit the role-based visibility of whoever generated them. If that user isn't on a given team or doesn't have access to a service in PagerDuty's UI, the MCP server won't see it either — this is a PagerDuty permissions issue, not an MCP config issue.

Server connects but can't acknowledge or resolve incidents
Check whether you generated a read-only key in Step 1. Write actions need a key (or user token, depending on the package) with write permissions — read-only keys will successfully list and describe incidents but reject state-changing calls.

Server won't start
Confirm PAGERDUTY_API_KEY (or whatever variable name the specific package you installed expects) is actually present in the env block — a missing or empty credential is a more common cause of silent startup failures than an invalid one.

When Not to Use This

Be deliberate about letting an AI acknowledge or resolve incidents unattended, especially for anything tied to an SLA or a customer-facing status page. A model confidently marking something "resolved" based on an incomplete read of the situation is a worse failure mode here than in most other MCP integrations on this site, because it can suppress a real page. Keep acknowledge/resolve actions manual, even if you automate the "who's on call and what's the current incident list" read side.

Frequently Asked Questions

Q: Do I need a full-access API key, or is read-only enough?
A: Read-only is enough if you only want Cursor to list incidents, check schedules, and read escalation policies — the common starting point. Full access is only needed if you specifically want the AI able to acknowledge, resolve, or create incidents.

Q: Why does the on-call lookup sometimes return the wrong person?
A: Usually a stale read against a schedule that changed after your first query, or an escalation policy with multiple layers where you asked about the wrong one. Ask again and be specific about which team or escalation policy you mean rather than assuming a generic "who's on call" maps to the service you're thinking of.

Q: Can this integration accidentally resolve a real incident?
A: Only if the key has write access and you approve an acknowledge/resolve tool call without checking what it's acting on — the same risk as any write-capable MCP integration. See the "When Not to Use This" section above.

Q: How does this pair with the Datadog or Grafana MCP servers also covered on this site?
A: Well — incident response usually spans "what's on fire" (Datadog or Grafana) and "who's handling it" (PagerDuty). Running both lets you ask a single chat to pull the underlying metrics for a service and check whether there's already an open PagerDuty incident for it, instead of manually correlating the two.

Q: Is there one official PagerDuty MCP server, or several community options?
A: This is a newer, actively evolving corner of the MCP ecosystem, and which package is best-maintained changes over time. Check PagerDuty's own developer docs or the Cursor MCP directory for the current recommendation before standardizing a team config on a specific package name.

Related Guides

---