Skip to main content
Glama
Sign In
enesjakozh
wpfleger96

PagerDuty MCP Server

by wpfleger96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

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.

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

  1. Initialize your local Python environment:

cd pagerduty-mcp-server
brew install uv
uv sync

  1. Configure authentication (see Authentication below).

Authentication

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

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

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:

  1. Register a PagerDuty OAuth application at Integrations → Developer Tools → My Apps.

  2. Set the required scope to read write.

  3. Set the redirect URI to http://localhost:5173/oauth/pagerduty (default port).

  4. 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 values (single-ID parameters and list filters such as team_ids) must contain only ASCII letters and digits; any other value returns an error

  • Date parameters must be valid ISO8601 timestamps

  • List parameters (e.g., statuses, team_ids) must contain valid values

  • In ID list filters, surrounding whitespace is stripped and blank IDs are 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 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:

    • user_ids and team_ids cannot be used with current_user_context=True

  • For users:

    • team_ids cannot be used with current_user_context=True

  • For on-calls:

    • user_ids and escalation_policy_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 the escalation policies the current user is a target of

    • If the current user is not a target of any escalation policy and no schedule_ids are given, the tool returns an error; use current_user_context=False with explicit filters instead

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.

NameRequiredDescriptionDefault
includeNoList of fields to include in the response. If specified, only these fields will be returned for the incident.
incident_idYesThe ID of the incident to acknowledge (required).

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
contentYesThe text content of the note (required).
incident_idYesThe ID of the incident to add a note to (required).

Output Schema

