Connect PagerDuty to Claude: Automate Workflows and Service Health

If you need to connect PagerDuty to Claude to automate incident triage, check on-call schedules, or orchestrate service health workflows, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and PagerDuty's REST API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting PagerDuty to ChatGPT or explore our broader architectural overview on connecting PagerDuty to AI Agents.

Giving a Large Language Model (LLM) read and write access to a critical operational system like PagerDuty is an engineering challenge. You have to handle API token lifecycles, map complex incident schemas to MCP tool definitions, and deal with strict rate limits during high-volume outages. Every time an incident payload changes or a new urgency state is introduced, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for PagerDuty, connect it natively to Claude, and execute complex Site Reliability Engineering (SRE) workflows using natural language.

The Engineering Reality of the PagerDuty API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against PagerDuty's APIs is painful. You are not just integrating "PagerDuty" - you are integrating an intricate web of Services, Escalation Policies, Incidents, Alerts, and Schedules, all of which have different data shapes and relational requirements.

If you decide to build a custom MCP server for PagerDuty, you own the entire API lifecycle. Here are the specific challenges you will face:

The Reference Expansion Problem PagerDuty's API relies heavily on references. When you fetch an incident, you don't get the full details of the assigned user or the escalation policy - you get a lightweight object with type: "user_reference" and an ID. To get Claude to understand who is actually working on the ticket, your MCP server must either handle secondary lookups automatically or expose complex include [] query parameters to the model. If you expose raw include [] arrays, the LLM will frequently hallucinate valid inclusion strings, resulting in HTTP 400 errors.

Incident State Transitions Updating an incident in PagerDuty is not a simple CRUD operation. An incident has a strict state machine: triggered -> acknowledged -> resolved. If Claude attempts to update an incident to resolved without passing the correct required fields (like the resolver's email header in some API versions), or tries to acknowledge an already-resolved incident, the API rejects the payload. Your MCP server must translate LLM intent into the strict state transitions PagerDuty demands.

Strict REST API Rate Limits PagerDuty enforces strict REST API rate limits to protect their infrastructure during major outages. Depending on your pricing tier, this is often capped at 900 requests per minute. If an AI agent attempts to summarize a massive incident backlog or recursively loops through log entries, it will quickly hit a 429 Too Many Requests error.

A factual note on rate limits: Truto does not automatically retry, throttle, or apply exponential backoff on rate limit errors. When the upstream PagerDuty API returns an HTTP 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (or the AI agent orchestration layer) is strictly responsible for interpreting these headers and executing retry/backoff logic.

How to Generate a PagerDuty MCP Server with Truto

Truto dynamically derives MCP tools directly from the underlying PagerDuty integration resources. Instead of hard-coding schemas, Truto parses the API documentation records and resource configurations, converting them into standard JSON-RPC 2.0 endpoints on the fly.

You can generate an MCP server scoped to a specific PagerDuty environment using either the Truto UI or the API.

Method 1: Via the Truto UI

If you want to quickly generate a server URL for local testing or to drop into the Claude Desktop app:

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected PagerDuty account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server. You can restrict the server to specific HTTP methods (e.g., read only) or apply tags to isolate specific operational domains (like incidents or on-call).
5. Click Create and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123def456...).

Method 2: Via the Truto API

For production workflows where you need to programmatically provision MCP servers for your customers or internal tooling, you can use the Truto token management API. This validates that tools are available, stores the hashed token in distributed edge storage, and returns a ready-to-use URL.

Make a POST request to /integrated-account/:id/mcp:

curl -X POST https://api.truto.one/integrated-account/<pagerduty_account_id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "SRE Claude Assistant",
    "config": {
      "methods": ["read", "write"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response contains the secure URL you will use to connect Claude:

{
  "id": "mcp_8f72b1...",
  "name": "SRE Claude Assistant",
  "config": {
    "methods": ["read", "write"]
  },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890..."
}

Connecting the MCP Server to Claude

Once you have the Truto MCP URL, connecting it to Claude requires no additional middleware. You can connect it via the user interface or a local configuration file.

Method A: Via the Claude UI (or ChatGPT)

Anthropic and OpenAI provide interfaces for adding custom tool endpoints directly into their web and desktop clients.

For Claude:

1. Open Claude Settings -> Integrations.
2. Click Add MCP Server.
3. Paste the Truto MCP URL.
4. Click Add. Claude will immediately handshake with the initialize endpoint, retrieve the PagerDuty tools via tools/list, and make them available in your chat context.

For ChatGPT (Parallel example):

1. Go to Settings -> Apps -> Advanced settings.
2. Enable Developer mode.
3. Under MCP servers / Custom connectors, add a new server.
4. Name it "PagerDuty SRE" and paste the Truto MCP URL.

Method B: Via Manual Config File

If you are using Claude Desktop or an orchestration framework that relies on a configuration file, you can map the Server-Sent Events (SSE) transport natively using the standard MCP CLI.

Edit your claude_desktop_config.json file:

{
  "mcpServers": {
    "pagerduty-production": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890..."
      ]
    }
  }
}

Restart Claude Desktop. The model now has direct, authenticated access to PagerDuty.

PagerDuty Hero Tools for AI Agents

