What can you do with this server?

The PagerDuty MCP Server provides programmatic access for LLMs to interact with the PagerDuty API, enabling management of various PagerDuty resources including: * Incidents: List, show details, and filter by status, service IDs, team IDs, or date range * Services: List and show details with optional filtering by query or team IDs * Teams: List and show details with optional query filtering * Users: List, show details, and access the current user's profile information * Escalation policies: List and show details with filtering options * Schedules: List and show details with optional query or date range filtering * On-call entries: List with filtering by schedule IDs, user IDs, policy IDs, or date range

Which integrations are available for this server?

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.

How do I use PagerDuty MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PagerDuty MCP Server show me the currently triggered incidents" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

PagerDuty MCP Server

by wpfleger96

Overview Schema Related Servers Score Discussions

Python

Remote

A server that exposes PagerDuty API functionality to LLMs. This server is designed to be used programmatically, with structured inputs and outputs.

PyPI Downloads Python Versions GitHub Contributors Lines of Code PyPI version License

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.

Related MCP server: Logseq MCP Server

Getting Started

Initialize your local Python environment:

cd pagerduty-mcp-server
brew install uv
uv sync

Configure authentication (see Authentication below).

Authentication

Priority: X-PagerDuty-Token HTTP header > PAGERDUTY_API_TOKEN environment variable > OAuth 2.0 PKCE

When running as part of a platform that injects per-request credentials, the server reads the X-PagerDuty-Token HTTP header. This takes highest priority and does not require any local configuration.

Option 2: API Token (Recommended for Most Users)

Set the PAGERDUTY_API_TOKEN environment variable, or add it to a .env file in the project root. The server will automatically load environment variables from the .env file if present.

Environment variable:

export PAGERDUTY_API_TOKEN=your_api_token_here

.env file (recommended):

echo "PAGERDUTY_API_TOKEN=your_api_token_here" > .env

Option 3: OAuth 2.0 PKCE (Local Interactive Use)

OAuth is available for local standalone usage. It opens a browser for authentication and stores tokens securely in the OS keyring. OAuth is opt-in — it only activates when PAGERDUTY_CLIENT_ID is set and no API token is present.

Setup:

Register a PagerDuty OAuth application at Integrations → Developer Tools → My Apps.
Set the required scope to read write.
Set the redirect URI to http://localhost:5173/oauth/pagerduty (default port).
Set the PAGERDUTY_CLIENT_ID environment variable to your application's client ID.

Optional configuration:

Set PAGERDUTY_CLIENT_SECRET to enable token refresh (confidential client).
Set PAGERDUTY_OAUTH_CALLBACK_PORT to override the default callback port (5173).

Usage

Claude/Cursor

{
  "mcpServers": {
    "pagerduty-mcp-server": {
      "command": "uvx",
      "args": ["pagerduty-mcp-server"],
      "env": {
          "PAGERDUTY_API_TOKEN": "<PAGERDUTY_API_TOKEN>"
      }
    }
  }
}

As Standalone Server

uv run pagerduty-mcp-server

Available Tools

Read Tools

get_escalation_policies — List or get details for escalation policies
get_incidents — List or get details for incidents (supports filtering by status, urgency, service, team, and time range)
get_oncalls — List on-call entries for a time range
get_schedules — List or get details for schedules
get_services — List or get details for services
get_teams — List or get details for teams
get_users — List or get details for users
list_users_oncall — List users on call for a specific schedule
build_user_context — Build a context object for the current authenticated user

Write Tools

acknowledge_incident — Acknowledge an incident (signals active investigation)
resolve_incident — Resolve an incident (stops further escalations)
add_incident_note — Add a note to an incident (for recording investigation progress or context)

The `include` Parameter

Most read tools accept an optional include parameter — a list of field names to return. When specified, only those fields are included in each response object, which reduces token usage in LLM contexts.

# Return only id, title, and status for each incident
get_incidents(include=["id", "title", "status"])

# Return only id and name for each service
get_services(include=["id", "name"])

