Why on-call engineers ask for PagerDuty in their AI client
It is 3am and the person who got paged is reading a phone screen. They want the incident, its alerts, its notes, who else is on call, and whether something like this has happened before. By hand that is three screens and a search back through months of incidents. An AI client that can call PagerDuty answers it in one question.
MCP (Model Context Protocol) is the open standard that lets an AI client discover and call tools on a server. A PagerDuty MCP server for on-call engineers comes in two shapes. One is PagerDuty's own hosted server. The other is PagerDuty reached through one governed endpoint (a single address an AI client signs in to) beside the team's other apps. What the engineer types looks the same either way. Whose credential runs the call, which tools exist, and what gets written down afterwards do not.
What PagerDuty's own MCP server gives you
PagerDuty hosts a remote MCP server itself, with nothing to install. Its documentation gives the address as https://mcp.pagerduty.com/mcp, with https://mcp.eu.pagerduty.com/mcp for accounts in its EU service region, and lists a PagerDuty account with Advanced Permissions as a requirement. The older self-hosted server is deprecated and its repository is archived (checked October 2026, PagerDuty's MCP server docs). That archived server exposed only read-only tools by default, and needed an --enable-write-tools flag before anything could change the account (checked October 2026, the archived repository).
Sign-in takes a PagerDuty API key sent in an Authorization header, or OAuth through static client credentials or a bearer token. The same page says PagerDuty does not currently support Dynamic Client Registration, and documents setup for Cursor, Visual Studio Code and Claude Code (checked October 2026, PagerDuty's MCP server docs).
Its tools come in two families: browse_ tools that read, and manage_ tools that change. manage_incidents covers create, update, add_note, add_responders and start_workflow. manage_schedules covers create, update and create_override. PagerDuty's page says tool filtering is not directly available for its hosted server, and that a Scoped OAuth client can limit which tools succeed (checked October 2026, PagerDuty's MCP server docs). That is the sentence a security reviewer will stop on.
What a PagerDuty MCP server for on-call engineers changes in the permission model
The identity on the wire decides everything the AI can reach. PagerDuty offers three ways to shape it, and they are not equivalent.
A general access REST API key can be created read-only, which restricts it to GET calls, and Admins or the Account Owner create those keys. A user token key is restricted to that user's own permissions. An operation that user may not perform returns 403. A scoped OAuth app's user token reaches only data the authorizing person can access, further limited by the app's approved scopes. Its actions appear in PagerDuty under that person's name, and scopes name a resource type plus read or write, such as incidents.read. Under Advanced Permissions, an Observer views without changing things. A Responder can act on incidents, create incidents for any team and create schedule overrides. A Manager has full create, update and delete (checked October 2026: API access keys, scoped OAuth apps and advanced permissions).
Elaichi's own PagerDuty connector signs in with OAuth or an API key. Every call through a connection uses the account that connection was made with, whoever is calling. So an engineer who wants their own PagerDuty permissions to apply connects their own PagerDuty account. A connection one person shares with the team runs every teammate's call on that one person's sign-in, which is sometimes what you want and never an accident worth stumbling into.
On Elaichi's side of the wire, each call acts as one named person. Each engineer connects their AI client once and approves their own grant (the OAuth authorization behind their token), and their role permissions are read on every request rather than frozen into the token.
What the on-call engineer sees at the client
One address and a browser sign-in. Elaichi serves MCP at https://api.elaichi.ai/mcp, the same string for every organization. The grant behind the token decides which organization and which person a client reaches, not the URL. Claude, ChatGPT and Cursor all sign in there. The Claude-side walkthrough of this same team covers the client steps in order.
The tool list is shorter than people expect, because connected tools are never listed one by one, however few there are. The model finds one with search_tools and runs it with execute_tool, or with run_code where Code Mode is available. An engineer asking who is on call for payments right now gets a search, then a call to list_all_pagerduty_on_calls. The client's list never fills up with PagerDuty's tool surface.
Two consequences follow. A client control that approves or blocks individual MCP tool names sees execute_tool, not "update a PagerDuty incident", so per-app control belongs in Elaichi rather than in the client. And a tool a restriction withholds is not invisible. search_tools still names it, flagged as restricted, with no schema and no way to call it, plus a count of the other restricted matches. The engineer learns what to ask an admin for instead of guessing.
Which PagerDuty calls count as deletes
Elaichi's PagerDuty connector carries 157 tools: 81 reads, 26 creates, 25 updates, 21 deletes and 4 others. All 21 deletes are HTTP DELETE calls, which Elaichi tiers destructive. Everything else that is not a read is tiered write, including create_a_pagerduty_override, create_a_pagerduty_maintenance_window, update_a_pagerduty_schedule_by_id and update_a_pagerduty_escalation_policy_by_id.
The destructive set is worth reading by name. It includes 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. The write tier is not harmless either. PagerDuty's docs say that while a service is in a maintenance window its integrations are disabled and no new incidents trigger (checked October 2026, maintenance windows). That is the quietest way to lose a page.
Here is the trap. Over MCP, the consent checkbox "Run your connected tools" runs every tier of connected tool, deletes included. "Delete data and remove access" covers Elaichi's own deletes, not a connected app's. No consent choice makes PagerDuty read-only for a client. Holding one to reads means choosing toolboxes of read tools at consent, or writing restrictions.
Holding an on-call role to the tools it needs
Write the rule on the role, and name what the role may reach rather than what it may not. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.
A block-only layer leaves everything it does not name reachable. Blocking a handful of PagerDuty's write tools leaves the other 70-odd in place. Two approaches work. One is an allow rule naming the exact tools the role may call. The other is block rules naming all 76 PagerDuty tools that are not reads. The allow rule is shorter, with one condition: once a role carries any allow rule, everything none of its allow rules names is blocked, so the role also needs allow rules for every other app it uses.
For an on-call responder the useful set is small. The reads cover the incident, its alerts, its notes, its log entries, on-call lookups, schedules, escalation policies and services. Two writes do the rest. update_a_pagerduty_incident_by_id is the one tool that changes the incident record, taking status acknowledged or resolved, assignments, escalation level, escalation policy, priority, urgency and title. create_a_pagerduty_incident_note adds the note. Leave the 21 deletes, the schedule and escalation-policy edits and the maintenance-window tool off the responder role. Keep those for whoever runs the rota. If you are weighing granularity, blocking one tool against blocking the whole app is its own decision.
Two mechanics decide whether the rule holds. Allow rules match the operation Elaichi pinned when the rule was saved, not the label the tool is shown under, so a rename cannot slip past governance; block rules match either. And a change to a role, a restriction or an access grant takes effect about two minutes. It does not land on the client's next call: revoking a grant or removing a member does. Plan the rollout around that, and read who may do what, in which app before writing the first rule.
When a responder hits a block, the refusal says whether it came from their role or their own account. They can file their own access request from the client. An admin decides it in the Elaichi console under Governance, then Access requests. No AI surface can approve one.
What the audit log keeps afterward
One row per connected-tool call that reaches execution. It records the person, the tool's advertised and catalog names, the connector, and the connection the call actually reached. It also records the tier, how approval was given, the surface the call came from, and the MCP client's id when that surface is mcp.
A call refused earlier, by a restriction or a missing scope, writes no row. So the log is a record of what ran, not of everything attempted. Elaichi keeps 90 days of that history, and for longer, export to your own Datadog comes with the Black plan, which is launching soon. PagerDuty's own trail stays where it is, and list_all_pagerduty_audit_records reads it from the same chat.
When PagerDuty's own server is the right answer
If PagerDuty is the only app your engineers want in their AI client, use PagerDuty's own hosted server and stop reading. It adds no second vendor and needs nothing installed. PagerDuty's Advanced Permissions roles and a scoped OAuth client already narrow what a token can do. A governed endpoint earns its place when there are several apps, several AI clients, and somebody has to answer who could do what, in one place, with dates.
Be clear about what it does not add. Elaichi does not ask a person before a write runs over MCP. The grant is the approval, decided once on the consent screen for that named client. Any per-call prompt an engineer sees is their client's own behavior. If you want a pause before each acknowledge or resolve, that pause lives in the client. Cursor, for one, asks for approval before using MCP tools by default (checked October 2026, Cursor's MCP docs).
A team already running PagerDuty's own server can bring it under the same rules rather than replace it. An Org Owner or Org Admin on Gold can add a remote MCP server as the organization's own connector, using the organization's own pre-registered OAuth client or an API token declared as config, since PagerDuty's page says it does not support Dynamic Client Registration (checked October 2026, PagerDuty's MCP server docs). The argument for putting a vendor's server behind a governed endpoint does not change: restrictions, scopes and one audit row per call. To see what a connector carries before planning any of this, read it off the PagerDuty connector page, or browse the whole catalog.
