Skip to main content
Glama
enesjakozh
wpfleger96

PagerDuty MCP Server

by wpfleger96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

PagerDuty MCP 서버

LLM에 PagerDuty API 기능을 제공하는 서버입니다. 이 서버는 구조화된 입력 및 출력을 통해 프로그래밍 방식으로 사용하도록 설계되었습니다.

PyPI 다운로드 파이썬 버전 GitHub 기여자 PyPI 버전 특허

개요

PagerDuty MCP 서버는 PagerDuty API와 상호 작용하기 위한 도구 세트를 제공합니다. 이러한 도구는 LLM이 인시던트, 서비스, 팀, 사용자 등 PagerDuty 리소스에 대한 다양한 작업을 수행하는 데 사용하도록 설계되었습니다.

Related MCP server: Logseq MCP Server

설치

PyPI에서

지엑스피1

출처에서

# 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

기여

출시

이 프로젝트에서는 자동 릴리스를 위해 Conventional Commit을 사용합니다. 커밋 메시지에 따라 버전 상향 조정이 결정됩니다.

  • 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
NameRequiredDescriptionDefault
incident_idYesThe ID of the incident to acknowledge (required).
includeNoList of fields to include in the response. If specified, only these fields will be returned for the incident.

Output Schema

ParametersJSON 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.

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

Output Schema

ParametersJSON 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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
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.
queryNoPolicies whose names contain the search query (optional). 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.
team_idsNoPolicies assigned to these team IDs (optional, excludes current_user_context). Not used if `policy_id` is provided.
limitNoLimit the number of results (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

Output Schema

ParametersJSON 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
incident_idNoThe incident ID or number to retrieve (optional, cannot be used with any other filters).
current_user_contextNoFilter by current user's context (default: True). Not used if `incident_id` is provided.
service_idsNoFilter by services (optional, excludes current_user_context). Not used if `incident_id` is provided.
team_idsNoFilter by teams (optional, excludes current_user_context). Not used if `incident_id` is provided.
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.
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.
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.
limitNoMax results (optional). 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`.
include_notesNoIf True, includes notes for each incident in the response. Defaults to False.
includeNoList of fields to include in the response. If specified, only these fields will be returned for each incident

Output Schema

ParametersJSON Schema
NameRequiredDescription

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:

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

  2. 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
NameRequiredDescriptionDefault
current_user_contextNoUse current user's team policies (default: True)
schedule_idsNoFilter by schedules (optional)
user_idsNoFilter by users (optional, excludes current_user_context)
escalation_policy_idsNoFilter by policies (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`.
limitNoMax results (optional)
earliestNoOnly earliest on-call per policy/level/user combo (optional)
includeNoList of fields to include in the response. If specified, only these fields will be returned for each on-call entry

Output Schema

ParametersJSON Schema
NameRequiredDescription

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
NameRequiredDescriptionDefault
schedule_idNoThe schedule ID to retrieve details for (optional, cannot be used with query or limit).
queryNoFilter schedules whose names contain the search query (optional). Not used if `schedule_id` is provided.
limitNoLimit the number of results returned (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

Output Schema

ParametersJSON 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_servicesA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
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). Not used if `service_id` is provided.
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.
queryNoFilter services whose names contain the search query (optional). Not used if `service_id` is provided.
limitNoLimit the number of results (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

Output Schema

ParametersJSON 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?

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
NameRequiredDescriptionDefault
team_idNoThe team ID to retrieve (optional, cannot be used with any other filters).
queryNoFilter teams whose names contain the search query (optional). Not used if `team_id` is provided.
limitNoLimit the number of results returned (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

Output Schema

ParametersJSON 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
user_idNoThe user ID to retrieve (optional, cannot be used with any other filters).
current_user_contextNoUse current user's team IDs to filter (default: True). Not used if `user_id` is provided.
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.
queryNoFilter users whose names contain the search query (optional). Not used if `user_id` is provided.
limitNoLimit the number of results (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

Output Schema

ParametersJSON 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 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
NameRequiredDescriptionDefault
schedule_idYesThe ID of the schedule to query
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

Output Schema

ParametersJSON 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.

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

Output Schema

ParametersJSON 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. 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
  2. 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"
+}
  3. 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
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 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

Related MCP Connectors

Related MCP Servers

  • OpenAPI MCP Server

    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.
    5,976 npm
    297
    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.
    321 PyPI
    6
    Apache 2.0