See the tool documentation for the full list of available fields per tool.

Response Format

All API responses follow a consistent format:

{
  "metadata": {
    "count": "<int>",
    "description": "<str>"
  },
  "<resource_type>": [
    {
      "...": "..."
    }
  ],
  "error": {
    "message": "<str>",
    "code": "<str>"
  }
}

The error field is only present when an error occurs. Resource names in responses are always pluralized for consistency, even when a single item is returned.

Error Handling

When an error occurs, the response will include an error object with the following structure:

{
  "metadata": {
    "count": 0,
    "description": "Error occurred while processing request"
  },
  "error": {
    "message": "Invalid user ID provided",
    "code": "INVALID_USER_ID"
  }
}

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 in get_incidents, only triggered, acknowledged, and resolved are valid values
For urgency in incidents, only high and low 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

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 with current_user_context=True
For incidents:
- team_ids and service_ids cannot be used with current_user_context=True
For services:
- team_ids cannot be used with current_user_context=True
For escalation policies:
- team_ids cannot be used with current_user_context=True
For on-calls:
- user_ids cannot be used with current_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

The test suite includes both unit tests and integration tests. Integration tests require a real connection to the PagerDuty API, while unit tests can run without API access.

The pytest-cov args are optional, use them to include a test coverage report in the output.

To run all tests (integration tests will be automatically skipped if PAGERDUTY_API_TOKEN is not set):

uv run pytest [--cov=src --cov-report=term-missing]

To run only unit tests (no API token required):

uv run pytest -m unit [--cov=src --cov-report=term-missing]

To run only integration tests (requires PAGERDUTY_API_TOKEN set in environment):

uv run pytest -m integration [--cov=src --cov-report=term-missing]

To run only tests related to a specific submodule:

uv run pytest -m <client|escalation_policies|...> [--cov=src --cov-report=term-missing]

Debug Server with MCP Inspector

npx @modelcontextprotocol/inspector uv run pagerduty-mcp-server

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) and the resource they test (incidents, teams, etc.)

Example Queries

Are there any incidents assigned to me currently in pagerduty?
Do I have any upcoming on call schedule in next 2 weeks?
Who else is a member of the personalization team?

Available Tools

12 tools

acknowledge_incidentB

Acknowledge a PagerDuty incident. This signals that someone is actively working on the incident.

ParametersJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The ID of the incident to acknowledge (required).
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for the incident.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It mentions 'signals that someone is actively working' but omits details like status changes, permissions, or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with the action and immediate context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and simple parameters, the description lacks context on usage nuance versus siblings, e.g., when to acknowledge vs resolve.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema sufficiently describes parameters. The description adds no extra parameter meaning, resulting in baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'acknowledge' and resource 'incident', clearly distinguishing it from sibling tools like 'resolve_incident' or 'add_incident_note'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any preconditions or exclusions. It only states the basic action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_incident_noteA

Add a note to a PagerDuty incident. Notes are used to record additional context, investigation progress, or resolution details.

ParametersJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The ID of the incident to add a note to (required).
`content`	Yes	The text content of the note (required).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only describes the action as adding a note, without disclosing limits, append-only behavior, or whether notes can be edited/deleted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the main action and providing context in the second sentence with no redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists and the tool has low complexity (2 required params), the description adequately covers the purpose and parameter usage, though it lacks behavioral details. A score of 4 reflects it is mostly complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does not add any additional context beyond what the schema provides for the parameters 'incident_id' and 'content'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a note to an incident and explains the purpose of notes, distinguishing it from sibling tools like acknowledge or resolve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for adding context or progress, but does not explicitly state when to use this tool versus alternatives or mention prerequisites like incident ID validity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, description fully responsible. Discloses output format and filtered resources, but lacks info on side effects, authentication needs, or error cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph with key information front-loaded. Could be streamlined slightly but no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No parameters, output schema exists. Description explains output format and usage context adequately, though missing prerequisites like authentication state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, baseline 4. Description adds meaning by explaining output structure and purpose of the context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool validates and builds user context dictionary with explicit format. Distinguishes from siblings which are resource-specific tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for filtering resources before other tool calls, but no explicit when-to-use or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_escalation_policiesA

