Methodology

This page exists so the record can be argued with. A method nobody can inspect is an assertion, not evidence.

What is measured

We open a read-only Model Context Protocol handshake against an endpoint's declared public URL and record what comes back. Nothing is sent that a client would not send to use the server normally, and no credentials are ever presented to a server we measure.

What is recorded is protocol reachability, not host reachability.Almost nothing we observe is an unreachable machine; unsuccessful attempts are overwhelmingly protocol-level responses from hosts that answered. This distinction is why the record never characterises an endpoint as permanently gone or defunct: such wording would be wrong about the great majority of cases, and unfair in the rest.

What is recorded per observation

The fingerprint matters independently of the count. A server can change its tool schema while the number of tools stays identical, and that change is invisible to anyone comparing counts alone.

The record key, and why it is the endpoint

A record is keyed on the normalised endpoint: the lowercased host and path, with trailing slashes removed. Scheme, query and fragment are dropped; a port is kept.

It is keyed that way because a snapshot commits to its records through a merkle root, so a page's identity has to be a field inside the committed record. The endpoint is the only identifying field there. A registry name is not in the commitment at all, and a page keyed on one could never be tied back to a published root.

Names are recorded as attributes instead. One endpoint may carry more than one registry name — this happens when a namespace is migrated and the old name is left published — and both are shown rather than one being chosen. The name a server reports about itself is kept too, clearly marked as self-reported: it is absent whenever a handshake did not complete, and it is not unique.

The normalisation rule is frozen. Changing it would silently re-identify every record and split histories in two, so it is treated as a disclosed break in the series, never as a tidy-up.

What gets published

A server is published once we hold at least 3 observations of it. Below that the page still exists and stays reachable, but is excluded from search indexes: the endpoint is real, we simply have too little history for the page to be worth reading. Nothing is hidden behind a 404 for having too short a record.

Affiliation

Any endpoint operated by an entity affiliated with us carries a visible disclosure on its page and is excluded from every ranking and from any aggregate presented as independent evidence.

How that resolves in this build: 55 endpoints held · 54 published (1 below the observation threshold) · 1 affiliated and excluded from independent figures · 53 counted as independent, across 51 distinct hosts.

Endpoint counts and operator counts are not interchangeable. One operator can hold a very large number of endpoints, so an endpoint total quoted on its own overstates how diverse a population is. Wherever a count implies diversity, the host count is given beside it.

How each snapshot selected what it looked at

Snapshots are not all the same shape, and a count from one is not automatically comparable to a count from another. Every snapshot therefore declares its basis beside its count on the verification page — a census counts a different thing from a sample, and putting the two in one column without saying so would let true numbers assemble a false trend.

The first snapshot used a sampling rule that is now RETIRED. It selected the 3,000 oldest endpoints by registry publication date, capped at 3,000, plus a 200-endpoint control drawn uniformly without replacement from the full deduped set — 3,200 in total. Every snapshot since has been a full census of every deduped remote endpoint in the registry.

That retired rule is published in full deliberately. A sampling scheme still in use would be operational detail worth withholding, because knowing which endpoints get looked at is knowing which ones do not. A retired one cannot be gamed — the cap no longer applies to anything — so disclosing it costs nothing and lets a reader check our arithmetic on the one snapshot where the population differs.

Disclosure history

We have recorded our own load as though it were a property of somebody else's server, and we corrected it in public. In the second published snapshot, two operators running many subdomains were recorded as rate-limited. That was us: our own requests to those operators produced the throttling we then wrote down as an observation about them. The affected rows are a measurement artifact, they are disclosed as such, and the throttling behaviour was changed so the same class of error is structurally harder to repeat.

This is disclosed rather than quietly fixed for a reason worth stating plainly. A competing proposal to publish health metadata for MCP servers was withdrawn by its own author after the same class of defect — a prober recording its own load as server degradation — was found in its numbers. The difference between that outcome and ours is not that we avoided the mistake. It is that ours is written down here.

Corrections land in the next snapshot, with the artifact named. A published snapshot is never rewritten: an archive you can edit after the fact proves nothing about what was true before you edited it.

What this page deliberately omits

The record is only useful while it cannot be gamed. So this page gives results and rules, and does not publish the operational detail of how or when observations are taken. That is a deliberate omission, stated here rather than hidden.

Verifying any of this

4 snapshots are published as of 2026-08-09. Verify the chain shows how to reproduce a root yourself, without relying on anything on this site.