We pointed a real MCP client at 11 public Model Context Protocol servers. The latency spread was 215× — and uptime is the least of the problem.
The Model Context Protocol went from a proposal to 10,000+ public servers in about a year. Agents now lean on these servers the way web apps lean on APIs. But there's no Pingdom for MCP — nobody's watching whether these servers are actually healthy. So we built one, and pointed it at a starter set of well-known public servers.
Each server gets a real MCP handshake — not a dumb HTTP ping. We run initialize, then tools/list, exactly like an agent would, and measure the round trip. Here's what we found.
Hugging Face answered the full handshake in 97ms. GitMCP took nearly 21 seconds for the same exchange. Median across the fleet was 522ms. If your agent calls a tool on a 21-second server, that's 21 seconds your user is staring at a spinner — or your request times out entirely. Latency isn't a vanity metric here; it's the difference between an agent that works and one that hangs.
| Server | Handshake latency | Tools |
|---|---|---|
| Hugging Face | 97 ms | 8 |
| Context7 | 108 ms | 2 |
| Cloudflare Docs | 148 ms | 2 |
| SpaceMolt | 194 ms | 183 |
| Exa | 239 ms | 2 |
| CrashStory | 522 ms | 18 |
| Roundtable | 551 ms | 13 |
| DeepWiki | 605 ms | 3 |
| Chainflip Broker | 634 ms | 6 |
| Microsoft Learn | 664 ms | 3 |
| GitMCP | 20,820 ms | 5 |
Those 11 servers expose 245 tools between them — from a 2-tool docs server to SpaceMolt's 183-tool game server. Every one of those tools is a contract: a name, and a set of required inputs that agents depend on.
Here's the blind spot. A normal uptime monitor sees 200 OK and reports "healthy." But MCP servers don't usually fail by going down — they fail by quietly changing the contract. A tool gets renamed in a redeploy. A parameter that was optional becomes required. A tool disappears. The server still returns 200 OK — and every agent calling it silently breaks, with no error on the server's side.
Uptime tells you the server answered. It can't tell you the server still does what your agent expects.
This is the failure mode nobody's monitoring, because catching it requires actually speaking the protocol and diffing the tool schemas over time — which is exactly what we built.
A year ago, a flaky MCP server was your own problem on your own laptop. Today, agents in production depend on a web of third-party MCP servers maintained by other teams who can redeploy at any moment. The reliability surface moved from "my code" to "everyone's servers" — and the tooling hasn't caught up. That gap is the whole reason this report exists.
Run an MCP server? Know before your users do when it breaks.
Continuous handshake checks + breaking-change alerts. Free during beta.
Get early access →Each server is probed with a full MCP handshake over Streamable HTTP (initialize → notifications/initialized → tools/list). Latency is end-to-end, including tool discovery. Figures are a representative snapshot from June 2026; the Reliability Index updates continuously, and uptime percentages accrue over time. Tools are anonymous, public, no-auth endpoints. Want your server tracked? The open-source checker is on GitHub — or just ask.