Get PagerDuty escalation policies by filters or get details for a specific policy ID.

ParametersJSON Schema

Name	Required	Description
`policy_id`	No	The escalation policy ID to retrieve (optional, cannot be used with any other filters).
`current_user_context`	No	Use current user's ID/team IDs context (default: True). Not used if `policy_id` is provided.
`query`	No	Policies whose names contain the search query (optional). Not used if `policy_id` is provided.
`user_ids`	No	Policies that include these user IDs (optional, excludes current_user_context). Not used if `policy_id` is provided.
`team_ids`	No	Policies assigned to these team IDs (optional, excludes current_user_context). Not used if `policy_id` is provided.
`limit`	No	Limit the number of results (optional). Not used if `policy_id` is provided.
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each escalation policy

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behaviors. It only states the basic retrieval operation without mentioning rate limits, pagination, or auth requirements. The read-only nature is implied but not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the action. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (7 parameters with interdependencies), the description is minimal but sufficient combined with schema descriptions and output schema. It could mention pagination, but the limit parameter covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All seven parameters have full schema descriptions (100% coverage), so the description adds no new parameter semantics. It summarizes the two modes but does not elaborate on parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves PagerDuty escalation policies with two modes: listing by filters or fetching details by ID. This distinguishes it from sibling tools focused on incidents, oncalls, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description implies usage for retrieving escalation policies, it does not explicitly state when to prefer this over other tools or provide exclusion criteria. However, the sibling tools are on different resources, so context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_incidentsB

Get PagerDuty incidents by filters or get details for a specific incident ID or number.

ParametersJSON Schema

Name	Required	Description
`incident_id`	No	The incident ID or number to retrieve (optional, cannot be used with any other filters).
`current_user_context`	No	Filter by current user's context (default: True). Not used if `incident_id` is provided.
`service_ids`	No	Filter by services (optional, excludes current_user_context). Not used if `incident_id` is provided.
`team_ids`	No	Filter by teams (optional, excludes current_user_context). Not used if `incident_id` is provided.
`statuses`	No	Filter by status (optional). Not used if `incident_id` is provided. Must be input as a list of strings, valid values are `["triggered", "acknowledged", "resolved"]`. Defaults to all statuses.
`urgencies`	No	Filter by urgency (optional). Not used if `incident_id` is provided. Must be input as a list of strings, valid values are `["high", "low"]`. Defaults to all urgencies. Account must have the urgencies ability to do this.
`since`	No	Start of query range in ISO8601 format (default range: 1 month, max range: 6 months). Not used if `incident_id` is provided.
`until`	No	End of query range in ISO8601 format (default range: 1 month, max range: 6 months). Not used if `incident_id` is provided.
`limit`	No	Max results (optional). Not used if `incident_id` is provided.
`include_past_incidents`	No	If True and `incident_id` is provided, includes similar past incidents in the response. Defaults to False. Cannot be used without `incident_id`.
`include_related_incidents`	No	If True and `incident_id` is provided, includes related incidents impacting other services/responders in the response. Defaults to False. Cannot be used without `incident_id`.
`include_notes`	No	If True, includes notes for each incident in the response. Defaults to False.
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each incident

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only states the function. It does not mention pagination, error handling, rate limits, or authentication requirements. Some behavior is implied by the input schema (e.g., mutual exclusivity of incident_id and filters), but the description itself is silent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence of 18 words, appropriately front-loaded with the verb and resource. It is concise, though it could benefit from slightly more detail to improve clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema being present, the description fails to explain the tool's two usage modes (list vs. specific ID) clearly. With 13 parameters, more context about how parameters interact (e.g., mutual exclusivity) would be helpful. The description is too vague for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds little beyond saying 'filters' which the schema already details. It does not provide additional meaning or context for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves PagerDuty incidents, with two distinct modes: filtering by attributes or retrieving a specific incident by ID/number. This distinguishes it from sibling tools that perform actions on incidents (e.g., acknowledge_incident, resolve_incident).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention when to avoid using it or reference sibling tools, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_oncallsA

