Provider REST API

12 actions

Connect Claude to PagerDuty

Triage incidents, acknowledge and resolve pages, and see who is on call. Toolspoke puts 12 of its actions behind one MCP endpoint that Claude, Cursor, and Codex all speak.

Connect View pricing

Connection: Provider REST API
Authentication: API key
Actions exposed: 12
Cost per call (typical): 1 credit
Adapter: Maintained by Toolspoke

Connected in three steps

1
Install PagerDuty
Open the marketplace in your workspace, add PagerDuty to the project your agents work in, and it appears on the gateway immediately.
2
Connect the credential
Authenticate with api key. Where to get one, and what it has to be able to reach, is the next section.
3
Point your agent at the gateway
Give your client one address, https://toolspoke.com/mcp. Claude Code takes it as a command, Claude and Claude Desktop add it as a custom connector, and Cursor, Codex and VS Code each read it from a config file of their own.

.mcp.json

{
  "mcpServers": {
    "toolspoke": {
      "type": "http",
      "url": "https://toolspoke.com/mcp"
    }
  }
}

One block covers every tool you have installed. PagerDuty shows up in the client as soon as your policy allows it, and so does everything else you install later.

Where the address goes, per client

Claude Code: Run it in your project, then /mcp to sign in
claude mcp add --transport http toolspoke https://toolspoke.com/mcp
Claude and Claude Desktop: Settings, then Connectors, then Add custom connector
https://toolspoke.com/mcp
Cursor: ~/.cursor/mcp.json, or .cursor/mcp.json for one project
{ "mcpServers": { "toolspoke": { "url": "https://toolspoke.com/mcp" } } }
Codex: ~/.codex/config.toml
[mcp_servers.toolspoke] url = "https://toolspoke.com/mcp"
VS Code: .vscode/mcp.json, or the MCP: Add Server command
{ "servers": { "toolspoke": { "type": "http", "url": "https://toolspoke.com/mcp" } } }

What PagerDuty asks for

API key. You provide it once, when you install the connector. Toolspoke encrypts it at rest and decrypts it only for the length of a single call, and the gateway attaches it to the outbound request itself, so it is never part of the arguments an agent sends.

REST API keyRequired: PagerDuty → Integrations → API Access Keys → Create New API Key. A read-only key covers every read action here; the writes need a full-access key.; y_NbAkKc66ryYTWUXYEu
Acting user's emailOptional: The login email of a PagerDuty user. Sent as the From header, which PagerDuty requires before it will create an incident, change an incident's status, or add a note. Leave blank to install read-only.; [email protected]

What Claude can do in PagerDuty

12 actions, each one declared and named by the connector rather than discovered at runtime. A workspace policy grants a person all of them, a hand-picked selection, everything on the read side, everything on the write side, or none.

Reads: 9Reads
Writes: 1Writes
Destructive: 2Destructive

Reads

Fetches data and changes nothing.

list_incidents
List incidents, newest first by default. Start here when triaging: pass statuses ["triggered","acknowledged"] to see only what is still open, and service_ids to narrow to one service. Returns the incident ids that get_incident, update_incident_status, add_incident_note and list_incident_log_entries all need.
get_incident
Fetch one incident in full: current status, who it is assigned to, its service, escalation policy, priority and the alert body it was created from. Call list_incidents first for the id. For the sequence of what happened - acknowledgements, escalations, notifications - call list_incident_log_entries instead.
list_incident_log_entries
Return the timeline of one incident: when it triggered, every acknowledgement, escalation, reassignment, notification and status change, in order. Use this to answer "why was nobody paged" or "how long did it sit unacknowledged", which get_incident cannot tell you.
list_services
List the services incidents are attached to, with their escalation policies and current status. Call this to turn a service name into the service id that list_incidents filters on and create_incident requires.
list_escalation_policies
List escalation policies with their rules and the schedules or users at each level. Use it to work out who an unacknowledged incident on a service will reach next, and how long each level waits.
list_oncalls
Answer "who is on call right now". Returns one entry per escalation level currently covered, naming the user, the schedule they are covering and the window. Filter by escalation_policy_ids to ask about one service's rota; pass since and until to ask about a future window instead of now.
list_users
List PagerDuty users with their names, emails, roles and teams. Use it to turn a person's name into the user id that list_incidents and list_oncalls filter on, and to check that an address is a real PagerDuty login before it is used as the acting user.
get_user
Fetch one user by id, with their contact methods, notification rules and teams. Call list_users first for the id. Use it to check how someone would actually be reached before deciding an escalation failed.
list_priorities
List the priority levels this account defines, most severe first, with the ids create_incident needs. Only accounts on Standard or Enterprise plans have priorities at all - an error here means the feature is not enabled, not that the key is wrong.

