Your agent needs to work with PagerDuty. It has to read triggered incidents, figure out who is on call, add a triage note, and resolve the ones that self-healed. PagerDuty ships an official MCP server in two shapes, local and PagerDuty-hosted, alongside a REST API that has been in production for a decade. Both paths work. They diverge on capability coverage, on how much of the tool surface lands in your context window, and on whether the agent acts as a real responder or as an account-level token. Here is the decision framework.
These are two different distribution shapes over roughly the same backend. Establishing what each one is takes a minute, and the differences start immediately.
PagerDuty maintains an official MCP server with two deployment modes. The local server runs as a subprocess via uvx pagerduty-mcp or Docker and authenticates with a PagerDuty User API token. The PagerDuty-hosted remote server is a managed HTTP endpoint at https://mcp.pagerduty.com/mcp, with an EU variant at https://mcp.eu.pagerduty.com/mcp.
Both modes are documented at the PagerDuty MCP Server site, with the hosted endpoint specified separately as the PagerDuty MCP API on the developer portal.
The PagerDuty REST API is the full configuration and incident surface: incidents, alerts, services, teams, users, schedules, escalation policies, maintenance windows, log entries, analytics, and audit records. It is versioned through the Accept header.
Two adjacent APIs matter for agents and are not part of REST. The Events API v2 triggers, acknowledges, and resolves alerts with a service-level routing key. Webhook subscriptions push incident state changes to your endpoint instead of making you poll.
Four dimensions decide this: what the agent can do, how it authenticates, what the tool surface costs you, and what you are left owning in production.
The MCP server covers the incident response loop well. Reading and filtering incidents, pulling related and past incidents, listing on-calls, reading escalation policies, starting incident workflows, posting status page updates, and pulling MTTA and MTTR aggregates are all first-class tools.
The gaps are not obscure. They cluster around org configuration, event ingestion, and compliance reporting, which is exactly where scheduled and background agents live.
Three of those gaps are structural rather than temporary. The Events API v2 is a separate ingestion pipeline keyed on integration keys, not a REST endpoint waiting to be wrapped as a tool. Webhook subscriptions are a push model, and MCP has no event subscription surface at all.
The third is quieter. An agent that suppresses alerts during a deploy needs maintenance windows, and there are no maintenance window tools on the MCP server. An agent that answers "who changed this escalation policy and when" needs the Audit Records API. Neither exists on the MCP path today.
This is where PagerDuty diverges from most MCP servers. The hosted remote server supports API tokens through an Authorization: Token token=... header and OAuth through metadata discovery, and it also accepts a bearer token directly, including an App OAuth Token obtained through a client_credentials grant.
That means the usual "MCP cannot run headless" argument does not hold cleanly for PagerDuty. What does hold: PagerDuty does not support Dynamic Client Registration (DCR), so every MCP client needs a pre-registered OAuth client.
PagerDuty's remote MCP documentation is explicit that some tools and filters require user-level authentication. Scoping list_incidents by teams or assigned is the named example, and "what is assigned to me" is the single most common question an on-call agent gets asked.
The REST API offers the same three-way choice with sharper edges. General Access REST API keys are account-wide and admin-created, with an optional read-only flag. User Token REST API keys inherit exactly that user's permissions and return 403 Forbidden on anything they are not allowed to do. Scoped OAuth apps, registered through App Registration, add per-object read and write scopes on top.
PagerDuty's own rate limit guidance notes that global API keys may be deprecated in future for security reasons, and recommends a scoped OAuth app per environment instead of a shared key.
Read that as a roadmap signal, not a footnote. If your PagerDuty agent is standing on a general access key today, the migration to per-user OAuth or a scoped app is work you have already agreed to do. Doing it before it becomes urgent is cheaper. For a deeper look at this pattern, see why static credentials break in production AI systems.
72 tools is a lot to put in front of a model. At roughly 200 tokens per tool definition, a full PagerDuty MCP surface costs somewhere near 14,000 tokens of context before your agent reads a single incident. At thousands of runs a day that is a real line item.
Accuracy degrades alongside cost. A model choosing between manage_incidents, update_service, create_schedule_override, and append_event_orchestration_router_rule in the same decision space picks wrong more often than one choosing among five relevant tools. This is one reason MCP can be significantly more expensive than CLI-based approaches at scale.
PagerDuty's documentation says directly that too many tools hurts AI performance, and recommends mcp-proxy to expose only the subset a workflow needs.
The catch is in the remote server docs: the proxy approach requires a local subprocess to intercept calls, so it is not available for the hosted server. On remote, your only filter is a Scoped OAuth client, which limits which tools will succeed rather than which tools the model sees. The tokens are still spent. The wrong tool is still selectable.
On the MCP path, PagerDuty owns hosting, tool schemas, and endpoint normalization. You own the OAuth client registration, per-user token storage, refresh, revocation on offboarding, and tenant isolation. MCP tool schemas change when PagerDuty ships a server update, and there is no version pin.
On the REST path you own more and control more: endpoint selection, pagination, retry behavior on 429 using the ratelimit-limit, ratelimit-remaining, and ratelimit-reset headers, and the same full token lifecycle. Note that the "Manage incidents" endpoint carries its own tighter cap of 500 requests per minute.
The MCP path fits when the human is present and the tool surface is being driven by a person, not a scheduler.
The API path fits when the agent runs on a schedule, acts for many users, or touches surfaces the MCP server does not expose.
Scalekit sits between those two paths rather than picking one. The connector wraps the REST API with per-user OAuth and prebuilt tool schemas, and Virtual MCP servers let you serve those same tools over MCP when you want the MCP shape.
The Scalekit PagerDuty connector is OAuth 2.0 and ships 42 prebuilt tools at the time of writing, covering incidents, services, teams, users, schedules, escalation policies, on-calls, log entries, notifications, and maintenance windows.
Worth naming honestly: the coverage is not identical to PagerDuty's MCP server. Scalekit has maintenance windows and full escalation policy and user writes, which MCP lacks. PagerDuty's MCP server has event orchestrations, status pages, change events, and analytics aggregates, which the Scalekit connector does not. Check both tool lists against your agent's actual job.
Install the SDK and the framework, then initialize once. The connection_name string must match the connection name configured in your Scalekit dashboard, which is the single most common integration error on first run.
The agent never sees a PagerDuty token. It resolves a connected account, and if that account is not ACTIVE, you send the user an authorization link and stop.
Before any tool list reaches the model, one thing needs stating: this is not a connector catalog. actions.langchain.get_tools returns the tools this specific user's connected account is authorized to call, filtered further to the four this agent actually needs. Four tools, not 42, and not 72. This scoped approach is one of the core tool calling auth patterns for production agents.
If you are on Node and calling Anthropic directly, listScopedTools gives you raw JSON Schema you can hand to the Messages API without reshaping, and executeTool runs the call with the user's vaulted credential.
The loop below shows the full cycle: message construction, the messages.create call with tools, the stop_reason check, tool result construction, and the append back onto the transcript.
If your agent framework or IDE speaks MCP, you do not have to choose between the MCP shape and per-user scoping. A Virtual MCP server is a scoped endpoint declaring exactly which connections and tools it exposes and whose credentials it acts with, created once per agent role.
Two objects drive the model. The server is created once and yields a static mcp_server_url. A session token is minted before each run and bound to one user's connected accounts. One server definition serves all users, with no credential sharing between them.
OAuth credentials expire and get revoked. Check state before every run, surface the re-auth link if the connection is not ACTIVE, and mint a fresh short-lived token rather than reusing one.
An on-call agent is rarely PagerDuty-only. It reads PagerDuty, checks the deploy in GitHub, and posts to Slack. Three connectors, three OAuth dialects, three token lifecycles, and one context window that fills up fast if each connector arrives at full catalog size.
Virtual MCP servers collapse that into one endpoint per agent role with an explicit tool allowlist across connectors. The endpoint stays static across your entire tenant base. The identity does not, because it is carried by the session token. For a full treatment of how tool calling auth changes between single-tenant and multi-tenant architectures, that post covers the tradeoffs in detail.
Scoping controls what can happen. Logs tell you what did. Scalekit records every tool call with the user who authorized it, retained for 90 days and exportable to your SIEM, so a PagerDuty write is traceable to a human rather than to a service account.
This is the difference between passing a SOC 2 control and arguing about it. The audit trail requirements for agent auth in B2B SaaS are becoming a standard part of enterprise evaluations.
Whichever path you pick, the credential lifecycle lands on you. Neither PagerDuty's MCP server nor its REST API stores, rotates, or revokes anything on your behalf.
A multi-tenant incident agent serving 8 customer accounts with 40 responders between them has 40 credentials to encrypt at rest, isolate per tenant, refresh, and revoke. The MCP OAuth flow produces one token per user. The REST OAuth flow produces one token per user. Same arithmetic, different issuer.
The offboarding case is where this stops being theoretical. A responder leaves, their SSO is disabled, and a PagerDuty user API token generated eleven months ago is still sitting in a config file. The agent does not decide to keep using it. It just does. This is exactly the scenario described in when an employee leaves, who revokes their AI agent's access.
PagerDuty requires a From header carrying a valid user's email on write operations, which is why every write tool in the Scalekit connector takes a required from_email. With per-user OAuth, that value and the credential describe the same person.
With a shared account-level token, they do not have to. The agent supplies an email string and PagerDuty records it. Your incident timeline now says a human acknowledged something that a background job acknowledged, and nothing in the audit trail contradicts it.
Scalekit's PagerDuty connector handles the OAuth flow, AES-256 vaulted token storage namespaced per tenant, automatic refresh, and revocation as a single action. Credentials resolve server-side before each call and never reach the agent runtime or the LLM context.
The same infrastructure serves both paths. Choosing MCP or the REST API changes the token type and the tool shape. It does not change what you need at the credential layer. For more on how secure token management works for AI agents at scale, that post covers storage, rotation, and expiry in depth.
If your PagerDuty agent is interactive and runs beside a present engineer in an IDE, the official MCP server is the shorter road, provided you can run mcp-proxy locally to cut 72 tools down to the handful the workflow needs.
If it runs on a schedule, needs maintenance windows or webhook subscriptions or the Events API v2, or acts for responders across multiple customer accounts, build against the API and enforce per-user scoping at the infrastructure layer.
Most production incident agents end up running both, with the interactive assistant on MCP and the scheduled pipeline on REST. The credential management problem is identical either way, and that is the part that needs production-grade infrastructure.
Start with the Scalekit PagerDuty connector docs and the Virtual MCP server guide.
If you are working through per-user scoping, From header attribution, or multi-connector on-call agents, join the Scalekit Slack community or talk to an engineer for immediate help.
