OpenStatus MCP Server 接入指南让 AI 助手替你巡检监控、发布事故与排期维护【免费下载链接】openstatus Status page with uptime monitoring API monitoring as code 项目地址: https://gitcode.com/GitHub_Trending/op/openstatusOpenStatus 为 AI 助手提供了一套远程 MCPModel Context Protocol服务器暴露于https://api.openstatus.dev/mcp采用 streamable-HTTP 传输让任何支持 MCP 的客户端Claude、ChatGPT、Cursor、Codex、opencode 等都能读取监控器、通知渠道、私有探测节点与审计日志并直接创建状态页事故、追加更新、解决报告或排期维护窗口。本文基于仓库中的 openstatus-mcp SKILL 文档 与 MCP 服务端源码完整讲解连接方式、23 个工具的职能边界、变更类操作的强制确认规则以及审计追溯机制读完即可在任意 MCP 客户端中安全、合规地把 OpenStatus 接入你的 AI 工作流。什么是 openstatus MCP serverOpenStatus 把状态页、监控器、审计日志等核心能力封装成一个远程、可流式传输的 HTTP 端点任何实现了 MCP 协议的客户端都能以统一方式调用它。这个端点是远程托管的不需要你自行部署它同时面向“人机协同”和“全自动 Agent”两类使用场景交互式客户端Claude Desktop、Claude Code、Cursor、VS Code 等通过 OAuth 授权登录在同意页上选择工作区与访问级别无人值守场景CI、cron、headless agent通过 API Key 携带在x-openstatus-key请求头中完成认证。MCP 端点共暴露23 个工具其中 19 个以单一工作区为作用域读写状态页、事故报告、维护窗口、监控器、通知、私有位置、审计日志4 个用于检索并读取 openstatus.dev 上的公开内容文档、定价、博客等。对于不含audit-log功能的套餐审计类工具不会注册暴露的工具数量为 21 个。这一差异在服务端源码中有明确实现——registerAuditTools会根据ctx.workspace.limits[audit-log]决定是否注册审计工具见 audit.ts。从源码结构看MCP 服务端由以下模块组成见 mcp 路由目录模块文件注册的工具域server.ts统一装配所有工具注册器构建McpServer实例index.tsHTTP 传输层、401 挑战与 OAuth 发现、JSON-RPC 信封处理tools/page.ts状态页与页面组件只读发现tools/status-report.ts事故报告的创建、更新、解决tools/maintenance.ts维护窗口的创建与列举tools/monitor.ts监控器配置、状态、汇总、响应日志只读tools/notification.ts/tools/private-location.ts通知渠道与私有位置只读tools/audit.ts审计日志需要audit-log计划tools/content.ts公开内容搜索与读取resources.ts三个公开只读资源连接方式一OAuth推荐交互式客户端原理401 即发现机制OpenStatus 的/mcp端点是一个符合 RFC 9728 的 OAuth 保护资源。当客户端不带任何凭证发起请求时服务端不会默默返回一个“匿名但可用”的会话而是返回401并在响应头中携带WWW-Authenticate: Bearer resource_metadata...挑战见 index.ts。这个 401 并非错误而是标准的 OAuth 发现机制客户端看到挑战后就能定位授权服务器、发起授权码流程。任何实现了 MCP 授权规范的客户端Claude.ai、Claude Desktop、Claude Code、ChatGPT、Cursor、Codex、opencode、VS Code都会自动注册自身、弹出授权同意页并通过 PKCE 交换得到os_oat_…前缀的 bearer token。配置步骤在客户端 MCP 配置中直接指向端点无需填写任何请求头{ mcpServers: { openstatus: { type: http, url: https://api.openstatus.dev/mcp } } }以 Claude Code 为例也可以使用 CLI 添加claude mcp add --transport http --scope user openstatus https://api.openstatus.dev/mcp同意页上的选择在 OAuth 同意页上你需要选择两件事工作区workspace这次授权作用于哪个工作区访问级别accessread-only只读或read write读写。授权的应用可以在Settings Integrations Connected apps中随时查看和撤销。在服务端OAuth 授权最终会被解析为携带scopes的访问令牌见 auth.ts审计日志会把keyId记为oat_grant idcreatedById记为授权用户从而把每一次 MCP 调用追溯到具体的授权授权与用户。连接方式二API KeyCI、cron、headless agent对于无人值守场景把 OpenStatus API Key 放在x-openstatus-key请求头中即可。这把 Key 与 CLI、REST API、Terraform Provider 共用同一套密钥体系可在Settings General的API Keys卡片中创建以os_开头。{ mcpServers: { openstatus: { type: http, url: https://api.openstatus.dev/mcp, headers: { x-openstatus-key: os_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx } } } }关于凭证优先级文档与源码保持一致的约定当 OAuth token 与 API Key 同时存在时请求头中的凭证胜出。在认证中间件中凭证提取与校验顺序遵循extractCredential→validateKey的链路见 credentials.ts 与 auth.ts校验通过后工作区与 API Key 信息会被注入请求上下文供 MCP 工具闭包使用。Scopes凭证携带的权限边界两种凭证都携带 scope且权限是结构性强制的而非调用时的临时检查只读凭证在tools/list中只能看到list_*与get_*工具变更类工具根本不会被注册因此无法被调用读写凭证暴露全部工具。API Key 的 scope 在创建时固定OAuth 授权的 scope 在同意页选择。这一设计在服务端是双保险实现的见 register-scoped.ts注册阶段用matchesScope过滤工具只读 key 看不到写工具即使过滤逻辑出现缺陷底层 service 的requireScope(ctx, write)也会抛出ForbiddenError兜底——“过滤是用户体验service 校验才是正确性保证”。23 个工具全景状态页只读发现list_status_pages列出工作区拥有的状态页用于解析变更类工具所需的pageIdlist_page_components列出状态页上的组件id、名称、类型、关联的监控器用于解析pageComponentIds。值得注意的是状态页工具在输出上做了投影处理页面可能携带password、customDomain等访问控制秘密因此注册工具只输出精简的{ id, title, slug }结构完整数据行不会离开服务层见 page.ts。状态报告事故list_status_reports读取状态页上的事故filter: active | all分页。分页参数在 status-report.ts 中定义为 1 起始的page与perPage默认 50上限 200并返回每个报告的最新一条更新create_status_report开启新事故。入参包括title、初始status、公开message、pageId、可选pageComponentIds与componentImpacts、可选date覆盖、以及必填的notifyadd_status_report_update在未解决的事故上追加一条公开更新update_status_report编辑事故元数据标题、状态、关联组件不产生公开更新resolve_status_report以一条最终更新关闭事故状态置为resolved。组件影响componentImpacts支持operational | degraded_performance | partial_outage | major_outage四种取值组件 id 必须来自list_page_components。源码中还实现了“影响携带”carried impacts逻辑追加更新时若用户只给出发生变化的组件影响服务会读取报告当前的非 operational 影响并合并进去使每次更新的数据自包含确认预览也能展示完整影响面见 status-report.ts。维护窗口list_maintenances读取已排期的维护窗口分页page与perPage默认 50、上限 200create_maintenance排期维护窗口from/to使用 ISO 8601 时间如2026-04-30T14:00:00Z且to必须严格晚于from——该约束由 Zodrefine校验违反时会返回可恢复的校验错误见 maintenance.ts。监控器只读list_monitors列出监控器含activeIncidentCount用于解析其他监控器工具所需的数字型monitorIdget_monitor完整配置——URL、区域、周期、重试、通知渠道、标签。它不返回延迟或状态那属于下面两个工具get_monitor_status按区域返回当前健康状态active/degraded/error。工具描述明确要求 Agent 以“最差区域”汇报不得自行发明一个“总体”标签见 monitor.tsget_monitor_summary返回1d默认、7d、14d窗口内的成功/降级/失败计数与 p50–p99 延迟list_response_logs返回最近各区域的探测结果状态码、延迟窗口同样为1d/7d/14d仅 HTTP 监控器get_response_log单次探测的完整详情——各阶段计时dns、connect、tls、ttfb、transfer、脱敏后的响应头、错误信息、断言结果。响应体内容刻意不暴露见 monitor.ts。工作区只读list_notifications通知渠道及各自接线的监控器。渠道的data字段token、webhook URL、手机号在输出中被整体省略凭证永不暴露见 notification.tslist_private_locations私有位置自托管探测 Agent及其状态与lastSeenAt。token字段被省略Agent token 永不暴露status: error表示 Agent 心跳异常需结合lastSeenAt判断其是否存活见 private-location.tslist_audit_logs最近 14 天的审计日志条目可用entityTypeentityId过滤需要audit-log计划功能get_audit_log单条审计条目的 before/after 快照与changedFields同样需要audit-log计划。公开内容只读无工作区数据以下 4 个工具面向 openstatus.dev 的公开页面不包含任何工作区数据任何凭证、任何 scope 下都可用search_docs检索文档、指南或更新日志type默认docs返回供get_doc_page使用的pathget_doc_page按path读取某一文档、指南或 changelog 页面的完整 Markdownsearch_content检索全部公开页面——产品/定价、博客、对比页、用例、客户故事、工具页以及文档/指南/更新日志type默认all。实现上走https://www.openstatus.dev/api/search并对返回的 Markdown 做了 24000 字符截断以控制上下文占用见 content.tsget_content_page按path如pricing、blog/…、compare/…读取任意公开页面的完整 Markdown适合回答“哪个套餐适合我”或“openstatus 与 X 相比如何”这类问题。Resources三个只读资源除工具外服务器还在任意凭证下暴露三个只读资源见 resources.tsopenapi-specificationOpenStatus HTTP API 的机器可读描述内联自仓库的openapi.jsonmcp-server-reference本 MCP 服务器的传输、认证与完整工具列表参考页site-indexopenstatus.dev 的llms.txt站点索引。这些远程资源的读取实现了超时与降级网络拉取失败时resources/read不会返回空体空体会被客户端视为服务故障而是降级为指向同一 URI 的指针文本见 resources.ts。变更类操作的强制规则MCP 服务器对任何“对外发布”的工具都施加了严格的确认纪律这些规则写进了工具描述并被源码强制执行notify是显式必填参数create_status_report、add_status_report_update、resolve_status_report、create_maintenance都要求显式传入notify: true | false没有默认值。模型必须询问用户是否要通知订阅者。update_status_report没有notify字段——因为它不产生新的更新条目根本没有可派发的通知路径。通知随调用即时派发不可补发通知在同一个调用内完成派发见 status-report.ts 中notifyStatusReport的调用。以notify: false发布的更新之后永远无法再补发通知。工具会在返回的notified: boolean字段中如实报告实际派发结果——即使通知派发失败事故/维护记录本身依然持久化。绝不猜测数字 id先调用list_status_pages和list_page_components获取真实 id工作区之外的 id 会返回NOT_FOUND。错误映射上NOT_FOUND、VALIDATION、CONFLICT、LIMIT_EXCEEDED、PRECONDITION_FAILED等被归类为可恢复错误LLM 可读消息后重试而UNAUTHORIZED/FORBIDDEN/INTERNAL则抛出 JSON-RPC 层的McpError见 adapter.ts。先拟稿、后确认、再执行起草标题、状态、消息与受影响组件向用户展示草稿确认notify取值然后才调用工具。这些规则在框架层也有对应实现AgentTool类型携带destructive标志与可选的approval元数据见 types.ts注册时会被镜像到 MCP 标准的destructiveHint/readOnlyHint/idempotentHint注解供 Claude Desktop、Cursor 等外部客户端在 UX 层做确认提示与缓存决策见 registry-adapter.ts。同时注册器会校验注解与 scope 的一致性——一个写工具若标成readOnlyHint: true会直接抛错绝不允许“对客户端撒谎”见 register-scoped.ts。审计每一次 MCP 变更都可追溯所有 MCP 变更操作都会写入工作区审计日志且带有完整的身份信息actor_type mcp——区别于 API Key 等其他传输面便于按传输面切片统计见 adapter.ts 中toServiceCtx的设置actor_id 凭证标识——API Key 的 id或 OAuth 授权的oat_grant idactor_user_id 凭证背后的人——API Key 的创建者createdById或 OAuth 授权用户。因此任何一次变更都可以追溯到具体是哪把 Key / 哪个 OAuth 授权、哪个用户、经由 MCP 传输面发起的。配合list_audit_logs与get_audit_log可以在 14 天窗口内查看 before/after 快照与字段级 diff。一次完整实战AI 助手处理一次故障把上述能力串起来一个典型的“AI 值班”流程如下发现用户对助手说“检查一下支付网关监控器”。助手调用list_monitors找到目标monitorId研判调用get_monitor_status看各区域状态调用get_monitor_summary看最近 1d 的失败率与延迟调用list_response_logs/get_response_log定位具体失败与断言结果草稿助手拟好事故标题、初始状态、公开消息与受影响组件通过list_status_pages/list_page_components解析出真实pageId/pageComponentIds确认向用户展示草稿并询问是否通知订阅者得到明确的notify值后调用create_status_report跟进故障修复后调用add_status_report_update或resolve_status_report收尾追溯事后用list_audit_logs查看这次操作是谁、用哪把凭证执行的。参考文档完整工具 schema、OAuth 端点与错误码https://www.openstatus.dev/docs/reference/mcp-server/仓库内对应实现见 resources.ts 的mcp-server-reference资源产品概览https://www.openstatus.dev/tooling/mcp-server服务端实现 apps/server/src/routes/mcp/index.ts、apps/server/src/routes/mcp/server.ts工具注册与作用域过滤apps/server/src/routes/mcp/tools/register-scoped.ts、apps/server/src/routes/mcp/tools/registry-adapter.ts各工具域的服务层实现packages/services/src/agent-tools/【免费下载链接】openstatus Status page with uptime monitoring API monitoring as code 项目地址: https://gitcode.com/GitHub_Trending/op/openstatus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考