MCP Server Health Checker

How to verify an MCP server is actually working

A Streamable HTTP MCP server can look fine from the outside (the URL loads, the deploy is green) and still be broken for every client that tries to use it. The only real test is the protocol itself: send a JSON-RPC initialize request, complete the handshake, then ask for the tool list. That is exactly what this checker does, the same sequence Claude, OpenClaw, and every other MCP client performs when it connects. You get a stage-by-stage report: is the endpoint reachable, does it publish a server card, does initialize succeed and with which protocol version, and how many tools does it expose.

Frequently asked questions

What exactly does the health check send to my server?

Three standard MCP messages over plain HTTP POST: an initialize request (protocol version 2025-06-18, client name remoteopenclaw-health-check), a notifications/initialized notification, and a tools/list request. If your server issues an Mcp-Session-Id header during initialize, we echo it back on the follow-up calls. Nothing else is sent, no tools are invoked, and no auth headers are attached.

My server requires an API key or OAuth. Will the check work?

Partially. The reachability stage still tells you whether the endpoint responds, and a 401 or 403 on initialize confirms your auth layer is doing its job. But the handshake and tool list stages need an unauthenticated endpoint. We do not accept or forward credentials, by design, so we never see your keys.

What is the server card and do I need one?

The server card is an optional JSON file at /.well-known/mcp/server-card.json that describes your server so clients and registries can discover it without a handshake. A missing card does not fail the health check, but publishing one makes your server easier to index and list in directories.

Why does the check handle both JSON and SSE responses?

The Streamable HTTP transport lets a server answer a POST with either a plain application/json body or a text/event-stream that delivers the response as an SSE data event. Clients must accept both, so the checker does too. If your server replies in either format, it passes; if it replies with something else, that is a spec compliance bug worth fixing.

My server passed. What next?

Get it in front of users: submit it to the Remote OpenClaw directory so agent builders can find it, and browse the MCP directory to see how similar servers present themselves. Before you install anyone else's server, run its config through our companion tool, the MCP Security Scanner.