How the MCP Reliability Index works

A generic uptime monitor asks one question: did the URL return 200? For MCP that isn't enough. A server can be “up” and still be useless to an agent — it exposes no tools, sits behind an auth wall, or its tool schema silently changed. We speak MCP: we run the handshake and list the tools the way a client does, so healthy means an agent could actually use it — not just that the port answered.

For each server with a public remote endpoint we run the MCP handshake (initialize → tools/list) over HTTP, outside-in, with no SDK and no language assumptions — exactly how a client connects. We record whether it responds, the connect latency, the tools it exposes, and a fingerprint of its tool schemas so we can detect silent changes over time.

Healthy — responds and lists its tools without credentials.
Alive, needs auth — responds but requires an API key or OAuth (a 401/403), so we can't inspect its tools. It's alive, just gated.
Dead — unreachable, DNS failure, timeout, or doesn't speak MCP.

An agent that depends on a tool which silently goes down or changes its schema fails quietly — you find out from broken output, not an alert. Across 21,605 probed endpoints, only about a quarter are healthy and public. Knowing which is which before you build on them saves a debugging fire-drill later.

These are outside-in probes at a point in time; a server behind auth may be perfectly healthy for its own users. We re-scan regularly and are not affiliated with any listed server. Found a mistake? Tell us.