List on-call entries for schedules, policies, or time ranges.

Behavior varies by time parameters:

Without since/until: Returns current on-calls Example: get_oncalls(schedule_ids=["SCHEDULE_123"])
With since/until: Returns all on-calls in range Example: get_oncalls(schedule_ids=["SCHEDULE_123"], since="2024-03-20T00:00:00Z", until="2024-03-27T00:00:00Z")

ParametersJSON Schema

Name	Required	Description
`current_user_context`	No	Use current user's team policies (default: True)
`schedule_ids`	No	Filter by schedules (optional)
`user_ids`	No	Filter by users (optional, excludes current_user_context)
`escalation_policy_ids`	No	Filter by policies (optional)
`since`	No	Start of query range in ISO8601 format (default: current datetime)
`until`	No	End of query range in ISO8601 format (default: current datetime, max range: 90 days in the future). Cannot be before `since`.
`limit`	No	Max results (optional)
`earliest`	No	Only earliest on-call per policy/level/user combo (optional)
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each on-call entry

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explains behavior variation with time parameters, includes examples, and mentions constraints like the 90-day max range for 'until'. No annotations provided, so description carries full burden and does so well, though permission requirements are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two paragraphs with clear first sentence and bulleted examples. Efficient but could be slightly more concise; still earns its sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complex tool with 9 parameters. Covers main behavior variation well. The 'include' parameter is only briefly mentioned, and return values are not described (though output schema exists). Overall fairly complete for a read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions. The description adds value by explaining the behavioral difference of 'since' and 'until' and providing usage examples, which clarifies parameter semantics beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List on-call entries for schedules, policies, or time ranges' and distinguishes two modes based on time parameters. This specificity helps differentiate it from sibling tools like list_users_oncall.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use without vs. with time parameters, including examples. However, it does not explicitly contrast with sibling tools or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schedulesB

Get PagerDuty schedules by filters or get details for a specific schedule ID.

ParametersJSON Schema

Name	Required	Description
`schedule_id`	No	The schedule ID to retrieve details for (optional, cannot be used with query or limit).
`query`	No	Filter schedules whose names contain the search query (optional). Not used if `schedule_id` is provided.
`limit`	No	Limit the number of results returned (optional). Not used if `schedule_id` is provided.
`since`	No	Start time for overrides/final schedule details (ISO8601, optional). Only used if `schedule_id` is provided. Defaults to 2 weeks before 'until' if 'until' is given.
`until`	No	End time for overrides/final schedule details (ISO8601, optional). Only used if `schedule_id` is provided. Defaults to 2 weeks after 'since' if 'since' is given.
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each schedule

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses no behavioral traits (e.g., pagination, rate limits, authentication). Only states basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with purpose, no wasted words. Efficiently communicates the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, 0 required, and an output schema, the description is adequate but lacks elaboration on use cases for optional parameters or response details. Not misleading but could be improved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds minimal new meaning. It restates the filter vs. ID distinction which is already captured in parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (get), resource (schedules), and two distinct modes (filter vs. specific ID). It distinguishes from sibling tools, none of which target schedules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use filters vs. schedule ID, or when to prefer this tool over alternatives. The description implies two use cases but does not provide decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_servicesA

Get PagerDuty services by filters or get details for a specific service ID.

ParametersJSON Schema

