remote-capable server
The server can be hosted and run remotely because it primarily relies on remote services or has no dependency on the local environment.
Integrations
Provides tools for interacting with the PagerDuty API, enabling operations on incidents, services, teams, and users. Supports listing, filtering, and managing PagerDuty resources with automatic context-based filtering.
PagerDuty MCP Server
A server that exposes PagerDuty API functionality to LLMs. This server is designed to be used programmatically, with structured inputs and outputs.
Overview
The PagerDuty MCP Server provides a set of tools for interacting with the PagerDuty API. These tools are designed to be used by LLMs to perform various operations on PagerDuty resources such as incidents, services, teams, and users.
Installation
From PyPI
From Source
Requirements
- Python 3.13 or higher
- PagerDuty API key
Configuration
The PagerDuty MCP Server requires a PagerDuty API key to be set in the environment:
Usage
As Goose Extension
As Standalone Server
Response Format
All API responses follow a consistent format:
Error Handling
When an error occurs, the response will include an error object with the following structure:
Common error scenarios include:
- Invalid resource IDs (e.g., user_id, team_id, service_id)
- Missing required parameters
- Invalid parameter values
- API request failures
- Response processing errors
Parameter Validation
- All ID parameters must be valid PagerDuty resource IDs
- Date parameters must be valid ISO8601 timestamps
- List parameters (e.g.,
statuses
,team_ids
) must contain valid values - Invalid values in list parameters will be ignored
- Required parameters cannot be
None
or empty strings - For
statuses
inlist_incidents
, onlytriggered
,acknowledged
, andresolved
are valid values - For
urgency
in incidents, onlyhigh
andlow
are valid values - The
limit
parameter can be used to restrict the number of results returned by list operations
Rate Limiting and Pagination
- The server respects PagerDuty's rate limits
- The server automatically handles pagination for you
- The
limit
parameter can be used to control the number of results returned by list operations - If no limit is specified, the server will return up to {pagerduty_mcp_server.utils.RESPONSE_LIMIT} results by default
Example Usage
User Context
Many functions accept a current_user_context
parameter (defaults to True
) which automatically filters results based on this context. When current_user_context
is True
, you cannot use certain filter parameters as they would conflict with the automatic filtering:
- For all resource types:
user_ids
cannot be used withcurrent_user_context=True
- For incidents:
team_ids
andservice_ids
cannot be used withcurrent_user_context=True
- For services:
team_ids
cannot be used withcurrent_user_context=True
- For escalation policies:
team_ids
cannot be used withcurrent_user_context=True
- For on-calls:
user_ids
cannot be used withcurrent_user_context=True
schedule_ids
can still be used to filter by specific schedules- The query will show on-calls for all escalation policies associated with the current user's teams
- This is useful for answering questions like "who is currently on-call for my team?"
- The current user's ID is not used as a filter, so you'll see all team members who are on-call
Development
Running Tests
Note that most tests require a real connection to PagerDuty API, so you'll need to set PAGERDUTY_API_KEY
in the environment before running the full test suite.
To run only unit tests (i.e. tests that don't require PAGERDUTY_API_KEY
set in the environment):
To run only integration tests:
To run only parser tests:
To run only tests related to a specific submodule:
Debug Server with MCP Inspector
Contributions
Releases
This project uses Conventional Commits for automated releases. Commit messages determine version bumps:
feat:
→ minor version (1.0.0 → 1.1.0)fix:
→ patch version (1.0.0 → 1.0.1)BREAKING CHANGE:
→ major version (1.0.0 → 2.0.0)
The CHANGELOG.md, GitHub releases, and PyPI packages are updated automatically.
Documentation
Tool Documentation - Detailed information about available tools including parameters, return types, and example queries
Conventions
- All API responses follow the standard format with metadata, resource list, and optional error
- Resource names in responses are always pluralized for consistency
- All functions that return a single item still return a list with one element
- Error responses include both a message and a code
- All timestamps are in ISO8601 format
- Tests are marked with pytest markers to indicate their type (unit/integration), the resource they test (incidents, teams, etc.), and whether they test parsing functionality ("parsers" marker)
You must be authenticated.
Tools
A server that exposes PagerDuty API functionality to LLMs with structured inputs and outputs, enabling management of incidents, services, teams, and users.
- Overview
- Installation
- Requirements
- Configuration
- Usage
- Response Format
- User Context
- Development
- Contributions