NameRequiredDescription

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

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
limitNoLimit the number of results (optional). Not used if `policy_id` is provided.
queryNoPolicies whose names contain the search query (optional). Not used if `policy_id` is provided.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each escalation policy
team_idsNoPolicies assigned to these team IDs (optional, excludes current_user_context). Not used if `policy_id` is provided.
user_idsNoPolicies that include these user IDs (optional, excludes current_user_context). Not used if `policy_id` is provided.
policy_idNoThe escalation policy ID to retrieve (optional, cannot be used with any other filters).
current_user_contextNoUse current user's ID/team IDs context (default: True). Not used if `policy_id` is provided.

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
limitNoMax results (optional). Not used if `incident_id` is provided.
sinceNoStart of query range in ISO8601 format (default range: 1 month, max range: 6 months). Not used if `incident_id` is provided.
untilNoEnd of query range in ISO8601 format (default range: 1 month, max range: 6 months). Not used if `incident_id` is provided.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each incident
statusesNoFilter 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.
team_idsNoFilter by teams (optional, excludes current_user_context). Not used if `incident_id` is provided.
urgenciesNoFilter 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.
incident_idNoThe incident ID or number to retrieve (optional, cannot be used with any other filters).
service_idsNoFilter by services (optional, excludes current_user_context). Not used if `incident_id` is provided.
include_notesNoIf True, includes notes for each incident in the response. Defaults to False.
current_user_contextNoFilter by current user's context (default: True); errors if the current user belongs to no teams. Not used if `incident_id` is provided.
include_past_incidentsNoIf True and `incident_id` is provided, includes similar past incidents in the response. Defaults to False. Cannot be used without `incident_id`.
include_related_incidentsNoIf 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`.

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and one sentence cannot cover it. It does not state that the operation is read-only, does not mention default query windows, result caps, or pagination, and does not note account-level requirements (the 'urgencies ability' constraint lives only in the schema). For a 13-parameter PagerDuty query tool, this is a substantial gap.

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?

A single tight sentence with the resource front-loaded and zero filler. The 'or' construction is slightly loose but communicates the two modes efficiently; nothing is wasted, though the brevity comes at the cost of the undisclosed behavior noted elsewhere.

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?

An output schema exists, so return shape and the include/include_notes behavior need not be explained. However, with 13 parameters, no annotations, and a genuine mode switch that disables ten of those parameters, the description leaves real gaps around default time windows and the mutual exclusivity contract. Adequate as a pointer, thin for a tool of this complexity.

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 every parameter including mutual-exclusion rules, ISO8601 formats, value enums, and the 1-month default / 6-month maximum window is already documented in the schema. The description adds no parameter meaning beyond repeating the filters/detail split already encoded in incident_id's description. Baseline 3 applies.

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?

States a specific verb and resource ('Get PagerDuty incidents') and names the two operating modes: filtered list versus single-incident detail by ID or number. No sibling tool covers the same resource, so the agent can orient itself without ambiguity. It stops short of explicitly differentiating itself from adjacent tools like add_incident_note or 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 dual-mode framing ('by filters or ... a specific incident ID') implies two usage paths, but the description never says when each is appropriate or that they are mutually exclusive. It also offers no exclusion guidance relative to siblings. The agent must open the schema to learn that incident_id cannot be combined with filters.

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:

  1. Without since/until: Returns current on-calls Example: get_oncalls(current_user_context=False, schedule_ids=["PSCHED123"])

  2. With since/until: Returns all on-calls in range Example: get_oncalls(current_user_context=False, schedule_ids=["PSCHED123"], since="2024-03-20T00:00:00Z", until="2024-03-27T00:00:00Z")

NameRequiredDescriptionDefault
limitNoMax results (optional)
sinceNoStart of query range in ISO8601 format (default: current datetime)
untilNoEnd of query range in ISO8601 format (default: current datetime, max range: 90 days in the future). Cannot be before `since`.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each on-call entry
earliestNoOnly earliest on-call per policy/level/user combo (optional)
user_idsNoFilter by users (optional, excludes current_user_context)
schedule_idsNoFilter by schedules (optional)
current_user_contextNoUse escalation policies the current user is a target of (default: True); errors if the current user is a target of no escalation policy and no schedule_ids are given.
escalation_policy_idsNoFilter by policies (optional, excludes current_user_context)

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It discloses the important time-parameter branching and provides examples, but it does not mention permission requirements, rate limits, or other operational constraints.

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 front-loaded with the core purpose and then uses a compact numbered list to explain the two behavioral modes. The examples are directly tied to the branches and do not add unnecessary prose.

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 presence of a full input schema, an output schema, and 100% parameter description coverage, the description is largely complete. It covers the key behavioral variation by time range, though it leaves filter-specific semantics to the schema.

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 already 100%, but the description adds meaning beyond the schema by explaining that omitting since/until changes the result from a range query to current on-calls. The examples also demonstrate relevant parameter combinations.

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 states a specific verb and resource: "List on-call entries" for schedules, policies, or time ranges. It is clear what the tool returns, but it does not explicitly differentiate itself from the sibling list_users_oncall tool.

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?

It gives clear conditional usage: without since/until it returns current on-calls, and with since/until it returns all on-calls in the range. It does not name sibling alternatives or state when not to use this tool, so it stops short of full alternative guidance.

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.

NameRequiredDescriptionDefault
limitNoLimit the number of results returned (optional). Not used if `schedule_id` is provided.
queryNoFilter schedules whose names contain the search query (optional). Not used if `schedule_id` is provided.
sinceNoStart 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.
untilNoEnd 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.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each schedule
schedule_idNoThe schedule ID to retrieve details for (optional, cannot be used with query or limit).

Output Schema

NameRequiredDescription

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_servicesB

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

NameRequiredDescriptionDefault
limitNoLimit the number of results (optional). Not used if `service_id` is provided.
queryNoFilter services whose names contain the search query (optional). Not used if `service_id` is provided.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each service
team_idsNoFilter 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.
service_idNoThe service ID to retrieve (optional, cannot be used with any other filters).
current_user_contextNoUse current user's team IDs to filter (default: True); errors if the current user belongs to no teams. Not used if `service_id` is provided.

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It conveys only that this is a read/get operation and does not mention default filtering via current_user_context, permissions, pagination, rate limits, or error behavior.

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 front-loaded sentence with no wasted words. It efficiently states both possible modes without unnecessary elaboration.

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?

An output schema exists and parameter schema coverage is full, so the description need not explain return values or every parameter. Still, for a tool with six optional filters and a default current_user_context behavior, the description omits important operational context that no annotations supply.

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 schema already documents all six parameters in detail. The description only alludes to filters and service ID generically, adding little beyond what the schema provides, which makes the baseline 3 appropriate.

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 states a clear verb and resource: get PagerDuty services, with two modes (filtered list or specific service ID). It does not explicitly differentiate itself from sibling tools like get_incidents or get_teams, so it stops short of a 5.

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?

It implies two usage modes: filtered listing or detail lookup by service_id. However, it gives no explicit when-to-use guidance, exclusions, or alternatives relative to sibling tools, leaving selection mostly to inference.

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.

NameRequiredDescriptionDefault
limitNoLimit the number of results returned (optional). Not used if `team_id` is provided.
queryNoFilter teams whose names contain the search query (optional). Not used if `team_id` is provided.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each team
team_idNoThe team ID to retrieve (optional, cannot be used with any other filters).

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
limitNoLimit the number of results (optional). Not used if `user_id` is provided.
queryNoFilter users whose names contain the search query (optional). Not used if `user_id` is provided.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each user
user_idNoThe user ID to retrieve (optional, cannot be used with any other filters).
team_idsNoFilter 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.
current_user_contextNoUse current user's team IDs to filter (default: True); errors if the current user belongs to no teams. Not used if `user_id` is provided.

Output Schema

NameRequiredDescription

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 carries the full burden and discloses nothing behavioral: no mention of pagination, auth/permission requirements, or the significant default that current_user_context=true silently narrows results to the caller's teams and errors if the user has none. That side effect is only visible by reading the schema.

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?

A single front-loaded sentence that wastes no words and puts the primary verb first. It is arguably too terse given the two-mode behavior, but nothing in it is 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?

An output schema exists and all six parameters are documented in the schema, so basic completeness is met. Still missing is any explanation of how the two modes interact and the team-scoped default behavior, which matters for a tool with six optional parameters and no annotations.

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 every parameter including limit, query, include, team_ids and the current_user_context default is already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Get PagerDuty users') and distinguishes its two operating modes: filtered list vs single-ID lookup. It does not, however, differentiate itself from sibling tools like list_users_oncall or build_user_context, which an agent must choose between.

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 dual-mode framing implies when each path applies (filter list vs user_id), but there is no explicit guidance on when to prefer this over list_users_oncall or build_user_context, nor on prerequisites such as needing team context.

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.

NameRequiredDescriptionDefault
sinceNoStart of query range in ISO8601 format
untilNoEnd of query range in ISO8601 format
includeNoList of fields to include in the response. If specified, only these fields will be returned for each user on call
schedule_idYesThe ID of the schedule to query

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
includeNoList of fields to include in the response. If specified, only these fields will be returned for the incident.
incident_idYesThe ID of the incident to resolve (required).

Output Schema

NameRequiredDescription

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv4.0.7
    • Changedget_incidents1 field changed
      • changedInput schema / properties / current_user_context / description
        Previous value: -"Filter by current user's context (default: True). Not used if `incident_id` is provided."New value: +"Filter by current user's context (default: True); errors if the current user belongs to no teams. Not used if `incident_id` is provided."
    • Changedget_oncalls2 fields changed
      • changedInput schema / properties / current_user_context / description
        Previous value: -"Use current user's team policies (default: True)"New value: +"Use escalation policies the current user is a target of (default: True); errors if the current user is a target of no escalation policy and no schedule_ids are given."
      • changedInput schema / properties / escalation_policy_ids / description
        Previous value: -"Filter by policies (optional)"New value: +"Filter by policies (optional, excludes current_user_context)"
    • Changedget_services1 field changed
      • changedInput schema / properties / current_user_context / description
        Previous value: -"Use current user's team IDs to filter (default: True). Not used if `service_id` is provided."New value: +"Use current user's team IDs to filter (default: True); errors if the current user belongs to no teams. Not used if `service_id` is provided."
    • Changedget_users1 field changed
      • changedInput schema / properties / current_user_context / description
        Previous value: -"Use current user's team IDs to filter (default: True). Not used if `user_id` is provided."New value: +"Use current user's team IDs to filter (default: True); errors if the current user belongs to no teams. Not used if `user_id` is provided."
  2. 11 tool updatesv4.0.1
    • Addedacknowledge_incident
    • Addedadd_incident_note
    • Changedget_escalation_policies1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each escalation policy"
+}
    • Changedget_incidents5 fields changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each incident"
+}
      • changedInput schema / properties / include_past_incidents / description
        Previous value: -"If True and `incident_id` is provided, includes similar past incidents\nin the response. Defaults to False. Cannot be used without `incident_id`."New value: +"If True and `incident_id` is provided, includes similar past incidents in the response. Defaults to False. Cannot be used without `incident_id`."
      • changedInput schema / properties / include_related_incidents / description
        Previous value: -"If True and `incident_id` is provided, includes related incidents\nimpacting other services/responders in the response. Defaults to False. Cannot be used without `incident_id`."New value: +"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`."
      • changedInput schema / properties / statuses / description
        Previous value: -"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\"]`."New value: +"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."
      • addedInput schema / properties / urgencies
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "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."
+}
    • Changedget_oncalls1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each on-call entry"
