PagerDuty MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAGERDUTY_API_TOKEN | Yes | API User Token from PagerDuty |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_incidentsA | List PagerDuty incidents with optional filters. Args: status: Filter by status (triggered, acknowledged, resolved) urgency: Filter by urgency (high, low) limit: Maximum number of incidents to return (default: 25, max: 100) Returns: Dict with keys: - incidents: List of incident summaries - total: Total count - statuses_available: Valid status values - urgencies_available: Valid urgency values |
| get_incidentA | Get detailed information about a specific incident. Args: incident_id: PagerDuty incident ID (e.g., 'Q26N8MQQHA6R0P') Returns: Dict: Full incident details including description, timeline, alerts |
| get_my_incidentsA | Get incidents assigned to the current user. Returns: Dict with keys: - incidents: List of assigned incidents - total: Count of assigned incidents - user_email: Current user email |
| acknowledge_incidentA | Acknowledge an incident (mark as working on it). Args: incident_id: PagerDuty incident ID note: Optional acknowledgement note Returns: Dict: Updated incident information |
| resolve_incidentC | Resolve an incident with resolution notes. Args: incident_id: PagerDuty incident ID resolution: Resolution notes explaining how the incident was fixed Returns: Dict: Updated incident information |
| add_incident_noteA | Add a note to an incident (for investigation updates, findings, etc.). Args: incident_id: PagerDuty incident ID note: Note content Returns: Dict: Created note information |
| get_incident_alertsA | Get all alerts associated with an incident. Args: incident_id: PagerDuty incident ID Returns: Dict with keys: - alerts: List of alert details - total: Count of alerts |
| get_incident_timelineA | Get incident activity timeline (all status changes, notes, acknowledgements). Args: incident_id: PagerDuty incident ID Returns: Dict with keys: - timeline: List of log entries (chronological) - total: Count of entries |
| get_oncallA | Get current on-call schedules. Returns: Dict with keys: - oncalls: List of current on-call assignments - total: Count of on-call entries |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct resource and action: specific incident retrieval, user-specific incident listing, general listing, and incident lifecycle actions (acknowledge, resolve, note) are clearly separated. Specialized views like alerts and timeline also have unique purposes with no overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_incident, resolve_incident, list_incidents). The only slight deviation is get_my_incidents and get_oncall, but they still fit the verb_noun convention clearly.
With 9 tools, the server is well-scoped for incident management and on-call visibility. Each tool serves a distinct purpose without redundancy or unnecessary bloat.
The server covers the core incident lifecycle: list, view, acknowledge, resolve, add notes, plus related context (alerts, timeline, on-call). However, it lacks the ability to create or reassign incidents, which are common operational actions, representing a minor gap.