Methodology
Tooltower watches remote MCP servers from the outside, the way a client sees them. This page explains what we measure, what the labels mean, and what we will not claim.
What is public
- Status pages and badges exist only for servers whose owners turned them on.
- Research reports publish aggregates from occasional snapshots of public servers (at most weekly). They never label a named server as down.
What a check is
A liveness check is one server/discover POST. A server is reachable when its MCP handler returns a
well-formed JSON-RPC response — a result or an error. Servers on protocol versions before 2026-07-28 answer
server/discover with a standard error, and that counts as reachable: an older server is not a broken one,
because dual-era clients (Claude, Claude Code, Codex and others) still connect to it.
Once a day we also detect the protocol era and transport (2026-07-28, an earlier version over streamable HTTP, or the deprecated HTTP+SSE transport) and, hourly, read the anonymous tool/prompt/resource lists.
Outcomes that are never "down"
| Outcome | Meaning |
|---|---|
| Auth edge reachable | The server asks for authorization (401 with a challenge). We report the edge, not the backend, and never mark it Operational. |
| Blocked by WAF | A bot-protection page answered instead of the server. Says nothing about the server. |
| Rate limited | 429, or 503 with Retry-After. We back off. |
| Cold start | The first try timed out and an immediate retry succeeded — typical for scale-to-zero hosting. |
| Incomplete TLS chain | The server omits an intermediate certificate; many clients still connect. Reported as a warning. |
Status labels
- Operational — the MCP backend answered (anonymously, or with the owner's token) and checks pass.
- Degraded — p95 latency above 3× its own baseline, failures in some regions, or conformance errors on a claimed server.
- Down — only when all three hold: a private incident is open (a failure confirmed from a second region, same error family), at least 2 consecutive failed cycles, and at least 10 minutes have passed.
- Auth discovery broken — every discovery mechanism the MCP specification defines failed, confirmed twice from two regions. The page quotes the requirement that is not met.
- Insufficient data, Paused at owner request — what they say.
If more than 20% of the closely watched servers fail from one region in the same 5 minutes, we assume the problem is ours: that region is quarantined, and if it happens everywhere public "Down" labels are suppressed.
How we measure
- Every check opens a new connection (DNS, TCP, TLS, request), so latencies are cold-connection latencies. We record each phase separately.
- If our own process stalls for more than 50 ms during a check, that sample's timing is discarded.
- We resolve DNS ourselves and connect only to public addresses; IPv4 only for now.
- One retry after 1–2 seconds, only for timeouts, connection resets and 502/503/504 without
Retry-After.
What we do not claim
- That we are affiliated with the MCP project, the MCP Registry, or any vendor we list. Data on servers comes from the Official MCP Registry and our own probes.
- That a server is "down" on the strength of one probe, one region, or a WAF page.
- That a server on an earlier protocol version is broken.
Corrections
Owners can annotate incidents and ask for corrections; we answer within 1 business day. Corrections are logged here.
| Date | Server | Correction |
|---|---|---|
| — | — | — |
How the bot behaves and how to opt out: /bot.