Registry coverage

What we can count today

Packages we have scanned

749Registry-wide, every package type, all time.

Carrying registry attestation

Not yet measuredOur packages API does not publish an attestation tier per package yet, so we have nothing to count. This is a gap in what we measure, not a measurement of zero.

Scanned, nothing attests

Not yet measuredOur packages API does not publish an attestation tier per package yet, so we have nothing to count. This is a gap in what we measure, not a measurement of zero.

Coverage delta

Not yet measuredOur packages API does not publish an attestation tier per package yet, so we have nothing to count. This is a gap in what we measure, not a measurement of zero.

Attestation means one of two things, both of them acts by someone other than us: the package is published under a namespace its publisher proved they own in the official MCP registry, or we read it from a first-party source directly. We read that classification from our packages API; we never compute it here, because a second definition of “attested” published under the same word would be worse than none.

Packages we scanned that nothing attests to

These are packages our scanners have run against, for which no official-registry namespace and no first-party source exists. They are in wide use. Their absence from the official registry is a fact about the registry’s coverage, not about them.

We publish no composite verdict for these packages. Each one shows what each scanner reported and nothing more, and the composite column reads Unrated. A per-scanner finding is a checkable statement about what a tool reported; a single aggregate verdict is a judgement about someone’s work, and we do not publish one about a publisher who never engaged with us. Upstream stars, language and the per-scanner rollup are not carried on our packages listing yet, so those cells read “Not published” rather than showing a zero we did not measure.

No findings does not mean no risk. Nerlo aggregates automated scanner output; automated scanning is one layer of defence, not a substitute for review.

Why these are missed

We audited our own discovery surface on 25 July 2026 against 39 known first-party vendor MCP servers. 32 of them resolved to a live repository. Four causes came out of it, each with a number attached.

1. Discovery ran on self-assigned topics. Of the 32 repositories that resolved, only 13 carried the GitHub topics our crawler searched on — 19 of 32 (59%) were unreachable at any page depth. A topic is a label a publisher may or may not add; it is not an index.
2. The search cap made the sample thin and recency-biased. topic:mcp-server alone held 21,625 repositories when we measured. One crawl keeps at most 500 of them, ordered by most recently updated — 2.3% of that one topic, weighted toward whatever was pushed to last. A stable, finished package sinks out of reach precisely because it is stable and finished.
3. Package-registry crawling covered npm, PyPI and crates only. Servers shipped as container images or GitHub release binaries are invisible to all three. Of the 29 first-party packages we now track, 10 ship only on those channels — the count is computed from the table below, not asserted.
4. No authoritative first-party index was consumed at all. Until 25 July 2026 every source we crawled was a search over self-described metadata. We now read the official MCP registry feed directly and keep the operator-curated first-party list below, whose entries are keyed by numeric repository id so a rename cannot drop one silently.

First-party packages we have not matched

The gap runs both ways, and this is the half that costs us something. These 29 packages are first-party servers from named vendors — attested by construction, because we read them from a source the vendor controls. Our registry holds no package of the same name for 23 of them today.