MCP 监控应检查握手、工具与数据

HTTP 200 只能证明服务还能响应，不能证明 AI Agent 能顺利调用工具。握手失败、工具列表变空、返回字段缺失，甚至数据停在三天前，都可能藏在一次「成功」的请求里。

作者把 MCP 可用性拆成四层，并提出故障确认和替代工具发现机制。对正在接入 MCP 的开发者，这篇最有用的提醒是：监控要沿着 Agent 真正依赖的调用链检查，不能停在端口和状态码上。不过，文中的效果数据来自作者自家的 Agent Nexus，适用范围需要单独看。

HTTP 200 后面，还藏着哪四种故障

第一层是存活检查（Liveness）：端点能否在合理时间内响应。每次尝试都应有独立的超时限制。作者特别强调，不能只凭一次 HEAD 超时，就把 MCP 端点判为离线；确认故障必须使用直接 GET 请求。

第二层是能力检查（Capability）：协议和工具是否可用。访问 /mcp 得到 HTTP 200 还不够，服务必须完成 initialize 握手，再通过 tools/list 返回声明过的工具。对于依赖这些工具的 Agent，空数组或未处理的 JSON-RPC 错误，都可能让后续任务无法执行。

第三层是结构检查（Schema）：响应是不是仍然符合约定。JSON 能解析，只说明语法没坏；必填字段缺失，照样会破坏调用。传统监控可能记录「HTTP 200、延迟 85ms」，调用端却因找不到属性而报错，或者让 LLM 根据残缺信息继续生成。

作者建议跟踪输入、输出签名的 Schema hashing，发现接口结构随时间发生的漂移。但原文没有说明如何生成哈希、如何区分兼容变更与破坏性变更，也没有给出实现。

第四层是数据新鲜度（Data Freshness）：内容是否及时、完整。天气、金融或加密货币 API 即使持续返回 200 OK，上游同步也可能已经停了三天。最新时间戳过旧、返回数据量突然归零，都应单独记录为质量异常。

这四层回答的是不同问题：服务在不在，协议通不通，结构对不对，数据还能不能用。任何一层失效，都可能中断多步工作流，浪费 token，或者诱发模型编造替代结果。

故障要先确认，替代工具也要有依据

一次探测失败可能来自网络抖动或冷启动。如果立刻告警、下架服务，维护者会被误报打扰，Agent 也可能放弃原本可靠的提供方。

作者披露，Agent Nexus 的注册引擎采用「连续两次每小时探测失败」才确认故障，并且独立验证恢复。他们声称，这消除了 90% 的误报。

这个规则包含取舍：确认越谨慎，短暂波动越不容易触发告警，但真实故障也会等待下一次探测。每小时两次连续失败适合什么场景，需要结合任务允许等待多久来决定。 原文没有给出 90% 的样本规模、统计周期或比较基线。

确认故障之后，作者主张返回建议性的替代工具，而不只是报错。候选项应有重叠能力、当前健康状态，最好还采用相同的认证方式。

下面的命令用于按故障需求查询发现接口：

curl -s "https://agentnexus.app/api/public/discover?need=sendgrid%20is%20down"

要看的是 need=sendgrid%20is%20down：它把「SendGrid 不可用」作为发现需求。作者称，响应会标出降级端点，并列出替代项的当前健康状态和历史可靠性；原文没有展示响应样例，也没有证明候选工具可以直接替换现有调用。

作者还区分了「现在正常」与「长期可靠」：一个工具当前探测通过，历史可用率可能只有 82%；另一个工具偶尔失败，但此前六个月有 99.9% 的可用率。两类信息需要一起看，单次红绿灯不够用。

我的判断

把监控从 HTTP 状态码推进到协议、结构和数据质量，这个方向成立。对 MCP 调用方来说，真正需要验证的是任务依赖是否满足，而这些依赖确实超出了普通存活探测的范围。

但四层检查并不等于可靠性保证。tools/list 正常，不能证明每个工具的真实调用都成功；调用前健康检查通过，也不能保证执行时没有故障。因此，作者提出的 pre-flight 检查可以减少无效调用，却不能保证自主任务始终按预期完成。

Schema hashing 适合发现变化，但判断变化是否有害，仍要靠明确的接口契约和兼容规则。相比单纯比较哈希，检查调用方实际依赖的必填字段，通常更容易解释失败原因。

这篇也带有产品推广目的：作者称 Agent Nexus 覆盖 726+ 个已验证工具，但没有展开验证标准。90% 的误报改善属于自家系统的效果陈述；替代发现机制也缺少成功率对照。可以借用它的问题拆分方式，暂时不必接受它对产品效果的全部推论。

能拿来做什么

• 给 Node 中的 MCP 接入增加调用前检查，至少覆盖 initialize、tools/list 和任务必需工具是否存在，并为每次探测设置独立超时。
• 对工具响应检查实际依赖的字段；如果任务依赖时效性，再单独检查最新时间戳和数据量，避免把合法 JSON 当作可用数据。
• 把当前健康状态、历史可用率和恢复状态分别记录，再按任务时效要求选择故障确认频率，不要直接照搬每小时探测规则。
• 为关键工具预先整理候选提供方，核对能力和认证方式。发现接口返回的建议应进入选择流程，不能直接视为无条件兼容的替换。