Truto normalizes PagerDuty's endpoints into descriptive, snake_case tool names with fully hydrated JSON Schema query and body parameters. Here are the highest-leverage tools available for your SRE automation.

list_all_pager_duty_incidents

Retrieves a paginated list of existing incidents representing problems or issues that need resolution. This is the foundation of any triage workflow. The schema allows Claude to filter by status (triggered, acknowledged, resolved), urgency, or specific service IDs. Truto normalizes the pagination parameters into limit and next_cursor so the LLM doesn't have to guess offset math.

"Show me all currently triggered incidents with high urgency across our production services."

get_single_pager_duty_incident_by_id

Fetches detailed information about a specific incident, including assignments, escalation policies, and exact timestamps. This is critical for agents needing deep context before attempting a remediation step.

"Get the full details for incident ID P12345. Who is currently assigned to it, and what is the exact summary?"

update_a_pager_duty_incident_by_id

Allows the LLM to mutate incident state. This tool can acknowledge an incident, reassign it, or resolve it entirely. The model must provide the specific incident ID and the required status payload.

"Acknowledge incident P12345 on my behalf and update the priority to P2."

create_a_pager_duty_incident_note

Adds a textual note to an incident timeline without changing its status. This is the primary way an AI agent leaves an audit trail, dropping investigation summaries, log snippets, or RCA (Root Cause Analysis) drafts directly onto the ticket.

"Add a note to incident P12345 stating: 'Automated agent checked the database CPU metrics and found no anomalies. Proceeding to check redis cache.'"

list_all_pager_duty_users_on_call

Queries the schedule to find exactly who is on the hook for a given rotation at this exact moment. Useful for escalations or knowing who to ping in a Slack war room.

"Who is currently on call for schedule ID SCHED99? I need their name and contact email."

list_all_pager_duty_services

Provides a directory of services configured in PagerDuty, complete with their linked escalation policies and status. Essential for agents that need to map a vague alert (e.g., "database is down") to a formal PagerDuty Service ID.

"List all our active PagerDuty services. I am looking for the one related to the European Payment Gateway."

To view the complete inventory of PagerDuty tools, schemas, and required parameters, visit the PagerDuty integration page.

Workflows in Action

MCP servers transform LLMs from passive text generators into active operational tools. Here is how a Claude agent executes real-world PagerDuty workflows to orchestrate incident response.

Workflow 1: Triage and Acknowledge (DevOps On-call)

An SRE is woken up by a page and uses Claude on their phone to perform initial triage while they get to their laptop.

"What are the current high-urgency triggered incidents? Acknowledge the newest one and leave a note that I am logging on to investigate."

1. list_all_pager_duty_incidents: Claude queries the incident list, filtering for status=triggered and urgency=high, sorting by created date.
2. update_a_pager_duty_incident_by_id: Claude extracts the ID of the most recent incident and sends a payload updating the status to acknowledged.
3. create_a_pager_duty_incident_note: Claude posts a note to the same incident ID containing the user's message, leaving a clear audit trail for the rest of the team.

The SRE arrives at their desk with the incident already acknowledged and the team informed.

Workflow 2: Finding Escalation Targets (Incident Commander)

An incident commander needs to pull a specific subject matter expert into a war room but does not know the exact schedule configuration.

"Who is currently on-call for the core database infrastructure, and what recent incidents are open for that service?"

1. list_all_pager_duty_services: Claude searches the service directory to find the specific ID for "Core Database Infrastructure".
2. list_all_pager_duty_users_on_call: Using the schedule associated with that service, Claude finds the active on-call engineer's details.
3. list_all_pager_duty_incidents: Claude queries the incidents list specifically filtered by the database service ID to see what is currently burning.

The commander instantly gets the name of the DBA to page and a summary of the active database alerts, saving crucial minutes of manual UI navigation.

Security and Access Control

Exposing an incident management system to an LLM requires strict boundary controls. Truto provides multiple layers of security at the MCP token level:

• Method Filtering: When generating the server, you can pass config: { methods: ["read"] }. Truto will intercept the documentation parsing phase and completely omit tools like create_a_pager_duty_incident or update_a_pager_duty_incident_by_id. The LLM physically cannot write data because the tools do not exist in its context.
• Tag Filtering: Limit the server to specific operational domains. By applying tags, you can restrict an agent to only interacting with schedules and users, preventing it from accessing incidents entirely.
• Extra Authentication (require_api_token_auth): By default, possessing the MCP URL grants access to the tools. Setting require_api_token_auth: true injects an authentication middleware layer. The client must supply a valid Truto API token in the Authorization: Bearer header, meaning the URL alone is useless if leaked.
• Time-to-Live (expires_at): For short-lived investigations or contractor access, supply an ISO datetime to expires_at. Truto schedules a distributed cleanup alarm that completely destroys the server configuration and edge storage keys at the exact second of expiration.

Orchestrating Operations with AI

Connecting PagerDuty to Claude via a custom integration requires handling complex pagination, parsing nested incident references, and writing boilerplate code for OAuth token refreshes. A managed MCP layer removes the infrastructure burden, allowing you to focus purely on prompt engineering and workflow design.

By dynamically generating tools based on strict documentation schemas, enforcing read/write boundaries, and passing native rate-limit headers back to the orchestration layer, Truto provides a production-grade bridge between LLMs and enterprise operations.