Openstatus MCP Health Checker
MCP健康检查工具，专为AI开发者设计，模拟真实AI客户端进行协议级测试，确保MCP服务器功能正常。
Maker 说
Hey Product Hunt! 👋
我和 Max 今天超级兴奋地和大家分享这个。
在我们深入研究 Model Context Protocol (MCP) 并构建 AI 智能体相关的产品时，我们一直反复遇到同一个烦人的问题：HTTP ping 返回标准的 200 OK 并不代表你的 AI 客户端真的能连上。如果 JSON-RPC 握手失败，或者 tools/list 返回空，你的智能体就会直接崩溃。
我们做了 MCP Server Health Check 来解决这个问题。它是一个免费、零安装的工具，完全按照真实 AI 客户端（比如 Claude Desktop 或 Cursor）的方式测试你的 endpoint。
不只是简单的可用性检测，它执行真正的协议级验证：
真实握手：它运行完整的 spec 定义的 initialize、ping 和 tools/list 序列。
零摩擦调试：你可以点进任何步骤，查看精确的 JSON-RPC payload、协商的 version 和 session ID。
智能认证：如果你的服务器受保护，它会在 401 时解析 RFC 9728 的 header，直接告诉你从哪里获取 auth token。
它完全开源，就像我们在 OpenStatus 的其他合成监控工具一样。
试试你自己的 MCP endpoint（或者用公共的比如 https://hf.co/mcp 来测试），告诉我们你的想法。我们会全天在评论区回答你的问题、听取反馈！🚀
热门评论
两天前我们发布了MCP服务器——开源状态来得正是时候。
你说“像一个真正的AI客户端”，它是会走完 initialize → list-tools → 真正调用工具，还是在握手阶段就停了？根据我的经验，“服务器响应initialize”和“工具实际正确执行”之间的间隙正是大多数 bug 藏身之处。
@tibozaurus 这是提升 MCP 可靠性的一个有用方向。简单的 200 OK 并不意味着智能体就能真正使用那个工具，所以测试真正的握手和 tools/list 流程，感觉更贴近生产级智能体系统所需。
这个时机挺有意思的，因为目前 MCP 服务器的质量参差不齐。很多服务器是根据早期规范草案快速搭建的，而且没有一个标准方法来判断某个服务器是否真的符合规范，直到某个客户端在上面出错才能发现。有没有计划推出一个合规分数或徽章系统，让开发者可以向潜在用户表明他们的服务器通过了真正的协议检查，而不仅仅是正常运行的 ping 测试？
用真实客户端的方式测试 MCP 服务器而不只是 ping 端点，这个做法很聪明。我见过的 MCP 集成中的大多数可靠性问题都来自实际工具调用流程中的边缘情况，而不是连接性。好奇你们是否也在测试不同服务器实现之间的响应格式一致性之类的方面？
OSS 太牛了！