en es ja ko zh

PagerDuty MCP Server

Name: PagerDuty MCP Server
Author: wpfleger96

by wpfleger96

Overview Schema Source Related Servers Discussions Admin

Python

Remote

向 LLM 公开 PagerDuty API 功能的服务器。该服务器旨在以编程方式使用，并具有结构化的输入和输出。

PyPI 下载 Python 版本 GitHub 贡献者 PyPI 版本

概述

PagerDuty MCP 服务器提供了一组用于与 PagerDuty API 交互的工具。这些工具旨在供 LLM 使用，用于对 PagerDuty 资源（例如事件、服务、团队和用户）执行各种操作。

Related MCP server: Logseq MCP Server

安装

来自 PyPI

pip install pagerduty-mcp-server

来自源

# Clone the repository
git clone https://github.com/wpfleger96/pagerduty-mcp-server.git
cd pagerduty-mcp-server

# Install dependencies
brew install uv
uv sync

要求

Python 3.13 或更高版本
PagerDuty API 密钥

配置

PagerDuty MCP 服务器需要在环境中设置 PagerDuty API 密钥：

PAGERDUTY_API_KEY=your_api_key_here

用法

作为鹅扩展

{
  "type": "stdio",
  "enabled": true,
  "args": [
    "run",
    "python",
    "-m",
    "pagerduty_mcp_server"
  ],
  "commandInput": "uv run python -m pagerduty_mcp_server",
  "timeout": 300,
  "id": "pagerduty-mcp-server",
  "name": "pagerduty-mcp-server",
  "description": "pagerduty-mcp-server",
  "env_keys": [
    "PAGERDUTY_API_KEY"
  ],
  "cmd": "uv"
}

作为独立服务器

uv run python -m pagerduty_mcp_server

响应格式

所有 API 响应都遵循一致的格式：

{
  "metadata": {
    "count": <int>,  // Number of results
    "description": "<str>"  // A short summary of the results
  },
  <resource_type>: [ // Always pluralized for consistency, even if one result is returned
    {
      ...
    },
    ...
  ],
  "error": {  // Only present if there's an error
    "message": "<str>",  // Human-readable error description
    "code": "<str>"  // Machine-readable error code
  }
}

错误处理

当发生错误时，响应将包含具有以下结构的错误对象：

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

常见的错误场景包括：

无效的资源 ID（例如，user_id、team_id、service_id）
缺少必需参数
参数值无效
API 请求失败
响应处理错误

参数验证

所有 ID 参数必须是有效的 PagerDuty 资源 ID
日期参数必须是有效的 ISO8601 时间戳
列表参数（例如， statuses 、 team_ids ）必须包含有效值
列表参数中的无效值将被忽略
必需参数不能为None或空字符串
对于list_incidents中的statuses ，只有triggered 、 acknowledged和resolved是有效值
对于事件的urgency ，只有high和low是有效值
limit参数可用于限制列表操作返回的结果数

速率限制和分页

服务器遵守 PagerDuty 的速率限制
服务器自动为您处理分页
limit参数可用于控制列表操作返回的结果数量
如果没有指定限制，服务器默认返回最多 {pagerduty_mcp_server.utils.RESPONSE_LIMIT} 个结果

示例用法

from pagerduty_mcp_server import incidents
from pagerduty_mcp_server.utils import RESPONSE_LIMIT

# List all incidents (including resolved) for the current user's teams
incidents_list = incidents.list_incidents()

# List only active incidents
active_incidents = incidents.list_incidents(statuses=['triggered', 'acknowledged'])

# List incidents for specific services
service_incidents = incidents.list_incidents(service_ids=['SERVICE-1', 'SERVICE-2'])

# List incidents for specific teams
team_incidents = incidents.list_incidents(team_ids=['TEAM-1', 'TEAM-2'])

# List incidents within a date range
date_range_incidents = incidents.list_incidents(
    since='2024-03-01T00:00:00Z',
    until='2024-03-14T23:59:59Z'
)

# List incidents with a limit on the number of results
limited_incidents = incidents.list_incidents(limit=10)

# List incidents with the default limit
default_limit_incidents = incidents.list_incidents(limit=RESPONSE_LIMIT)

用户上下文

许多函数接受current_user_context参数（默认为True ），该参数会根据此上下文自动过滤结果。当current_user_context为True时，您无法使用某些过滤参数，因为它们会与自动过滤功能冲突：

对于所有资源类型：
- user_ids不能与current_user_context=True一起使用
对于事件：
- team_ids和service_ids不能与current_user_context=True一起使用
对于服务：
- team_ids不能与current_user_context=True一起使用
对于升级策略：
- team_ids不能与current_user_context=True一起使用
对于值班人员：
- user_ids不能与current_user_context=True一起使用
- 仍可使用schedule_ids按特定时间表进行筛选
- 该查询将显示与当前用户团队相关的所有升级策略的待命情况
- 这对于回答诸如“我的团队目前谁值班？”之类的问题很有用。
- 当前用户的 ID 不用作过滤器，因此您将看到所有值班的团队成员

发展

运行测试

请注意，大多数测试都需要与 PagerDuty API 建立实际连接，因此您需要在运行完整测试套件之前在环境中设置PAGERDUTY_API_KEY 。

uv run pytest

仅运行单元测试（即不需要在环境中设置PAGERDUTY_API_KEY测试）：

uv run pytest -m unit

仅运行集成测试：

uv run pytest -m integration

仅运行解析器测试：

uv run pytest -m parsers

仅运行与特定子模块相关的测试：

uv run pytest -m <client|escalation_policies|...>

使用 MCP Inspector 调试服务器

npx @modelcontextprotocol/inspector uv run python -m pagerduty_mcp_server

贡献

发布

该项目使用常规提交进行自动发布。提交消息决定了版本更新：

feat: → 次要版本（1.0.0 → 1.1.0）
fix: →补丁版本（1.0.0→1.0.1）
BREAKING CHANGE: → 主要版本（1.0.0 → 2.0.0）

CHANGELOG.md、GitHub 版本和 PyPI 包会自动更新。

文档

工具文档——有关可用工具的详细信息，包括参数、返回类型和示例查询

公约

所有 API 响应都遵循标准格式，包含元数据、资源列表和可选错误
为了保持一致性，响应中的资源名称始终采用复数形式
返回单个项目的所有函数仍返回包含一个元素的列表
错误响应包括消息和代码
所有时间戳均为 ISO8601 格式
测试用 pytest 标记来标记，以指示其类型（单元/集成）、测试的资源（事件、团队等）以及是否测试解析功能（“解析器”标记）

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.

Tool Schema Changelog

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

11 tool updatesv4.0.1May 12, 2026

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

9 tool updatesv3.1.4May 8, 2026

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"
+}
```

9 tool updatesv1.0.0Aug 18, 2025
- 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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-04 03:00 across 12 tools

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

Need Help?

Reddit Discussion

Related Servers

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 a month ago (2026-08-23 00:06 UTC)
2
51 PyPI
13
MIT
Logseq MCP Server
Knowledge & Memory Note Taking
dailydaniel
A
license
B
quality
B
maintenance
A server that enables LLMs to programmatically interact with Logseq knowledge graphs, allowing creation and management of pages and blocks.
Updated 10 days ago (2026-09-23 14:18 UTC)
10
41 PyPI
41
MIT
OpenAPI MCP Server
API Testing Developer Tools
ivo-toby
A
license
Not graded
quality
B
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 4 months ago (2026-06-15 14:57 UTC)
5,976 npm
297
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)
321 PyPI
6
Apache 2.0