openstatus
Status page with global uptime monitoring
Start new thread

Openstatus MCP Health Checker - Test MCP servers like a real AI client, not just a ping

by•
Most monitors just send an HTTP ping. But a 200 OK is useless if the JSON-RPC handshake fails. Our tool is different because it performs a true protocol-level check, acting exactly like a real AI client. Key features: Full Handshake: Executes the spec-defined initialize, ping, and tools/list sequence. Deep Visibility: Inspect exact JSON-RPC payloads and negotiated versions. Smart Auth: Parses RFC 9728 headers on 401s to surface exact token requirements.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt! 👋 Max and I are super excited to share this with you today. As we've been diving into the Model Context Protocol (MCP) and building for AI agents, we kept running into the same frustrating issue: a standard 200 OK from an HTTP ping doesn't mean your AI client can actually connect. If the JSON-RPC handshake fails, or if the tools/list returns empty, your agent completely breaks. We built the MCP Server Health Check to solve this. It's a free, zero-install tool that tests your endpoint exactly how a real AI client (like Claude Desktop or Cursor) would. Instead of a basic uptime check, it performs a true protocol-level validation: Real Handshakes: It runs the full spec-defined initialize, ping, and tools/list sequence. Zero-Friction Debugging: You can click into any step to inspect the exact JSON-RPC payloads, negotiated versions, and session IDs. Smart Auth: If your server is locked down, it parses RFC 9728 headers on a 401 to show you exactly where to fetch your auth token. It’s completely open-source, just like the rest of our synthetic monitoring gear at OpenStatus. Give it a spin with your own MCP endpoints (or test it out with a public one like [) and let us know what you think. We’ll be hanging out in the comments all day to answer your questions and hear your feedback! 🚀

 Many congrats on the launch. I have a quick question: when the tools/list returns empty, does the checker differentiate between "tools not implemented" VS "tools filtered by auth/scope?"

 This is a smart solution to a real problem in the MCP ecosystem. The distinction you're making between HTTP-level success and actual protocol-level functionality is exactly what catches people off guard when deploying agents. The JSON-RPC inspection view sounds particularly useful for debugging those mysterious "tool not found" failures.

when you say "like a real ai client" does it go through initialize → list-tools → actually call a tool, or stop at the handshake? in my experience the gap between "server responds to initialize" and "tools actually execute correctly" is where most bugs hide

Maker

 First, we initialize the tools list. We still need to refine the final tool execution step to ensure it works perfectly. This will also allow us to monitor if a tool is taking longer than usual to respond.

This is a useful direction for MCP reliability. A simple 200 OK doesn’t mean an agent can actually use the tool, so testing the real handshake and tools/list flow feels much closer to what production agent systems need.

Maker

 yeah 200 doesnt mean anything for mcp servers,

 Exactly. For MCP, the real question is whether the agent can discover the tools, understand the schema, call them correctly, and recover when something fails. That’s a very different health check than “is the server alive?”

smart approach testing MCP servers as a real client instead of just pinging endpoints. most of the reliability issues i've seen with MCP integrations come from edge cases in the actual tool call flow, not connectivity. curious if you're also testing for things like response format consistency across different server implementations?

Maker

 200 is useless for mcp 😂

timing on this is interesting because MCP server quality is all over the place right now. a lot of servers were built quickly against early drafts of the spec and there's no standard way to know if something is actually compliant until a client breaks on it. is there any plan to expose a compliance score or badge system so developers can signal to potential users that their server passed a real protocol check rather than just an uptime ping

Maker

 100 uptime ping does not make much sense for MCP server

Launched our MCP server 2 days ago - Open status comes at the right time.

Hunter

oss ftw!