Every MCP directory, every "browse servers" page, every agent that discovers tools at runtime reads from the same place: the Model Context Protocol registry. I pulled a snapshot of it on 4 September 2026 — 25,125 servers — and ran an integrity audit over the whole thing.
The interesting part isn't what I found. It's the number I nearly reported.
What's actually in there
25,125 servers
24,863 active · 262 deprecated
904 servers (3.6%) share a description identically with another server
1,252 (4.98%) are near-duplicates of each other at Jaccard >= 0.7
12 records repeat a name (see the correction below)
0 are identical across every field the audit evaluates
That last line is the one that matters, and I'll come back to why.
The number I nearly led with
My own tool's summary says this:
"schema_issues": 101383
A hundred thousand schema issues in a registry of twenty-five thousand servers. That is a headline. It is also, as reported, meaningless.
Every one of those 101,383 is a missing_field on an optional field — repository, websiteUrl, packages. The audit infers the majority type of each field across the corpus and flags records that omit it, which is the right behaviour for a dataset where fields are mandatory and the wrong framing for a registry where they aren't.
What's true underneath it is duller and more useful:
title present in 14,384 of 25,125 (10,741 have none)
remotes present in 13,866 of 25,125 (11,259 have none)
So: a bit under half the registry has no title, and a bit under half declares no remote. That's a completeness observation about a young registry, not a corruption finding. "101,383 schema issues" would have been the more shareable sentence and it would have been wrong.
Why "0 identical across every field" is the real result
The audit separates near-duplicate clusters into two kinds: records that match on every evaluated field, and records that share a text stem but differ elsewhere.
In the MCP registry, 487 clusters covering 1,252 servers come back as near-duplicates on description. Zero of them are identical across every field. They're servers doing similar things, described similarly — A Model Context Protocol server for X repeated across many X — with different names, versions and packages.
Which is exactly what you'd expect from a registry, and exactly what a naive duplicate count would report as a 5% redundancy problem.
This is a general failure, not an MCP one
I hit the same gap measuring benchmark datasets, which is what the tool was written for.
Spider's training split: a naive text-similarity pass reports 77 duplicate clusters. Only 8 are real. The other 69 share a question stem while differing in the reference SQL, the database, or both — one phrasing deliberately reused against different schemas. Reporting the raw count overstates by roughly 9x.
BIRD-CRITIC: 4 clusters flagged, 1 genuine. Overstated by 4x.
Same shape every time. The obvious implementation of a duplicate check counts questions that look alike. The thing you actually care about is records a model could bank the same answer twice for, which requires the answer to match too.
Cross-split contamination has the identical problem. Counting identical questions between Spider's train and dev splits says 6 dev items are contaminated. Additionally requiring the reference SQL to match says 2, out of 1,034 — and both are trivial SELECT count(*) questions landing on coincidentally same-named tables in entirely different databases. Reporting the first number would have framed it as three times worse than it is.
What this doesn't say
The audit uses MinHash-LSH above 3,000 records, and LSH offers no recall guarantee, so the duplicate counts here are lower bounds. Every report states which method produced it.
Similarity is computed over the description field only. The snapshot is from 4 September 2026 and the registry has grown since. Correction, added after publishing. I originally wrote that "12 servers share a name" was worth the registry looking at. It isn't, and I should have checked before saying so.
The registry stores one row per version. Querying the live API: a 100-row page contains 62 distinct names, 24 of which recur — ac.inference.sh/mcp appears four times at 1.0.0, 1.0.1, 2.0.0 and 2.0.1, all active. A repeated name is the data model, not a collision.
Which makes this the second raw number in the same audit that meant something other than what it looked like, in a post arguing that raw numbers mean something other than what they look like. The snapshot I measured appears to have been reduced to one row per name already, so the 12 are worth understanding before they are worth reporting — and I have not done that work.
I'm not claiming the MCP registry has a quality problem. I'm claiming it now has a measured baseline, which it didn't before, and that the first number my own tool handed me would have misrepresented it.
Run it yourself
Pure standard library except for fetching:
git clone https://github.com/ashishsinha1602/dataset-integrity-audit
cd dataset-integrity-audit
pip install datasets
python audit.py prep --data mcp-latest.jsonl \
--text-field description --answer-field name --group-field _status
prepared/REPORT.md gives you the table. Point --text-field and --answer-field at any two columns and it works on any dataset — there's a hosted version if you'd rather not install anything.
Repo: github.com/ashishsinha1602/dataset-integrity-audit, MIT. Every number above is in prepared/ as committed JSON, so you can check any of them without re-running anything.
If there's one thing to take from this: when a duplicate check hands you a big number, find out how many of those records are identical everywhere before you quote it. On three different corpora that ratio has been between 4x and 9x, always in the direction that makes the problem look worse than it is.
Top comments (1)
The correction is the most useful part of this audit. A registry that stores versions needs at least three separate identity notions: package/version rows, logical server names, and callable endpoints. Duplicate detection across the wrong one will manufacture collisions or hide abandoned copies. I would publish those denominators beside every count, plus the snapshot hash and normalization code, so the next audit can distinguish actual registry drift from a changed reduction step.