Fewer Than Half of Registry-Listed MCP Servers Answer a Live Call

The registry entry looks right: description matches the use case, price is declared, endpoint is listed. Integration starts. The first test call returns nothing.

This is not an edge case. Today, 6,493 of the registry MCP servers we probed with a live handshake answered. That is 51% of the servers actually tested; the other probed servers did not respond. A further 2,251 registry entries blocked our crawler via robots.txt before we could test them.

The registry is not a liveness check. It records what was submitted, not what is currently running. A service that was live when it was registered can go dark for any reason: the operator wound it down, moved it, stopped paying for the host, or never finished building it. The registry has no mechanism to remove dead entries, and operators have no incentive to deregister a service that cost them nothing to list.

The implication for builders is narrow and immediate. Before writing any integration against a registry-sourced endpoint, run the handshake first. A tools/list call to the declared endpoint costs one HTTP request. If it returns a valid response, the server is live. If it does not, you have learned something the registry cannot tell you.

Two checks taken together answer the question that matters before you commit to an integration. The liveness check establishes whether the service is running. The multi-buyer check, covered [yesterday](/news/agent-multipayer-gap-oct2026), establishes whether anyone other than the operator has found it worth paying for. A service that passes both has cleared two independent thresholds that the registry cannot clear on its behalf.

The 2,251 robots.txt blocks are a separate data point worth noting. Some are services that have opted out of indexing for legitimate reasons: testing environments, private services, capacity management. Others are operators who do not want their dead service discovered as dead. The crawler cannot distinguish between them, which is one more reason the liveness check at integration time is yours to run, not ours to report.