Name	Required	Description
`service_id`	No	The service ID to retrieve (optional, cannot be used with any other filters).
`current_user_context`	No	Use current user's team IDs to filter (default: True). Not used if `service_id` is provided.
`team_ids`	No	Filter results to only services assigned to teams with the given IDs (optional, cannot be used with current_user_context). Not used if `service_id` is provided.
`query`	No	Filter services whose names contain the search query (optional). Not used if `service_id` is provided.
`limit`	No	Limit the number of results (optional). Not used if `service_id` is provided.
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each service

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only indicates a 'get' operation (read) but does not disclose any behavioral traits such as pagination behavior, default limits, rate limits, or effects on data. No annotations are provided, so the description carries the full burden. The presence of a 'limit' parameter implies pagination, but this is not mentioned in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that covers both usage modes. It is front-loaded with the main action and resource, and every word serves a purpose. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (not shown but present) and 100% schema parameter coverage, the description is minimally adequate. However, it lacks guidance on typical use cases, response format hints, or behavior when no filters are applied. For a simple read tool, it is acceptable but could be more informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema (e.g., it does not explain filter interactions or provide examples). Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves PagerDuty services either by filters or by a specific service ID. The verb 'Get' and resource 'services' are explicit, and the two modes are distinct. Sibling tools like get_incidents or get_teams target different resources, so purpose differentiation is natural.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. However, the resource name itself implies usage for services, and siblings are for other resources. No when-not-to-use or exclusion criteria are stated, which is a gap for a tool with multiple filter modes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_teamsA

Get PagerDuty teams by filters or get details for a specific team ID.

ParametersJSON Schema

Name	Required	Description
`team_id`	No	The team ID to retrieve (optional, cannot be used with any other filters).
`query`	No	Filter teams whose names contain the search query (optional). Not used if `team_id` is provided.
`limit`	No	Limit the number of results returned (optional). Not used if `team_id` is provided.
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each team

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation but does not explicitly confirm safety, rate limits, or pagination. The presence of an output schema partially covers return format, but the description adds minimal behavioral context beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that conveys the essential purpose. It is concise and front-loaded, though it could be slightly more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the schema covers all parameters and an output schema exists, the description is adequate for a simple read tool. However, it lacks explicit mention of its safe read-only nature and default behavior when no parameters are provided, leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter having a clear description. The tool description adds no further meaning beyond the schema, meeting the baseline expectation for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves PagerDuty teams, either by filters or by specific team ID. The verb 'Get' and resource 'teams' are specific, and the two usage modes are explicitly mentioned, distinguishing it from sibling tools focusing on other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use filters versus a specific team ID, providing clear context for usage. However, it does not explicitly state when not to use the tool or mention alternatives, which would improve the score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_usersB

Get PagerDuty users by filters or get details for a specific user ID.

ParametersJSON Schema

Name	Required	Description
`user_id`	No	The user ID to retrieve (optional, cannot be used with any other filters).
`current_user_context`	No	Use current user's team IDs to filter (default: True). Not used if `user_id` is provided.
`team_ids`	No	Filter results to only users assigned to teams with the given IDs (optional, cannot be used with current_user_context). Not used if `user_id` is provided.
`query`	No	Filter users whose names contain the search query (optional). Not used if `user_id` is provided.
`limit`	No	Limit the number of results (optional). Not used if `user_id` is provided.
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each user

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only states the basic operation. It does not mention rate limits, pagination, authentication, or default behavior (e.g., what happens without filters).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and efficiently summarizes the tool's purpose with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite rich schema and output schema, the description is minimal. It does not explain default behavior (e.g., returning all users when no filters), pagination, or response details, leaving gaps for a new user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it just says 'by filters'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets PagerDuty users either by filters or by a specific user ID, using a specific verb and resource. It distinguishes between two modes, which helps differentiate from siblings like list_users_oncall.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., list_users_oncall). It lacks explicit context for selection among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_users_oncallC

List the users on call for a schedule during the specified time range.

ParametersJSON Schema