+}
    • Changedget_schedules1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each schedule"
+}
    • Changedget_services1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each service"
+}
    • Changedget_teams1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each team"
+}
    • Changedget_users1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each user"
+}
    • Changedlist_users_oncall1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include in the response. If specified, only these fields will be returned for each user on call"
+}
    • Addedresolve_incident
  3. 9 tool updatesv3.1.4
    • Changedbuild_user_context2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_escalation_policies14 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / current_user_context / description
        Added value: +"Use current user's ID/team IDs context (default: True). Not used if `policy_id` is provided."
      • removedInput schema / properties / current_user_context / title
        Removed value: -"Current User Context"
      • addedInput schema / properties / limit / description
        Added value: +"Limit the number of results (optional). Not used if `policy_id` is provided."
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / policy_id / description
        Added value: +"The escalation policy ID to retrieve (optional, cannot be used with any other filters)."
      • removedInput schema / properties / policy_id / title
        Removed value: -"Policy Id"
      • addedInput schema / properties / query / description
        Added value: +"Policies whose names contain the search query (optional). Not used if `policy_id` is provided."
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • addedInput schema / properties / team_ids / description
        Added value: +"Policies assigned to these team IDs (optional, excludes current_user_context). Not used if `policy_id` is provided."
      • removedInput schema / properties / team_ids / title
        Removed value: -"Team Ids"
      • addedInput schema / properties / user_ids / description
        Added value: +"Policies that include these user IDs (optional, excludes current_user_context). Not used if `policy_id` is provided."
      • removedInput schema / properties / user_ids / title
        Removed value: -"User Ids"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_incidents24 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / current_user_context / description
        Added value: +"Filter by current user's context (default: True). Not used if `incident_id` is provided."
      • removedInput schema / properties / current_user_context / title
        Removed value: -"Current User Context"
      • addedInput schema / properties / incident_id / description
        Added value: +"The incident ID or number to retrieve (optional, cannot be used with any other filters)."
      • removedInput schema / properties / incident_id / title
        Removed value: -"Incident Id"
      • addedInput schema / properties / include_notes / description
        Added value: +"If True, includes notes for each incident in the response. Defaults to False."
      • removedInput schema / properties / include_notes / title
        Removed value: -"Include Notes"
      • addedInput schema / properties / include_past_incidents / description
        Added value: +"If True and `incident_id` is provided, includes similar past incidents\nin the response. Defaults to False. Cannot be used without `incident_id`."
      • removedInput schema / properties / include_past_incidents / title
        Removed value: -"Include Past Incidents"
      • addedInput schema / properties / include_related_incidents / description
        Added value: +"If True and `incident_id` is provided, includes related incidents\nimpacting other services/responders in the response. Defaults to False. Cannot be used without `incident_id`."
      • removedInput schema / properties / include_related_incidents / title
        Removed value: -"Include Related Incidents"
      • addedInput schema / properties / limit / description
        Added value: +"Max results (optional). Not used if `incident_id` is provided."
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / service_ids / description
        Added value: +"Filter by services (optional, excludes current_user_context). Not used if `incident_id` is provided."
      • removedInput schema / properties / service_ids / title
        Removed value: -"Service Ids"
      • addedInput schema / properties / since / description
        Added value: +"Start of query range in ISO8601 format (default range: 1 month, max range: 6 months). Not used if `incident_id` is provided."
      • removedInput schema / properties / since / title
        Removed value: -"Since"
      • addedInput schema / properties / statuses / description
        Added value: +"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\"]`."
      • removedInput schema / properties / statuses / title
        Removed value: -"Statuses"
      • addedInput schema / properties / team_ids / description
        Added value: +"Filter by teams (optional, excludes current_user_context). Not used if `incident_id` is provided."
      • removedInput schema / properties / team_ids / title
        Removed value: -"Team Ids"
      • addedInput schema / properties / until / description
        Added value: +"End of query range in ISO8601 format (default range: 1 month, max range: 6 months). Not used if `incident_id` is provided."
      • removedInput schema / properties / until / title
        Removed value: -"Until"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_oncalls18 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / current_user_context / description
        Added value: +"Use current user's team policies (default: True)"
      • removedInput schema / properties / current_user_context / title
        Removed value: -"Current User Context"
      • addedInput schema / properties / earliest / description
        Added value: +"Only earliest on-call per policy/level/user combo (optional)"
      • removedInput schema / properties / earliest / title
        Removed value: -"Earliest"
      • addedInput schema / properties / escalation_policy_ids / description
        Added value: +"Filter by policies (optional)"
      • removedInput schema / properties / escalation_policy_ids / title
        Removed value: -"Escalation Policy Ids"
      • addedInput schema / properties / limit / description
        Added value: +"Max results (optional)"
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / schedule_ids / description
        Added value: +"Filter by schedules (optional)"
      • removedInput schema / properties / schedule_ids / title
        Removed value: -"Schedule Ids"
      • addedInput schema / properties / since / description
        Added value: +"Start of query range in ISO8601 format (default: current datetime)"
      • removedInput schema / properties / since / title
        Removed value: -"Since"
      • addedInput schema / properties / until / description
        Added value: +"End of query range in ISO8601 format (default: current datetime, max range: 90 days in the future). Cannot be before `since`."
      • removedInput schema / properties / until / title
        Removed value: -"Until"
      • addedInput schema / properties / user_ids / description
        Added value: +"Filter by users (optional, excludes current_user_context)"
      • removedInput schema / properties / user_ids / title
        Removed value: -"User Ids"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_schedules12 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / limit / description
        Added value: +"Limit the number of results returned (optional). Not used if `schedule_id` is provided."
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / query / description
        Added value: +"Filter schedules whose names contain the search query (optional). Not used if `schedule_id` is provided."
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • addedInput schema / properties / schedule_id / description
        Added value: +"The schedule ID to retrieve details for (optional, cannot be used with query or limit)."
      • removedInput schema / properties / schedule_id / title
        Removed value: -"Schedule Id"
      • addedInput schema / properties / since / description
        Added value: +"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."
      • removedInput schema / properties / since / title
        Removed value: -"Since"
      • addedInput schema / properties / until / description
        Added value: +"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."
      • removedInput schema / properties / until / title
        Removed value: -"Until"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_services12 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / current_user_context / description
        Added value: +"Use current user's team IDs to filter (default: True). Not used if `service_id` is provided."
      • removedInput schema / properties / current_user_context / title
        Removed value: -"Current User Context"
      • addedInput schema / properties / limit / description
        Added value: +"Limit the number of results (optional). Not used if `service_id` is provided."
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / query / description
        Added value: +"Filter services whose names contain the search query (optional). Not used if `service_id` is provided."
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • addedInput schema / properties / service_id / description
        Added value: +"The service ID to retrieve (optional, cannot be used with any other filters)."
      • removedInput schema / properties / service_id / title
        Removed value: -"Service Id"
      • addedInput schema / properties / team_ids / description
        Added value: +"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."
      • removedInput schema / properties / team_ids / title
        Removed value: -"Team Ids"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_teams8 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / limit / description
        Added value: +"Limit the number of results returned (optional). Not used if `team_id` is provided."
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / query / description
        Added value: +"Filter teams whose names contain the search query (optional). Not used if `team_id` is provided."
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • addedInput schema / properties / team_id / description
        Added value: +"The team ID to retrieve (optional, cannot be used with any other filters)."
      • removedInput schema / properties / team_id / title
        Removed value: -"Team Id"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_users12 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / current_user_context / description
        Added value: +"Use current user's team IDs to filter (default: True). Not used if `user_id` is provided."
      • removedInput schema / properties / current_user_context / title
        Removed value: -"Current User Context"
      • addedInput schema / properties / limit / description
        Added value: +"Limit the number of results (optional). Not used if `user_id` is provided."
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • addedInput schema / properties / query / description
        Added value: +"Filter users whose names contain the search query (optional). Not used if `user_id` is provided."
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • addedInput schema / properties / team_ids / description
        Added value: +"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."
      • removedInput schema / properties / team_ids / title
        Removed value: -"Team Ids"
      • addedInput schema / properties / user_id / description
        Added value: +"The user ID to retrieve (optional, cannot be used with any other filters)."
      • removedInput schema / properties / user_id / title
        Removed value: -"User Id"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedlist_users_oncall8 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / schedule_id / description
        Added value: +"The ID of the schedule to query"
      • removedInput schema / properties / schedule_id / title
        Removed value: -"Schedule Id"
      • addedInput schema / properties / since / description
        Added value: +"Start of query range in ISO8601 format"
      • removedInput schema / properties / since / title
        Removed value: -"Since"
      • addedInput schema / properties / until / description
        Added value: +"End of query range in ISO8601 format"
      • removedInput schema / properties / until / title
        Removed value: -"Until"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  4. 9 tool updatesv1.0.0
    • First observedbuild_user_context
    • First observedget_escalation_policies
    • First observedget_incidents
    • First observedget_oncalls
    • First observedget_schedules
    • First observedget_services
    • First observedget_teams
    • First observedget_users
    • First observedlist_users_oncall
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.5/5.0

Scored across 12 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness3/5

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.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • OpenAPI MCP Server

    ivo-toby
    A
    license
    Not graded
    quality
    C
    maintenance
    A server that enables Large Language Models to discover and interact with REST APIs defined by OpenAPI specifications through the Model Context Protocol.
    8,715 npm
    301
    MIT

  • OpenAPI MCP Server

    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.
    48 PyPI
    6
    Apache 2.0