PagerDuty MCP 服务器
向 LLM 公开 PagerDuty API 功能的服务器。该服务器旨在以编程方式使用,并具有结构化的输入和输出。
概述
PagerDuty MCP 服务器提供了一组用于与 PagerDuty API 交互的工具。这些工具旨在供 LLM 使用,用于对 PagerDuty 资源(例如事件、服务、团队和用户)执行各种操作。
Related MCP server: Lark MCP Server
安装
来自 PyPI
来自源
要求
Python 3.13 或更高版本
PagerDuty API 密钥
配置
PagerDuty MCP 服务器需要在环境中设置 PagerDuty API 密钥:
用法
作为鹅扩展
作为独立服务器
响应格式
所有 API 响应都遵循一致的格式:
错误处理
当发生错误时,响应将包含具有以下结构的错误对象:
常见的错误场景包括:
无效的资源 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} 个结果
示例用法
用户上下文
许多函数接受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 。
仅运行单元测试(即不需要在环境中设置PAGERDUTY_API_KEY测试):
仅运行集成测试:
仅运行解析器测试:
仅运行与特定子模块相关的测试:
使用 MCP Inspector 调试服务器
贡献
发布
该项目使用常规提交进行自动发布。提交消息决定了版本更新:
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 标记来标记,以指示其类型(单元/集成)、测试的资源(事件、团队等)以及是否测试解析功能(“解析器”标记)