# PagerDuty in Claude for on-call engineers

> PagerDuty in Claude for engineers: reads and incident notes on the engineer role, while overrides, maintenance windows and every delete stay off.

**TL;DR** Elaichi's pagerduty connector carries 157 tools, and 81 of them read. Give the engineer role an allow rule that names the incident, on-call and log reads plus create_a_pagerduty_incident_note, and add allow rules for the role's other apps. Overrides, maintenance windows, schedule and escalation policy changes, new incidents and alert updates are writes, not deletes, so the consent screen does not hold them back; leaving them out of the allow rule does. Have each engineer connect their own PagerDuty account so PagerDuty's own role still applies.

## What an on-call engineer asks PagerDuty at 7:00 AM

Jake Morgan comes off a night of pages and opens Claude Code. He wants three answers before standup: what fired overnight, who is on call now, and whether the checkout errors look like last month's outage. Each answer sits in PagerDuty. Putting PagerDuty in Claude is worth doing for that loop, and for one write: a note on the incident saying what he found.

[Elaichi's pagerduty connector](/connectors/pagerduty/) carries 157 tools. By operation, 81 read, 26 create, 25 update, 21 delete and 4 do something else, such as testing a webhook. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves the connector, beside 600+ connectors, through one endpoint that Claude, Claude Code, Cursor and any MCP client sign in to.

The design question is the same one every connected app raises. Which of the 157 tools may the engineer role reach? The answer for most teams is the reads, the incident note, and nothing that changes who gets paged.

## Which PagerDuty reads cover the morning after an incident?

About a dozen read tools answer the questions engineers ask. They return incidents, alerts, notes, the incident log and the on-call roster.

| The engineer asks | Tool that runs |
| --- | --- |
| What fired overnight, and is it still open? | `list_all_pagerduty_incidents`, `get_single_pagerduty_incident_by_id` |
| Which alerts rolled into this incident? | `list_all_pagerduty_incident_alerts` |
| What happened, in order? | `list_all_pagerduty_log_entries`, `list_all_pagerduty_incident_notes` |
| Has this happened before? | `list_all_pagerduty_past_incidents`, `list_all_pagerduty_related_incidents` |
| Who is on call now? | `list_all_pagerduty_on_calls`, `list_all_pagerduty_users_on_call` |
| Who gets paged next? | `list_all_pagerduty_schedules`, `list_all_pagerduty_escalation_policies` |
| What changed before it fired? | `list_all_pagerduty_change_events` |
| Which service owns this? | `list_all_pagerduty_services` |

The history tools do the heavy lifting in a review. `list_all_pagerduty_past_incidents` returns incidents from the past six months with similar metadata on the same service, each with a similarity score. `list_all_pagerduty_related_incidents` returns the 20 most recent related incidents, with the relationships that explain why.

Two reads fit the engineering manager more than the engineer. `list_all_pagerduty_audit_records` and `list_all_pagerduty_maintenance_windows` show configuration history and planned silences. Both only read.

## Why is an incident note the one write engineers need?

A note records what the engineer found, on the incident, where the next responder will read it. `create_a_pagerduty_incident_note` adds a note to one incident, up to 2,000 notes per incident.

It is also the write a coding agent reaches for at the end of a task. The [coding-agent walkthrough](/blog/coding-agents-company-tools/) has Claude Code link its pull request to the incident with exactly this tool. A note changes no routing, pages nobody and resolves nothing.

## Is acknowledging an incident safe to allow?

Only if resolving, reassigning and escalating are safe too. In the pagerduty connector, `update_a_pagerduty_incident_by_id` is the one tool for changing the incident record.

Its incident body takes a `status` of acknowledged or resolved. The same body takes `assignments`, `escalation_level`, `escalation_policy`, `priority`, `urgency` and `title`. So a restriction cannot allow acknowledge and keep resolve out. The rule names a tool, and this tool does all of it.

Alerts are a separate matter. `update_a_pagerduty_incident_alert_by_id` and `pagerduty_incident_alerts_manage` change alerts, and the second takes up to 250 alerts in one request. Neither is part of the incident tool. The safer default leaves all three off the engineer role. Engineers can still acknowledge in PagerDuty itself, where PagerDuty's own permissions decide. If your team does want it in the client, allow the tool knowing what it carries. Each engineer's own PagerDuty role then sets the limit, which is the subject of the next decision.

## Should each engineer connect their own PagerDuty account?

Yes, when the role includes the note. In Elaichi a shared connection runs every call on its owner's credential, so PagerDuty sees one person for the whole team.

PagerDuty draws the same line on its side. Requests made with a user token REST API key are restricted to that user's own permissions, and anything else returns 403 Forbidden ([API access keys](https://support.pagerduty.com/main/docs/api-access-keys), checked October 2026). For OAuth apps, PagerDuty says a user token reaches only what the authorizing person can access, and the app's actions show under that person's name ([scoped OAuth apps](https://support.pagerduty.com/main/docs/scoped-oauth-apps), checked October 2026). So have Jake connect the [pagerduty connector](/connectors/pagerduty/) with his own sign-in or his own user token. His notes then run as him, not as a shared owner, and his PagerDuty role stays the outer limit.

That role matters, because PagerDuty's roles are broad. Under Advanced Permissions, the Responder base role can act on incidents, create incidents for any team and create schedule overrides. The Observer base role can view objects but cannot change them ([Advanced Permissions](https://support.pagerduty.com/main/docs/advanced-permissions), checked October 2026). An engineer on the Responder role still reaches overrides. Elaichi's rule narrows it from there.

One shape suits a shared connection. A team that only reads can connect once with a general access key created as a Read-only API Key, which PagerDuty restricts to GET calls. Then PagerDuty itself refuses every write, notes included.

## Which PagerDuty writes stay off the engineer role?

Everything that changes who gets paged, what pages, or what exists. The worst of these are writes, not deletes, which matters at consent.

- `create_a_pagerduty_override` puts someone else on a schedule for a span of time. PagerDuty calls an override a manual one-time adjustment to an on-call schedule ([schedule docs](https://support.pagerduty.com/main/docs/edit-schedules), checked October 2026). One wrong override and the page goes to a person who is asleep.
- `create_a_pagerduty_maintenance_window` takes a start time, an end time and services. While a service is in a maintenance window, no new incidents trigger ([maintenance windows](https://support.pagerduty.com/main/docs/maintenance-windows), checked October 2026). That is a silence on production.
- `create_a_pagerduty_incident` opens a new incident, and that pages the people on the service's escalation policy. A model that creates one by mistake wakes someone up.
- `update_a_pagerduty_incident_alert_by_id` and `pagerduty_incident_alerts_manage` change alerts, including their status, up to 250 at a time for the second.
- `update_a_pagerduty_schedule_by_id` and `update_a_pagerduty_escalation_policy_by_id` rewrite rotations and escalation paths for everyone on them.
- The 21 deletes, including `delete_a_pagerduty_service_by_id`, `delete_a_pagerduty_schedule_by_id`, `delete_a_pagerduty_escalation_policy_by_id`, `delete_a_pagerduty_user_by_id` and `delete_a_pagerduty_team_by_id`.

Here is the trap. All 21 delete tools are HTTP DELETE calls that Elaichi tiers destructive, so they need "Delete data and remove access" at consent, which is never pre-ticked. Every other write is tiered write, overrides and maintenance windows included. Those run under "Run your connected tools", the box an engineer ticks to run any connected tool. The consent screen holds back the deletes and nothing else.

## Writing the allow rule for PagerDuty in Claude

PagerDuty in Claude becomes a safe on-call tool when the engineer role holds an allow rule. It names the reads in the table above plus `create_a_pagerduty_incident_note`. A restriction is a rule about which connectors and which individual tools a target may reach, and an allow rule denies whatever it does not name.

Blocking the dangerous writes one by one is the weaker choice. A block rule covers only the tools it names, and the connector has 55 writes that are not deletes. A list of the ones somebody thought of on the day goes stale with the next tool the connector gains. [Restricting single tools against the whole app](/blog/per-tool-vs-per-app-restrictions/) sets out that trade-off.

The allow rule has one catch. It becomes the role's whole allowlist across every connector, not a PagerDuty filter. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. If engineers also use Jira, Slack and Sentry, add allow rules naming each of those connectors whole. Allow rules on one role merge into one list, so they can be separate rules. The [Cursor rollout playbook](/blog/engineering-team-cursor-jira/) covers the Jira and Slack half of the same engineer role.

A new rule takes about two minutes to reach every session, so wait before testing it. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema.

## Connecting Claude Code, Cursor and Claude to one address

Every engineer adds the same address, `https://api.elaichi.ai/mcp`, and signs in as themselves. Each client registers itself with Elaichi through dynamic client registration, so nobody types a client ID.

Cursor reads servers from `.cursor/mcp.json` or `~/.cursor/mcp.json`, takes a remote server as a `url` entry, and supports OAuth for servers that require it ([Cursor's MCP docs](https://cursor.com/docs/mcp), checked October 2026). Claude Code follows the [Claude Code setup guide](/blog/connect-elaichi-to-claude-code/). On Claude Team and Enterprise, an Owner adds the address once as a custom connector, and each member connects it with their own grant.

Inside the client, PagerDuty tools do not appear by name. In Elaichi, connected tools are never listed one by one, however few there are. The model finds a tool with `search_tools` and runs it with `execute_tool`. That also means a client's own per-tool approval sees one `execute_tool` for every app, so the PagerDuty decision belongs in the allow rule.

## What does the audit trail show after Jake adds a note?

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Jake's note shows him as the acting user, `create_a_pagerduty_incident_note` as the tool, his PagerDuty connection as the account reached, and the outcome.

The entry also records the surface, `mcp`, and the OAuth client the call came through. It keeps the one path argument that names the object, as the target id, and nothing else about the arguments, here the incident, so the note's text stays in PagerDuty. Because the call ran on Jake's own PagerDuty account, PagerDuty sees him too, not a shared owner. [What an AI audit log must capture](/blog/what-an-ai-audit-log-must-capture/) lists every field.

When Jake leaves, the Elaichi side ends with his membership. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so his next call fails. His PagerDuty account is a separate step in PagerDuty.

## Why not use PagerDuty's own MCP server?

A team that only needs PagerDuty may be better served by it. PagerDuty hosts a remote server at `https://mcp.pagerduty.com/mcp`, with `https://mcp.eu.pagerduty.com/mcp` for EU accounts. It accepts a PagerDuty API key or OAuth, and it puts no second vendor between the client and PagerDuty ([PagerDuty MCP Server](https://support.pagerduty.com/main/docs/pagerduty-mcp-server), checked October 2026).

PagerDuty's page is clear about its shape. Its tools come as `browse_` tools that read and `manage_` tools that change data. `manage_schedules` includes `create_override`, and `manage_incidents` includes `add_responders`. The page says tool filtering is not directly available on the hosted server, and that a Scoped OAuth client can limit which tools succeed. It also says PagerDuty does not currently support Dynamic Client Registration, so the Claude Code setup takes a client ID, a secret and a static callback port. The older self-hosted server, which was read-only by default, is deprecated, and its [GitHub repository](https://github.com/PagerDuty/pagerduty-mcp-server) is archived (checked October 2026).

So a PagerDuty-only team should start there, with a scoped client that holds read scopes. Elaichi earns its place when PagerDuty is one of several apps the engineer role reaches. Engineers add one address instead of one server per app. The rules for PagerDuty, Jira, Slack and Sentry live on one role, and one audit trail covers all of them.

## When an engineering team does not need this

When nobody asks PagerDuty questions from Claude, Claude Code or Cursor, there is nothing to govern. Engineers who check incidents in PagerDuty's own app and add notes there are already covered by PagerDuty's roles.

A small team that only reads, on one read-only key, also needs little. The test in [when you don't need an MCP gateway](/blog/when-you-dont-need-an-mcp-gateway/) applies unchanged. The case changes when a contractor joins the rotation, or when someone has to show who added which note from which client. The [connector catalog](/connectors/) lists the other apps an engineering role reaches, and [use cases](/use-cases/) shows the same pattern for other teams.

## FAQ

### Does PagerDuty have its own MCP server?

Yes. PagerDuty hosts one at https://mcp.pagerduty.com/mcp, with https://mcp.eu.pagerduty.com/mcp for EU accounts, and its older self-hosted server is deprecated and archived. It accepts a PagerDuty API key or OAuth. PagerDuty's page says tool filtering is not directly available on the hosted server and that a Scoped OAuth client limits which tools succeed (support.pagerduty.com, checked October 2026).

### Can I make PagerDuty read-only for an AI client?

Yes, in two places. In PagerDuty, a general access REST API key can be created as a Read-only API Key, which restricts it to GET calls. In Elaichi, an allow rule on the engineer role that names only PagerDuty read tools leaves every create, update and delete tool restricted for that role. The consent screen alone does not do it, because a connected app's writes run under "Run your connected tools".

### Is acknowledging a PagerDuty incident a separate tool?

No. In Elaichi's pagerduty connector, update_a_pagerduty_incident_by_id handles every change to the incident record. Its status field takes acknowledged or resolved, and the same call can change assignments, the escalation level, priority and urgency. Allowing acknowledge therefore allows resolve, reassign and escalate too. Alerts are separate: update_a_pagerduty_incident_alert_by_id and pagerduty_incident_alerts_manage change them, and create_a_pagerduty_incident opens a new incident that pages people. All three stay off the engineer role.

### Should engineers share one PagerDuty connection or connect their own?

Their own, when they will add notes or take action. A shared connection in Elaichi runs every call on its owner's credential, so PagerDuty sees one person. PagerDuty says a user token REST API key is restricted to that user's own permissions, so a per-engineer connection keeps PagerDuty's own role in force. A shared connection on a read-only key suits a team that only reads.

### How long does a new PagerDuty rule take to reach engineers?

Within about two minutes. Restriction and role changes in Elaichi resolve through a short cache, on the MCP endpoint, in the console and over REST alike. Removing or suspending a member, revoking a share and disconnecting an account act on the next call instead.

## Read next

- [How to roll out Cursor to an engineering team](/blog/engineering-team-cursor-jira/) — To roll out Cursor to an engineering team, connect Jira and Slack once, block deletes per role, pin the project and channel, then have engineers sign in.
- [MCP for coding agents across an engineering org](/blog/coding-agents-company-tools/) — MCP for coding agents needs one endpoint, a sign-in per engineer, and rules the agent cannot edit, because nobody reads each call it makes.
- [Connect Elaichi to Claude Code](/blog/connect-elaichi-to-claude-code/) — To connect Elaichi to Claude Code, run one claude mcp add command and sign in with OAuth. The entry holds no secret, so a project .mcp.json is safe to commit.