Registry coverage
Every index of AI-agent packages is built on a discovery surface, and every discovery surface misses things. We publish ours: how many packages we have scanned, how many we track but have not scanned, how many of them the official registry has a record of, and the measured reasons for each difference. We publish the gap in the other direction too: the first-party packages we know about and have not reached yet.
This is a page about coverage, not about quality. Nothing here ranks or grades the packages it names.
What we can count today
Every figure below is read live from our own API every time this page renders. Three of them are different sizes of the same registry and the differences are the point: scanned is what we have actually run scanners against, tracked is everything we know exists, and the middle figure is the distance between them. The first two plus the middle one add up exactly.
- Packages we have scanned
- 44,860Scanned by our pipeline at least once. This is the coverage claim, and it is the smallest of these three numbers on purpose.
- Tracked but never scanned
- 2,680Tracked in our registry, never scanned: 1,448 queued behind a first scan, and 1,232 we cannot acquire an artifact for at all.
- Packages we track
- 47,540Every package we hold a record of, scanned or not. 46,710 of them are browsable; the difference is packages delisted or removed upstream, which we keep a record of but do not list.
- Carrying registry attestation
- 3,249Published under a namespace the publisher proved they own in the official MCP registry, or read by us from a first-party source.
- Listed, nothing attests
- 43,461No official-registry namespace and no first-party source claims them. We publish each scanner's findings for these and withhold the composite verdict.
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. The two attestation figures are counted over the packages our registry lists, which is a slightly smaller set than the packages we track: we keep a record of packages that were delisted or removed upstream, and do not list them.
Packages in our registry that nothing attests to
These are packages in our registry for which no official-registry namespace and no first-party source exists. Many are in wide use. Their absence from the official registry is a fact about the registry’s coverage, not about them.
Browse all 43,461 unclaimed packages in the registry
We publish no composite verdict for these packages: each shows what each scanner reported and nothing more, and the composite 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.
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(one-off audit, 25 July 2026)
Every number in this section is from a single audit we ran on 25 July 2026 and has not been re-measured since, unlike the counters above, which are live. On that date we checked our own discovery surface against 39 known first-party vendor MCP servers, and 32 of them resolved to a live repository. Four causes came out of it, each with a number attached.
- 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.
- The search cap made the sample thin and recency-biased.
topic:mcp-serveralone 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. - 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 39 first-party packages we now track, 11 ship only on those channels: the count is computed from the table below, not asserted.
- 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 39 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 17 of them today.
| Repository | Expected registry namespace | Language | Distribution | In our registry |
|---|---|---|---|---|
| microsoft/mcp | io.github.microsoft | C# | oci, github-release | No name match yet |
| GoogleCloudPlatform/cloud-run-mcp | io.github.googlecloudplatform | JavaScript | npm | No name match yet |
| elastic/mcp-server-elasticsearch | io.github.elastic | Rust | crates | No name match yet |
| cloudflare/mcp-server-cloudflare | io.github.cloudflare | TypeScript | npm | No name match yet |
| awslabs/mcp | io.github.awslabs | Python | pypi | No name match yet |
| stripe/ai | io.github.stripe | TypeScript | npm | No name match yet |
| redis/mcp-redis | io.github.redis | Python | pypi | No name match yet |
| JetBrains/mcp-jetbrains | io.github.jetbrains | JavaScript | npm | No name match yet |
| modelcontextprotocol/servers | io.github.modelcontextprotocol | TypeScript | npm | No name match yet |
| supabase/mcp | io.github.supabase | TypeScript | npm | No name match yet |
| apify/apify-mcp-server | io.github.apify | TypeScript | npm | No name match yet |
| heroku/heroku-mcp-server | io.github.heroku | TypeScript | npm | No name match yet |
| twilio-labs/mcp | io.github.twilio-labs | TypeScript | npm | No name match yet |
| slackapi/slack-skills-plugin | io.github.slackapi | Python | pypi | No name match yet |
| googleworkspace/developer-mcpUpstream archived | io.github.googleworkspace | JavaScript | npm | No name match yet |
| googleworkspace/dev-assistUpstream archived | io.github.googleworkspace | TypeScript | npm | No name match yet |
| taylorwilsdon/google_workspace_mcp | io.github.taylorwilsdon | Python | pypi | No name match yet |
| hashicorp/terraform-mcp-server | io.github.hashicorp | Go | oci, github-release | Name match in our registry |
| hashicorp/vault-mcp-server | io.github.hashicorp | Go | oci, github-release | Name match in our registry |
| github/github-mcp-server | io.github.github | Go | oci, github-release | Name match in our registry |
| microsoft/playwright-mcp | io.github.microsoft | TypeScript | npm | Name match in our registry |
| Azure/azure-mcpUpstream archived | io.github.azure | C# | oci, github-release | Name match in our registry |
| Azure/mcp-kubernetes | io.github.azure | Go | oci, github-release | Name match in our registry |
| googleapis/mcp-toolbox | io.github.googleapis | Go | oci, github-release | Name match in our registry |
| containers/kubernetes-mcp-server | io.github.containers | Go | oci, github-release | Name match in our registry |
| grafana/mcp-grafana | io.github.grafana | Go | oci, github-release | Name match in our registry |
| mongodb-js/mongodb-mcp-server | io.github.mongodb-js | TypeScript | npm | Name match in our registry |
| getsentry/sentry-mcp | io.github.getsentry | TypeScript | npm | Name match in our registry |
| neo4j-contrib/mcp-neo4j | io.github.neo4j-contrib | Python | pypi | Name match in our registry |
| docker/mcp-gateway | io.github.docker | Go | oci, github-release | Name match in our registry |
| sooperset/mcp-atlassian | io.github.sooperset | Python | pypi | Name match in our registry |
| paypal/agent-toolkit | io.github.paypal | TypeScript | npm | Name match in our registry |
| chroma-core/chroma-mcp | io.github.chroma-core | Python | pypi | Name match in our registry |
| makenotion/notion-mcp-server | com.notion | TypeScript | npm | Name match in our registry |
| slack-samples/bolt-js-slack-mcp-server | io.github.slack-samples | JavaScript | npm | Name match in our registry |
| atlassian/atlassian-mcp-server | io.github.atlassian | JavaScript | npm | Name match in our registry |
| nspady/google-calendar-mcp | io.github.nspady | TypeScript | npm | Name match in our registry |
| piotr-agier/google-drive-mcp | io.github.piotr-agier | TypeScript | npm | Name match in our registry |
| korotovsky/slack-mcp-server | io.github.korotovsky | Go | oci, github-release | Name match in our registry |
How these numbers are produced
- The scanned, never-scanned and tracked figures are three named fields on our registry statistics endpoint, read fresh on every render of this page. We do not count them by walking pages of packages, so none of them is a sample and none can drift from what the API says.
- The two attestation figures are counts our backend returned for a filtered query: the same query the link above sends you to, so the number here and the number you land on are the same number, not two things that ought to agree.
- The attestation tier itself is computed by our backend from the official-registry namespace and the source a package was read from. This page reads it and never recomputes it. Where a figure is absent, the counter says so instead of showing a zero.
- We do not publish a count of undistributed packages. Our registry withholds that tier from its listing entirely, so any figure we showed would be a publication policy dressed up as a measurement.
- The audit section is dated because it is frozen: those numbers were measured once, by hand, on 25 July 2026. Everything else on this page is live.
- The first-party list is the operator-curated allowlist in this repository, resolved against the GitHub API on 25 July 2026. Adding a vendor is a one-line change to that file, and a test fails if this page and the file ever disagree.
- The “in our registry” column is a name search against our own listing, matched on the exact package name. A package we scanned under a different published name will read as no match, so the gap we report is an upper bound: the error runs against us, on purpose.
- We are not the official registry and this page does not speak for it. It reports what our discovery surface can see, measured on the dates given.