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.

1113 of the 13203 endpoints held in this build fall below that threshold and are therefore excluded from search indexes and from every count presented as a published population. They are not excluded from the archive, and their pages are reachable and say so on their face. An endpoint sits here because it entered the registry recently, not because anything is wrong with it.

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: 13203 endpoints held · 12090 published (1113 below the observation threshold) · 1 affiliated and excluded from independent figures · 12089 counted as independent, across 9026 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.

A gap in the record: registry names

Registry names are not held in the archive for snapshots REL-SNAP-001 through REL-SNAP-012. They are held from REL-SNAP-013 onward. For the earlier period every record page shows no registry name, and that is a gap in our data rather than a property of the endpoint.

The reason is worth stating exactly. A registry name was read during each sweep and used to find the endpoints to measure, but it was never written into the published snapshot itself — only the endpoint, the outcome and the schema fingerprint were. A registry name is a point-in-time fact: what a registry said on one date cannot be recovered on a later one, because the registry has since changed.

So it is fixed forward, not backward. From REL-SNAP-013 each snapshot carries the names the registry returned during its sweep. The twelve before it stay empty rather than be reconstructed from a source the published roots do not commit to. Filling them in after the fact would mean putting values into a public record that no merkle root ever covered — which is precisely the thing this archive exists not to do.

An empty value therefore means two different things either side of that boundary. Before REL-SNAP-013 it means we did not collect names at all. From REL-SNAP-013 it means no registry name was observed for that endpoint. They are the same absence on the page and they are not the same fact, so a reader counting endpoints without a registry name must not pool the two periods. The published export does not yet carry the collected names, so every record on this site currently shows none for that reason and not the other.

Registry names are not part of the anchored commitment, and they are marked that way wherever they appear, in the same way the endpoint count is on the verification page: a registry name is an attribute we observed alongside the measurement, not a field the chain commits to. No inclusion proof covers one, and no merkle root will ever be evidence for one.

What a recorded registry name does not prove. It records what the registry said at the time of that sweep, as observed by us. It is not evidence that the registry was correct, that the name belongs to whoever registered it, or that it still resolves today. We publish what we read, dated; the name is the registry's claim about the endpoint, not ours.

What a verified claim proves — and what it does not

An operator can claim an endpoint by publishing a key where the registry's own specification says to publish it, and then signing a challenge we issue. Reading a published key proves nothing on its own — anyone can read it — so nothing is accepted without a signature over a challenge bound to the exact endpoint being claimed, a single-use value, and a short expiry.

The key is read from one of two places: a TXT record at the domain apex, or a file served at /.well-known/mcp-registry-auth on the domain itself.

The DNS lookup is resolved through two independent resolvers, and they must agree. Both are named here, because which resolvers we ask is the trust model of a claim proved this way:

A record is accepted only when both return the same key material. Where they disagree — during propagation, or where one is serving a stale answer — the claim is refused, and the disagreement is the stated reason. Refusing costs a claimant a retry. Accepting on one resolver would mean a single lagging or compromised answer is enough, and that is not recoverable.

We do not validate DNSSEC. Two resolvers agreeing is not a cryptographic guarantee that a record is authentic; it is corroboration from two parties who would both have to be wrong in the same way at the same moment. So a claim proved through DNS rests on trusting those two resolvers, and a claim proved through the well-known URL rests on trusting the certificate authority system. Two trust roots, and neither of them a proof.

That is stated plainly rather than left for a reader to infer from the wordverified. What is recorded is narrower and checkable: which method proved a claim, against which published key, and when. A reader deciding what one of our claims is worth is entitled to know what it actually rests on, and an unstated assumption is worse than a disclosed weak one.

No claim is being accepted today. The endpoint exists, refuses every submission, and reads, stores and logs nothing. The records are now real, which removes the reason this page used to give for refusing and leaves the harder one: accepting a claim means holding something about a person, and the preconditions for doing that safely are not met yet. Proving control of a domain is not the part that is missing.

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.

We have described working servers in a class that implies they were at fault. On 2026-08-15 we measured how many endpoints in the archive speak a revision of the protocol that our probe does not. Four were recorded under a client-error class — not because anything was wrong with them, but because they correctly refused a handshake from a client speaking an older revision than they support. The protocol removed that handshake; our probe still opens with it.

Two of the four are confirmed. unitecargo.com/api/agent/v1/mcp andunitemfg.com/api/agent/v1/mcp answered a current-revision request in full and declare support for that revision only. Two are inferred rather than confirmed: alltimetables.com/mcp andgridscoot.vercel.app/api/mcp returned a response that the current specification treats as a modern-server signal — and that any server rejecting unknown methods the same way would also return. We are not presenting those two as equally certain, because they are not, and publishing all four as one number would repeat the original error in the opposite direction.

Nobody reported this. We found it by measuring our own record against the current protocol specification, and the four affected records are named above before any of the operators concerned had reason to ask.

A change in what an observation can tell you, from 2026-08-15. The probe now records which protocol revision a server indicates, when the reply makes that available. Earlier observations carry none — the information arrived and was discarded unread, which is what allowed the four records above to stand. So an observation made before that date and one made after are not comparable on this point: the absence of a protocol-revision note on an older record means we were not reading for it, and never means the server did not indicate one. This is recorded here for the same reason as the rate-limiting artifact above. A quiet improvement that changes what the numbers mean is the defect, not the improvement.

Where an observation was made from. Each snapshot records the machine its probes went out from — its vantage. This is not bookkeeping: a server can answer one network and refuse another, and a datacentre address is sometimes blocked where a residential one is not. When that happens the record shows a server as unreachable and the cause is the path, not the operator. The published snapshots span 2 vantages: residential-local, hetzner-nbg1. Rows captured from different vantages are not comparable on this point, and the vantage of every snapshot is shown beside it on the verification page. It is committed to the public archive but is not one of the five fields inside the merkle commitment, so it is not chain-verifiable.

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

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