Writes

Creates or updates something on the other side.

add_incident_note
Append a note to an incident's timeline, which is how findings are handed to the next responder. The note is attributed to the connection's acting user, so the From email must be configured. Notes cannot be edited or removed afterwards.

Destructive

Deletes or permanently alters something. Worth granting on purpose.

create_incident
Declare a new incident on a service, which pages whoever that service's escalation policy puts on call. Get the service id from list_services and, if the account has them, a priority id from list_priorities. Use urgency low for something that should wait for working hours. Requires the From email to be configured, because PagerDuty attributes the incident to a real user.
update_incident_status
Acknowledge or resolve an incident. Acknowledging stops the escalation clock and tells the rota somebody has it; resolving closes it and stops all notification. Both change what the people on call see, and resolving an incident whose cause is still live means the next occurrence raises a fresh page. Requires the From email to be configured.

What it will not do

Enforced by the gateway rather than left to convention, which is why each of these can be stated flatly.

It cannot call anything else: The 12 actions above are the whole of it. A call to any other name is refused before it reaches PagerDuty rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time.
It reaches no further than your credential: Toolspoke holds no access to PagerDuty of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either.
It never hears from PagerDuty: Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in PagerDuty. An agent has to ask.
It does not smooth over provider limits: Toolspoke does not retry, queue or back off around PagerDuty's own rate limits. A call that PagerDuty refuses comes back to the agent as a failed call.

Before you connect it

What can Claude do in PagerDuty?

12 named actions: 9 that only read, 1 that write and 2 that delete or permanently alter something. They include list_incidents, get_incident and list_incident_log_entries. Nothing outside that list is reachable: the connector declares each operation by name rather than proxying whatever an agent asks for.

What credentials does the PagerDuty connector need?

API key. The connector asks for rest api key, and optionally acting user's email. Values are encrypted at rest and attached to the outbound request by the gateway, so they are never part of the arguments an agent sends and never reach the audit log.

Does the PagerDuty connector work with Cursor and Codex, or only Claude?

Any client that speaks MCP, and every one of them gets the same 12 actions. There is a single address, https://toolspoke.com/mcp. Claude Code adds it with claude mcp add --transport http, Claude and Claude Desktop take it as a custom connector in settings, Cursor reads it from .cursor/mcp.json, Codex from ~/.codex/config.toml, and VS Code from .vscode/mcp.json. Each of them signs in to the gateway itself, so there is no key to paste.

What does the PagerDuty connector not do?

The 12 actions above are the whole of it. A call to any other name is refused before it reaches PagerDuty rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time. Toolspoke holds no access to PagerDuty of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either. Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in PagerDuty. An agent has to ask. Toolspoke does not retry, queue or back off around PagerDuty's own rate limits. A call that PagerDuty refuses comes back to the agent as a failed call.

Can I limit which actions an agent can call?

Yes, in two places. The project switches PagerDuty's actions on and off one at a time, for everyone in the project at once, and the screen groups them by read, write and destructive so turning off everything that deletes is one click. An individual agent key can then be narrowed further, to particular toolkits in a project and to particular actions in a toolkit. Whatever it was granted, a key never reaches a project its owner cannot.

What gets recorded when an agent calls PagerDuty?

Every attempt, with the agent that made it and the person that agent belongs to, the full request payload, the response payload, the status, the duration, and the credits spent. Values whose key names a secret are masked out before the record is shown to anyone. An operation the connector marks as not retained never has its response body written at all, so the gateway keeps no second copy of what was read.

More observability connectors

Browse all of them