One in thirteen MCP servers went silent within seven weeks

We probed 20,340 servers from the official registry 2,998,187 times over 48 days. 1,509 disappeared at least once and 1,706 broke their own tool contract. Payments servers carry 41.5 tools each and one in four has broken its contract; .ru addresses go silent three times as often as the field.

Cite as: FACTANKER, https://factanker.com/record/one-in-thirteen-mcp-servers-went-silent-in-seven-weeks

An agent that calls a tool on a remote server is making a bet: that the server answers, and that the tool still takes the arguments it took yesterday. Since 30 August 2026 we have been measuring whether that bet holds. Four times a day we take the server list from the official Model Context Protocol registry and ask each endpoint what it claims about itself — protocol version, identity, authentication scheme, tool contract. We record the answer and, more importantly, the date it changed.

As of 17 October that is 2,998,187 endpoint probes across 196 runs and 48 days, covering 20,340 servers. This is not uptime monitoring and we make no claim about anything before our first run. What follows is what the measurements say.

Servers vanish, and some come back

1,509 servers — one in thirteen — were unreachable at least once after we had seen them working. 837 of them have not returned. 672 went quiet and came back, which is its own kind of signal: an agent that gave up on them would have been wrong.

We close a period rather than delete a record. When a server stops answering, the fact that it was reachable stays, with an end date. The registry lists the server either way; only a measurement can tell you whether anyone is home.

The contract breaks more often than the server disappears

A breaking change means a tool vanished from the server's own list, or its required arguments changed. Code written against the old contract fails. We counted 5,335 breaking changes across 1,706 servers — that is 111 every day, in an ecosystem of twenty thousand servers that is seven weeks old.

The concentration is remarkable. These eight servers account for 1,129 of them by themselves:

The leader changed its tool contract in a breaking way 3.5 times a day, every day, for seven weeks. The second one has 167 breaking changes and currently offers zero tools. Both are listed in the registry as normally as any other.

Two in three ask for nothing

12,708 servers — 62.5 percent — require no authentication at all. Anyone who knows the address can call the tools. 6,338 use a bearer token, 774 answer with HTTP 401 and 488 with 403 without naming a scheme, and 24 use an API key or basic auth.

Where they are, measured by their own address

Only 1,538 of the servers answer under a country-code domain; the rest sit on .com, .ai, .io and other generic names, which say nothing about where anyone is. For the ones that do carry a country code, the difference in survival is hard to miss.

Against an overall rate of 4.1 percent, a .ru address is three times more likely to have stopped answering, and 328 British-domain servers have not lost a single one. We are describing addresses, not companies — but the address is what an agent actually calls.

What they do, and how much of it

The registry assigns no categories, so we derive one from each server's own tool names. The spread in tool count is the striking part: a payments server carries 41.5 tools on average, more than three times the overall mean of 13.3, while a search server gets by with 7.4.

One in four payments servers has broken its own contract at least once — 235 of 956. These are the servers an agent would call to move money.

What the rest of the measurement says

Speed is not the problem: 17,891 servers answer in under a second, 2,149 take one to three seconds, 261 take three to ten, and 39 need ten seconds or more. The median server offers 6 tools; 160 servers offer more than a hundred, and one offers 1,713. Ten servers answer correctly and offer nothing at all.

On protocol versions the field has largely converged on 2025-06-18 (11,778 servers), but 652 still answer with 2024-11-05, and a few have already moved to dates in the future of this writing.

Every group above has its own page, measured against all 20,340 servers so a figure can be placed rather than merely read: by authentication, by response time, by country domain and by capability. The observatory index lists all 52 of them.

Why we measure this at all

Verification scales worse than generation. A language model can describe what an MCP server offers; it cannot know whether the server answered this morning, or whether the tool it is about to call still takes the same arguments it took in September. That is not a question of knowledge but of measurement, and a measurement needs a date and a witness.

Every number on this page is a fact with a source and a timestamp, and every server has its own page with its full observation history. The data is also available over our MCP server and as JSON — no key, no registration.

Method: four probe runs a day against the endpoints listed in the official MCP registry, at most five endpoints per host per run, one second between hosts. A measurement is an endpoint probe; a fact is written only when a value changes, which is why 2,998,187 measurements produced 233,777 facts. Latency is reported in classes and only changes class after two consecutive readings, so a single slow moment does not move a server. The history begins at our first run; we claim nothing about the time before it.

The records behind this article