Connect PagerDuty to ChatGPT: Manage Incidents and Schedules

If you need to connect PagerDuty to ChatGPT to automate incident response, manage on-call schedules, or orchestrate IT operations, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and PagerDuty's REST APIs. 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.

Giving a Large Language Model (LLM) read and write access to a critical enterprise system like PagerDuty is an engineering challenge. You have to handle OAuth 2.0 token lifecycles, map massive JSON schemas to MCP tool definitions, and deal with PagerDuty's specific rate limits. Every time PagerDuty updates an endpoint or deprecates a field, 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 ChatGPT, and execute complex workflows using natural language.

If your team uses Claude, check out our guide on connecting PagerDuty to Claude or explore our broader architectural overview on connecting PagerDuty to AI Agents.

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 aren't just integrating a simple list of tickets - you are dealing with a complex hierarchy of incidents, alerts, log entries, and schedules, all of which have different design patterns, error formats, and operational quirks.

If you decide to build a custom MCP server for PagerDuty, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with PagerDuty:

The Incident vs. Alert Hierarchy

PagerDuty separates incidents from the underlying alerts that triggered them. An LLM might say "show me the payload of this incident," but the incident object itself does not contain the raw monitoring payload. To get that, the MCP server must know to query the /incidents/{id}/alerts endpoint, parse the specific alert bodies, and map the custom context keys back to the LLM. If your tool definitions do not explicitly separate incidents and alerts, the LLM will hallucinate data that it assumes should be present on the incident record.

Offset Pagination and Cursors

When an LLM requests a list of historical incidents or audits a massive schedule, it cannot ingest 10,000 records at once. PagerDuty heavily relies on limit and offset cursors for pagination on older endpoints, while newer endpoints use different cursor structures. You have to write the logic to handle these pagination cursors and explicitly instruct the LLM to pass cursor values back unchanged to fetch the next set of records. Without this, the model will simply repeat the same API call infinitely.

Rate Limits and 429 Errors

PagerDuty enforces strict, tier-based rate limits. For example, standard REST API endpoints are typically capped at 900 requests per minute per account, while some reporting endpoints have much lower limits. When an LLM is rapidly scanning log entries to build a post-mortem, it is very easy to trigger a 429 Too Many Requests error.

It is critical to note how Truto handles this: Truto does not retry, throttle, or apply automatic backoff on rate limit errors. When the upstream PagerDuty API returns an HTTP 429, Truto passes that error directly back to the caller. Truto normalizes upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - in this case, ChatGPT or your agent orchestrator - is entirely responsible for reading these headers, interpreting the reset time, and implementing its own retry or backoff logic.

The Managed MCP Approach

Instead of forcing your engineering team to build boilerplate infrastructure, deal with OAuth token refreshes, and map complex schemas to JSON-RPC 2.0 format, you can use Truto.

Truto's MCP server feature turns any connected PagerDuty integration into an MCP-compatible tool server dynamically. Rather than hand-coding tool definitions, Truto derives them from PagerDuty's API resource definitions and documentation records. This dynamic generation happens in real-time, meaning your AI agent always has the most up-to-date schema.

Each MCP server is scoped to a single integrated account. The server URL contains a cryptographic token that encodes which account to use, what tools to expose, and when the server expires. The URL alone is enough to authenticate and serve tools to ChatGPT.

Step 1: Create the MCP Server

You can create an MCP server for PagerDuty either through the Truto dashboard or programmatically via the API.

Method 1: Via the Truto UI

1. Log into your Truto account and navigate to the integrated account page for your connected PagerDuty instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can specify a name, filter allowed methods (e.g., read-only), filter by tags, and set an expiration date.
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the API For programmatic workflows, you can generate the MCP server dynamically by making an authenticated POST request to the Truto API. The API validates the configuration, generates a secure hashed token, and returns a ready-to-use URL.

// POST /integrated-account/:id/mcp
 
const response = await fetch('https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TRUTO_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "PagerDuty Incident Response Agent",
    config: {
      methods: ["read", "write"], 
      tags: ["incidents", "schedules", "users"]
    },
    expires_at: null
  })
});
 
const mcpServer = await response.json();
console.log(mcpServer.url); 
// "https://api.truto.one/mcp/a1b2c3d4e5f6..."

Step 2: Connect the Server to ChatGPT

Once you have your Truto MCP server URL, you need to register it with ChatGPT.

Method A: Via the ChatGPT UI If you are using ChatGPT with Advanced Settings enabled (available on Pro, Plus, Business, Enterprise, and Education accounts), connecting is a matter of pasting the URL.

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Toggle Developer mode on (this enables MCP support).
3. Under MCP servers / Custom connectors, click to add a new server.
4. Enter a name (e.g., "PagerDuty via Truto").
5. Paste the Truto MCP server URL you generated in Step 1.
6. Save the configuration. ChatGPT will automatically perform a protocol handshake, pull down the PagerDuty tool definitions, and make them available in your chat interface.

Method B: Via Manual Config File (for headless or custom environments) If you are using the OpenAI desktop app or orchestrating agents locally, you can map the URL using a configuration file and a Server-Sent Events (SSE) transport wrapper. Add the following to your mcp.json or claude_desktop_config.json equivalent:

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

Security and Access Control

Connecting an LLM to PagerDuty carries risk. You do not want a hallucinating agent deleting users or wiping out critical escalation policies. Truto provides four distinct mechanisms to lock down your MCP server:

• Method Filtering: By defining config.methods, you can restrict the server to specific operation types. Setting this to ["read"] ensures the agent can only call get and list endpoints, making it physically impossible for the LLM to alter PagerDuty data.
• Tag Filtering: You can restrict the server to specific domains using config.tags. If you only want an agent to read schedules but not incidents, setting tags to ["schedules"] completely hides the incident-related tools from the LLM.
• Secondary Authentication (require_api_token_auth): By default, possessing the MCP URL grants access. By setting require_api_token_auth: true, the client must also pass a valid Truto API token in the Authorization header. This ensures only authenticated internal services can execute calls.
• Time-To-Live (expires_at): You can set an exact ISO datetime for the server to self-destruct. This is perfect for granting temporary access to external contractors or spinning up ephemeral troubleshooting environments during a major incident.

Hero Tools for PagerDuty

When ChatGPT connects to your PagerDuty MCP server, it gains access to dozens of dynamically generated tools. Here are six high-leverage tools that unlock powerful IT operations workflows.

list_all_pager_duty_incidents

This tool retrieves a list of incidents from the PagerDuty account. It supports robust querying, allowing the LLM to filter by urgency, status (triggered, acknowledged, resolved), and specific date ranges.

"Fetch all triggered high-urgency incidents from the last 2 hours. Summarize the incident titles and IDs in a markdown table."

get_single_pager_duty_incident_by_id

Once an LLM has an incident ID, this tool fetches the comprehensive details of that specific incident. It returns the summary, status, creation timestamps, the service affected, current assignments, and escalation policy context.

"Get the full details for incident ID P12345. Tell me who is currently assigned to this incident and what service is degraded."

create_a_pager_duty_incident_note

This tool allows the LLM to write back to PagerDuty. Notes are critical for incident documentation and hand-offs. The LLM can gather context from Slack or external dashboards and append a summarized timeline directly to the PagerDuty incident record.

"Add a note to incident ID P12345 stating: 'Initial triage complete. CPU spike identified on US-East-1 database cluster. Escalating to the DBA team.'"

list_all_pager_duty_schedules

This tool retrieves all on-call schedules in the PagerDuty account. It returns the schedule names, descriptions, and the complex time periods defining when specific users are on-call. It is incredibly useful for mapping out the current operational coverage.

"List all the current on-call schedules. Identify the ID for the 'Primary Database Operations' schedule."

list_all_pager_duty_on_calls

This tool is vital for knowing who is currently holding the pager. By passing a schedule ID, the LLM can fetch the exact user who is currently on call, avoiding the need to manually interpret complex schedule layers.

"Check who is currently on-call for the 'Primary Database Operations' schedule. Return their name and email address."

create_a_pager_duty_incident

This tool empowers the LLM to programmatically trigger new incidents. It requires specific fields like the incident type, title, service ID, and escalation policy ID. This is often used when an agent identifies an anomaly in external logs and decides manual intervention is required.

"Create a new high-urgency incident on service ID S9876. Title it 'Automated Alert: Unusually high latency detected in payment gateway'. Route it to escalation policy E4567."

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

Workflows in Action

When you connect PagerDuty to ChatGPT via Truto's MCP, you move beyond simple queries and enable multi-step, autonomous workflows. Here are two concrete examples of how this looks in practice.

Scenario 1: Automated Triage and Context Gathering

A site reliability engineer is woken up by a generic page and wants to instantly understand the state of the system before logging into a dashboard.

"List all active triggered incidents right now. For the newest incident, fetch its full details and summarize the impact. Then, find out who is on call for the 'Network Infrastructure' schedule so I know who to pull into the war room."

Tool Execution Sequence:

1. list_all_pager_duty_incidents (with parameters statuses=["triggered"])
2. get_single_pager_duty_incident_by_id (passing the ID from step 1)
3. list_all_pager_duty_schedules (searching for the Network Infrastructure schedule ID)
4. list_all_pager_duty_on_calls (passing the schedule ID found in step 3)

Result: ChatGPT replies with a concise summary of the active incident, names the affected service, and explicitly provides the name and email of the network engineer who is currently on-call, saving the user 10 minutes of frantic dashboard navigation.

Scenario 2: Creating an Incident and Documenting Findings

A support engineer notices a flood of customer complaints regarding login failures. They need to escalate the issue immediately while capturing their initial investigation.

"I need to escalate a login failure issue. Create a new high-priority incident for the 'Authentication Service' (ID: SAUTH1). Once created, append a note to it saying 'Customer support reports a 40% spike in login timeouts over the last 15 minutes. Logs show Redis connection drops.'"

Tool Execution Sequence:

1. create_a_pager_duty_incident (passing title, service.id, and urgency: high)
2. create_a_pager_duty_incident_note (passing the newly created incident id and the content string)

Result: ChatGPT successfully triggers the incident, kicking off the PagerDuty escalation policies to wake the right people up. It then immediately writes the initial triage context directly to the incident timeline, ensuring the responding engineers have immediate visibility into the problem without having to dig through separate Slack channels.

Stop Building Boilerplate

Building a reliable PagerDuty integration for AI agents requires mapping dense incident hierarchies, building resilient cursor pagination logic, and handling strict rate limit headers without dropping context. You can either allocate your engineering team to maintain this REST plumbing indefinitely, or you can use a managed platform that handles it out of the box.

Truto abstracts the complexity of third-party APIs into secure, dynamically generated MCP servers. You get instant access to well-documented tools, built-in security filters, and zero maintenance overhead when the underlying API schemas drift.