Name	Required	Description
`schedule_id`	Yes	The ID of the schedule to query
`since`	No	Start of query range in ISO8601 format
`until`	No	End of query range in ISO8601 format
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for each user on call

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action but omits details about side effects, safety (e.g., read-only nature), or behaviors when parameters are omitted (e.g., default range when since/until are null).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loading the main action and resource. It is concise without being terse, though it could optionally add more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema exists, the description does not clarify behavior for missing time range parameters or mention pagination/limits. The tool seems simple, but important contextual details are absent for an agent to confidently invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all four parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema, so it meets the baseline expectation for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'users on call for a schedule during time range'. It is specific and unambiguous. However, it does not differentiate from the sibling tool 'get_oncalls', which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'get_oncalls'. There is no mention of prerequisites, limitations, or cases where this tool is inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_incidentA

Resolve a PagerDuty incident. This marks the incident as resolved and stops any further escalations.

ParametersJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The ID of the incident to resolve (required).
`include`	No	List of fields to include in the response. If specified, only these fields will be returned for the incident.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only mentions marking as resolved and stopping escalations, but lacks detail on idempotency, reversibility, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with two clauses, no redundant information, and directly conveys the function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the action and effect, but lacks behavioral transparency and usage guidance. Given the simple nature and presence of output schema, it is minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it resolves a PagerDuty incident and explains the effect (stops escalations). This differentiates it from siblings like acknowledge_incident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for resolving incidents but does not explicitly state when to use versus alternatives, nor does it mention prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools target distinct resources with clear actions. Slight overlap between get_oncalls and list_users_oncall, but descriptions clarify different use cases. Overall well-disambiguated.

Naming Consistency5/5

All tools use consistent snake_case with a verb_noun pattern (e.g., acknowledge_incident, get_services). No mixing of styles, making it predictable for an agent.

Tool Count5/5

12 tools covering incident actions, resource retrieval, and user context building is well-scoped for a PagerDuty incident response server. Neither too sparse nor unnecessarily large.

Completeness4/5

Incident lifecycle includes acknowledge, note, get, resolve, but missing create_incident or update_incident. Resource operations are read-only. For incident response context, surface is reasonably complete.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13

Related MCP Servers

Model Context Protocol (MCP)
Developer Tools Code Execution Autonomous Agents
hideya
A
license
B
quality
C
maintenance
This server facilitates the invocation of AI models from providers like Anthropic, OpenAI, and Groq, enabling users to manage and configure large language model interactions seamlessly.
Updated 12 days ago (2026-08-23 00:06 UTC)
2
13
MIT
Logseq MCP Server
Knowledge & Memory Note Taking
dailydaniel
A
license
B
quality
C
maintenance
A server that enables LLMs to programmatically interact with Logseq knowledge graphs, allowing creation and management of pages and blocks.
Updated 2 months ago (2026-07-08 20:28 UTC)
10
41
MIT
OpenAPI MCP Server
API Testing Developer Tools
ivo-toby
A
license
Not graded
quality
A
maintenance
A server that enables Large Language Models to discover and interact with REST APIs defined by OpenAPI specifications through the Model Context Protocol.
Updated 3 months ago (2026-06-15 14:57 UTC)
3,501
289
MIT
OpenAPI MCP Server
API Testing App Automation Developer Tools
rahgadda
A
license
Not graded
quality
D
maintenance
A Model Context Protocol Server that enables LLMs to interact with and execute REST API calls through natural language prompts, supporting GET/PUT/POST/PATCH operations on configured APIs.
Updated a year ago (2025-04-24 17:37 UTC)
6
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wpfleger96/pagerduty-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

PagerDuty MCP Server

Overview

Getting Started

Authentication

Option 1: X-PagerDuty-Token Header (Platform Integration)

Option 2: API Token (Recommended for Most Users)

Option 3: OAuth 2.0 PKCE (Local Interactive Use)

Usage

Claude/Cursor

As Standalone Server

Available Tools

Read Tools

Write Tools

The include Parameter

Response Format

Error Handling

Parameter Validation

Rate Limiting and Pagination

User Context

Development

Running Tests

Debug Server with MCP Inspector

Documentation

Conventions

Example Queries

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

The `include` Parameter