How the Record Is Built — Methodology & Limitations

What happens every day

The registry is crawled in full. Every server and every version, page by page, then written as one file per server version and one roll-up for the day. The roll-up is a diff against yesterday: what appeared, what changed, what stopped being listed.
The day is committed. The record lives in version control, so the history is the commit history. A day that was never crawled is a day that is gone, which is why this job retries, has a second attempt twelve hours later, and raises an alarm if no snapshot is recorded within twenty six hours.
Every published artifact is fetched. npm tarballs, Python wheels and sdists, container images layer by layer, and source archives from GitHub. New versions on the day they appear, and older ones on a rolling recheck, because a package can be republished over an existing version number without saying so.
Each artifact is verified, then addressed by its own hash. The SHA-256 of the bytes is the storage key. Identical bytes are stored once however many servers ship them, a stored object cannot disagree with its own address, and bytes that do not match what the publisher declared are never written at all.
The result is compared with what was held before. A hash that changed under a version number that did not is the event this exists to catch.

The shape of it

Five sources in, one content-addressed archive out, with the change events falling out of the comparison in the middle.

Official MCP RegistryDocker catalogue SmitheryClineGitHub npm & PyPI

Daily observation

Historical metadata

Change events

Artifact retrieval

SHA-256 identity

Content-addressed archive

Nothing is deleted. A server leaving a source is recorded as leaving it, not removed from the record.

What is watched for

Republishing. An existing version whose contents changed after publication.
Tag repointing. A git tag that now resolves to a different commit. Every tracked repository is rechecked daily, so this surfaces within a day rather than whenever someone happens to look.
Delisting. A server that was listed yesterday and is not listed today, along with the last state it was in before it went.
Status changes. A server marked deprecated or deleted by the registry, recorded with the date it happened.

Where the listings come from

The official MCP Registry, a GitHub search for repositories that never registered anywhere, and the catalogues other people publish: Smithery, Docker's curated catalogue, Cline's marketplace, npm and PyPI. Each is enumerated daily and each day's listing is kept, because a catalogue is a current-state publisher too, and its opinion on a given day is not recoverable afterwards either.

Badges on a server say who made the claim. Presence in the official registry, in Docker's catalogue, or a verified mark from Smithery are different assertions by different parties, and none of them is ours.

What this cannot tell you

Worth stating plainly, because a record that overstates itself is worth less than one that does not.

Coverage of other catalogues is partial and the gap is recorded. Smithery caps any single query at 500 rows against a catalogue of about 14,500, and npm keeps serving pages long after it has stopped returning anything new. Where a source will not show us everything, the shortfall is stored beside the listing rather than rounded away.
The archive starts when it started. Nothing here reaches back before the first crawl, and nothing ever will. That is the entire reason it runs daily.
A hosted server has no artifact to hold. Roughly half the registry is servers you connect to rather than packages you install. Their listings are recorded; there are no bytes to verify.
A changed hash is a fact, not a verdict. It means the bytes moved under a fixed version. Whether that was an accident, a rebuild, or an attack is a question this record lets you ask, not one it answers for you.

Who runs it