38.9% of this index has never answered.

What this says that a directory listing cannot

A registry entry is a claim: someone published a name, a description, and where the code lives. Nothing in the Registry records whether the thing runs. Every other MCP directory republishes those claims, so the only count any of them can produce is how many entries they copied.

This index connects. It acquires the package, starts it without a network or credentials, sends initialize, and asks for the tool list. That is the only reason the largest number here can exist at all: 14,505 servers — 38.9% of everything indexed — have never once completed that handshake. They are not reported as broken, because nothing was observed that would justify saying so. They are unobserved, and the difference matters.

The other half is the more familiar picture: 12,086 servers verified working, 4,670 demanding credentials the probe deliberately does not carry, and 5,994 broken.

Where the reached half stops

The census says how many servers are in each state. It does not say where they stopped, because the stage is recorded per run rather than per state — so this part is sampled, and the sample size is given so it can be judged for what it is.

Across 180 servers drawn evenly from across the whole index, none failed while the package was being acquired. Every server that was reached and did not verify stopped later: 36 during the protocol handshake, and 5 that completed the handshake and then failed the tool listing. Servers that want credentials fail at the handshake too, which is why so much of the non-verified index stops at the same point — the server answered, and what it said was not the protocol.

Those same 180 servers carry the only estimate on this page. Of the 37 holding a recorded tool-quality report, the median server spends 1,511 tokens describing its tools before a model has done any work at all. That is a fixed cost paid on every conversation that loads the server, and it is a sample median rather than a count.

How this is counted

Each state is a rule over the latest observation, and the rules are the same ones the directory filters use, so this page and the listing can never disagree. A verified server that goes 30 days without another success becomes stale without anything else happening to it. A server that fails twice, at least 15 minutes apart, becomes broken. A server with no observation row is counted as not yet observed rather than dropped from the total.

The counts are taken live when this page is requested. They were independently checked against a uniform sample of 720 servers drawn evenly across the index, which agreed with the exact count in every state to within sampling error.

What this does not say

Not observed is not the same as broken, abandoned, or bad. A server may be unobserved because the runner could not reach it, because its package could not be acquired, or simply because the index has grown faster than the probe has reached it — this page does not distinguish between those, and any claim about which one dominates would be a guess dressed as a finding.

A verified server is not a safe one. The probe never calls a tool, never reads an implementation, and does not assess data handling, permissions, dependencies, or security. It records that a handshake succeeded at a moment in time. The method describes the limits in full, and about describes what this project does and does not claim.

These numbers describe this index on the day it was loaded, and the index grows. The API exposes the same figures to anyone who wants to check them.