PagerDuty MCP 服务器

一个将 PagerDuty API 功能暴露给 LLM 的服务器。该服务器旨在以编程方式使用，具有结构化的输入和输出。

概述

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

安装

从 PyPI 安装

pip install pagerduty-mcp-server

从源代码安装

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

# Install dependencies
brew install uv
uv sync

需求

• Python 3.13 或更高版本
• PagerDuty API 密钥

配置

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

PAGERDUTY_API_KEY=your_api_key_here

使用

作为 Goose 扩展

{
  "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 时，不能使用某些过滤参数，因为它们会与自动过滤冲突：

• 对于所有资源类型：
  • 不能在 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
  • 仍可以使用 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 Commits进行自动化发布。提交消息决定了版本号的增加方式：

• 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标记来指示其类型（单元/集成）、所测试的资源（事件、团队等）以及是否测试解析功能（"parsers" 标记）