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

Un servidor que expone la funcionalidad de la API de PagerDuty a los LLM. Este servidor está diseñado para usarse programáticamente, con entradas y salidas estructuradas.

Descargas de PyPI Versiones de Python Colaboradores de GitHub Versión de PyPI Licencia

Descripción general

El servidor MCP de PagerDuty proporciona un conjunto de herramientas para interactuar con la API de PagerDuty. Estas herramientas están diseñadas para que los LLM realicen diversas operaciones en recursos de PagerDuty, como incidentes, servicios, equipos y usuarios.

Related MCP server: Logseq MCP Server

Instalación

Desde PyPI

pip install pagerduty-mcp-server

De la fuente

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

# Install dependencies
brew install uv
uv sync

Requisitos

Python 3.13 o superior
Clave API de PagerDuty

Configuración

El servidor MCP de PagerDuty requiere que se configure una clave API de PagerDuty en el entorno:

PAGERDUTY_API_KEY=your_api_key_here

Uso

Como extensión de ganso

{
  "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"
}

Como servidor independiente

uv run python -m pagerduty_mcp_server

Formato de respuesta

Todas las respuestas de la API siguen un formato consistente:

{
  "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
  }
}

Manejo de errores

Cuando ocurre un error, la respuesta incluirá un objeto de error con la siguiente estructura:

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

Los escenarios de error más comunes incluyen:

ID de recursos no válidos (por ejemplo, user_id, team_id, service_id)
Faltan parámetros requeridos
Valores de parámetros no válidos
Errores en las solicitudes de API
Errores de procesamiento de respuesta

Validación de parámetros

Todos los parámetros de identificación deben ser identificaciones de recursos de PagerDuty válidas
Los parámetros de fecha deben ser marcas de tiempo ISO8601 válidas
Los parámetros de lista (por ejemplo, statuses , team_ids ) deben contener valores válidos
Los valores no válidos en los parámetros de lista serán ignorados
Los parámetros obligatorios no pueden ser None ni cadenas vacías
Para statuses en list_incidents , solo triggered , acknowledged y resolved son valores válidos
Para urgency en incidentes, solo valores high y low son válidos
El parámetro limit se puede utilizar para restringir la cantidad de resultados devueltos por las operaciones de lista

Limitación de velocidad y paginación

El servidor respeta los límites de velocidad de PagerDuty
El servidor gestiona automáticamente la paginación por usted
El parámetro limit se puede utilizar para controlar la cantidad de resultados devueltos por las operaciones de lista.
Si no se especifica ningún límite, el servidor devolverá hasta {pagerduty_mcp_server.utils.RESPONSE_LIMIT} resultados de forma predeterminada

Ejemplo de uso

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)

Contexto del usuario

Muchas funciones aceptan el parámetro current_user_context (valor predeterminado: True ), que filtra automáticamente los resultados según este contexto. Si current_user_context es True , no se pueden usar ciertos parámetros de filtro, ya que entrarían en conflicto con el filtrado automático:

Para todos los tipos de recursos:
- user_ids no se puede utilizar con current_user_context=True
Para incidentes:
- team_ids y service_ids no se pueden usar con current_user_context=True
Para servicios:
- team_ids no se puede utilizar con current_user_context=True
Para políticas de escalada:
- team_ids no se puede utilizar con current_user_context=True
Para guardias:
- user_ids no se puede utilizar con current_user_context=True
- schedule_ids todavía se puede usar para filtrar por horarios específicos
- La consulta mostrará las llamadas disponibles para todas las políticas de escalamiento asociadas con los equipos del usuario actual.
- Esto es útil para responder preguntas como "¿quién está actualmente de guardia en mi equipo?"
- El ID del usuario actual no se utiliza como filtro, por lo que verá todos los miembros del equipo que están de guardia.

Desarrollo

Ejecución de pruebas

Tenga en cuenta que la mayoría de las pruebas requieren una conexión real a la API de PagerDuty, por lo que deberá configurar PAGERDUTY_API_KEY en el entorno antes de ejecutar el conjunto de pruebas completo.

uv run pytest

Para ejecutar solo pruebas unitarias (es decir, pruebas que no requieren PAGERDUTY_API_KEY configurado en el entorno):

uv run pytest -m unit

Para ejecutar solo pruebas de integración:

uv run pytest -m integration

Para ejecutar únicamente pruebas del analizador:

uv run pytest -m parsers

Para ejecutar únicamente pruebas relacionadas con un submódulo específico:

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

Servidor de depuración con MCP Inspector

npx @modelcontextprotocol/inspector uv run python -m pagerduty_mcp_server

Contribuciones

Lanzamientos

Este proyecto utiliza confirmaciones convencionales para lanzamientos automatizados. Los mensajes de confirmación determinan las actualizaciones de versión:

feat: → versión menor (1.0.0 → 1.1.0)
fix: → versión del parche (1.0.0 → 1.0.1)
BREAKING CHANGE: → versión principal (1.0.0 → 2.0.0)

El CHANGELOG.md, las versiones de GitHub y los paquetes de PyPI se actualizan automáticamente.

Documentación

Documentación de herramientas : información detallada sobre las herramientas disponibles, incluidos parámetros, tipos de retorno y consultas de ejemplo

Convenciones

Todas las respuestas de la API siguen el formato estándar con metadatos, lista de recursos y error opcional.
Los nombres de los recursos en las respuestas siempre se pluralizan para mantener la coherencia.
Todas las funciones que devuelven un solo elemento aún devuelven una lista con un elemento
Las respuestas de error incluyen tanto un mensaje como un código
Todas las marcas de tiempo están en formato ISO8601
Las pruebas se marcan con marcadores pytest para indicar su tipo (unidad/integración), el recurso que prueban (incidentes, equipos, etc.) y si prueban la funcionalidad de análisis (marcador "parsers").

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

Servidor MCP de PagerDuty

Descripción general

Instalación

Desde PyPI

De la fuente

Requisitos

Configuración

Uso

Como extensión de ganso

Como servidor independiente

Formato de respuesta

Manejo de errores

Validación de parámetros

Limitación de velocidad y paginación

Ejemplo de uso

Contexto del usuario

Desarrollo

Ejecución de pruebas

Servidor de depuración con MCP Inspector

Contribuciones

Lanzamientos

Documentación

Convenciones

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers