PagerDuty MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAGERDUTY_API_TOKEN | No | Your PagerDuty API token for authentication. | |
| PAGERDUTY_CLIENT_ID | No | Client ID for OAuth 2.0 PKCE authentication (required if not using API token). | |
| PAGERDUTY_CLIENT_SECRET | No | Optional client secret for OAuth token refresh (confidential client). | |
| PAGERDUTY_OAUTH_CALLBACK_PORT | No | Port for OAuth callback (default: 5173). | 5173 |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_escalation_policiesA | Get PagerDuty escalation policies by filters or get details for a specific policy ID. |
| get_incidentsB | Get PagerDuty incidents by filters or get details for a specific incident ID or number. |
| acknowledge_incidentB | Acknowledge a PagerDuty incident. This signals that someone is actively working on the incident. |
| resolve_incidentA | Resolve a PagerDuty incident. This marks the incident as resolved and stops any further escalations. |
| add_incident_noteA | Add a note to a PagerDuty incident. Notes are used to record additional context, investigation progress, or resolution details. |
| get_oncallsA | List on-call entries for schedules, policies, or time ranges. Behavior varies by time parameters:
|
| get_schedulesB | Get PagerDuty schedules by filters or get details for a specific schedule ID. |
| list_users_oncallC | List the users on call for a schedule during the specified time range. |
| get_servicesB | Get PagerDuty services by filters or get details for a specific service ID. |
| get_teamsA | Get PagerDuty teams by filters or get details for a specific team ID. |
| get_usersB | Get PagerDuty users by filters or get details for a specific user ID. |
| build_user_contextA | Validate and build the current user's context into a dictionary with the following format: { "user_id": str, "team_ids": List[str], "service_ids": List[str], "escalation_policy_ids": List[str] } The MCP server tools use this user context to filter the following resources: - Escalation policies - Incidents - Oncalls - Services - Users |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| get_tool_documentation |
TDQS
Scored across 12 tools
Most tools target distinct resources or incident actions, and the read tools are clearly resource-specific. The main potential overlap is between get_oncalls and list_users_oncall, which both concern on-call data but differ in whether they return entries or users; descriptions help but still leave minor ambiguity.
Almost all tools use consistent snake_case action-plus-object naming. The main deviation is list_users_oncall versus the get_* pattern used for other read/list operations, plus build_user_context as a special utility, but overall the convention is predictable.
Twelve tools is a well-scoped size for a PagerDuty integration, covering reads across key resources plus incident response actions. Each tool has a clear place and the set does not feel bloated or thin.
The core incident response workflow is represented with get_incidents, acknowledge_incident, add_incident_note, and resolve_incident, alongside reads for users, teams, services, policies, schedules, and oncalls. However, notable lifecycle operations are missing, such as creating/triggering incidents, updating or reassigning incidents, retrieving incident notes, and schedule overrides.