导语：MCP 让 AI 应用可以像“插拔外设”一样连接外部工具，但工具一旦不可达、超时或依赖失效，智能体就可能进入错误调用、反复重试甚至输出误导性结果。🧩 因此，在设计 MCP Server 时，工具健康检查与可用性探测不应被当作运维附属项，而应成为工具暴露、调用和降级策略的一部分。
为什么 MCP 工具需要健康检查
MCP 的核心价值在于标准化 AI 应用与外部数据源、API、数据库、文件系统或业务服务之间的连接。根据 MCP Tools 官方规范，服务器可以向模型暴露可调用工具，客户端通过 tools/list 发现工具，再通过 tools/call 发起调用。这意味着工具列表本身就是模型决策上下文的一部分：如果列表中存在“看起来可用、实际不可用”的工具，模型很可能选择错误路径。
健康检查要解决的不是“工具是否存在”，而是“工具现在是否值得被调用”。一个天气查询工具可能已经注册成功，但其上游 API 已经过期；一个数据库检索工具可能仍在 tools/list 中，但连接池已耗尽；一个文件处理工具可能能响应请求，却因为磁盘权限异常无法完成任务。✅ 可用性探测的目标，就是在模型调用之前尽量识别这些风险。
工具可用性的三个层次
1. 存活性：服务是否还在运行
存活性检查关注 MCP Server 进程、容器或连接是否仍然存在。对于 stdio 传输，可以观察子进程退出码、标准错误输出和心跳日志；对于 HTTP 类部署，可以提供轻量级的 /health 端点，只判断进程是否能响应。存活性检查应尽量简单，避免访问数据库、第三方接口等慢依赖，否则健康检查本身会变成系统负担。
2. 就绪性：服务是否可以接收调用
就绪性检查关注 MCP Server 是否已经完成初始化，并具备处理工具请求的条件。例如，配置是否加载完成、认证凭据是否存在、数据库连接是否可用、缓存或向量索引是否已预热。相比存活性，就绪性更适合用于流量路由：当服务存活但未就绪时，编排系统可以暂时不把请求转发给它，而不是立刻重启。
3. 功能性：工具是否能完成真实任务
功能性探测更贴近业务结果。它可以针对关键工具执行低成本、只读、无副作用的探测，例如查询数据库版本、验证上游 API token、读取测试资源、检查模型所需 schema 是否仍然匹配。⚠️ 这类探测要避免写入真实数据，也不要使用会产生费用、发送消息或触发业务流程的操作。
MCP 协议内的发现机制与变化通知
在 MCP 中，客户端可以通过 tools/list 获取当前可用工具集合。官方规范说明，支持工具的服务器必须声明 tools capability，并响应 tools/list 请求；工具集合可以为空，也可以随时间变化。规范还提供 listChanged 能力，用于在工具列表发生变化时通知客户端重新获取列表。📌 这为“动态可用性”提供了协议基础：当某个工具因依赖异常被临时下线时，服务器可以更新工具列表，而不是让模型继续看到不可调用的能力。
需要注意的是，tools/list 更适合表达“当前应暴露哪些工具”，而不是承载详细监控数据。实际工程中，可以把工具健康状态分为两类处理：一类影响工具是否对模型可见，例如核心依赖失效时临时隐藏工具；另一类仅影响调用策略，例如工具可用但延迟升高时降低优先级、增加超时或提示用户稍后重试。
Ping、心跳与连接探测的边界
早期 MCP 规范中包含可选的 ping 机制，用于让通信双方验证连接是否仍然响应；接收方需要及时返回空结果，发送方在超时后可以认为连接陈旧、终止连接或尝试重连，相关说明可参考 MCP Ping 旧版规范。不过，ping 只能证明“对端能回包”，不能证明某个工具的数据库、外部 API 或权限一定正常。
因此，健康检查不能只依赖心跳。更稳妥的做法是：连接层使用心跳、超时和重连策略判断通道是否健康；应用层使用 readiness 和功能探测判断工具是否可调用；业务层根据错误类型决定降级、隐藏工具或提示人工介入。这样可以避免把“连接可达”误判为“工具可用”。
推荐的实现策略
- 为不同传输设计不同检查方式：stdio 场景重点监控进程状态、stderr、初始化结果；HTTP 场景可以增加 /health 和 /ready；长连接场景则关注断线、超时和重连。
- 把工具状态结构化：建议至少包含 toolName、status、reason、lastCheckedAt、latencyMs、dependencyStatus 等字段，便于日志、告警和客户端判断。
- 设置合理缓存：依赖检查不要每次 tools/list 都实时访问数据库或第三方服务，可以使用短 TTL 缓存，平衡准确性与系统压力。
- 区分错误级别：临时超时可以返回降级提示；认证失效应阻止调用并告警；危险操作工具应在健康异常时直接隐藏或要求人工确认。
- 避免有副作用探测：健康检查不应发送邮件、创建工单、修改记录或扣减额度，最好只执行只读请求。
客户端如何利用健康信息
客户端不应机械地把 tools/list 返回的所有工具都交给模型，而应结合健康状态进行过滤和排序。🌐 对关键工具，可以在会话开始、工具列表变化、调用失败后重新探测；对非关键工具，可以采用懒加载或失败后降级。若工具失败，应向模型返回清晰、可解释的错误信息，例如“搜索服务暂不可用，可尝试本地知识库”，而不是只返回模糊的 timeout。
在多工具工作流中，还可以建立“替代工具”策略。例如主数据库查询失败时，切换到缓存检索；实时天气接口不可用时，提示无法获取实时数据而不是编造结果；写操作工具不可用时，保留草稿并请求用户稍后确认。这样能把健康检查从单纯监控能力，升级为 AI 工作流的可靠性机制。
总结
MCP 工具健康检查的重点，不是给每个工具加一个简单的“在线”标签，而是建立从连接、服务、依赖到业务功能的分层可用性判断。tools/list 和 listChanged 可以帮助客户端理解哪些工具当前应被暴露；心跳和超时可以发现连接异常；readiness 与功能探测则负责判断工具能否真正完成任务。🚀 对生产级 AI 应用来说，可靠的 MCP 工具探测机制可以减少无效调用、降低幻觉风险、提升用户信任，并让智能体在复杂环境中更稳地完成任务。
