How this data is verified

“Verified” is the whole pitch, so it has to be checkable. This page is the exact process every row goes through.

The pipeline

• Discovery from the official MCP registry API and community seed lists (URL pointers only; every field re-derived from primary APIs).
• Deduplication: URL canonicalisation plus fork/mirror clustering, so the same server never counts twice.
• Collection through documented public APIs only — the MCP registry, GitHub REST, npm and PyPI — with rate limits honored and an identifying User-Agent.
• Liveness verification of every entry at snapshot time.
• Computed fields (maintenance status, license clearance, auth shape, install method) derived deterministically from the collected metadata.
• LLM-assisted categorisation and extraction, validated against allow-lists and hand-checked on a random sample; a field is re-run rather than shipped if the sampled error rate exceeds 10%.
• Cross-review: every published document is reviewed by a different model family than the one that drafted it, and the review is logged.

What we never do

• No HTML scraping — API endpoints only, robots.txt respected.
• No personal data beyond the public org/handle already attached to a repository.
• No login-walled or paywalled sources.
• No invented values: a field we could not verify ships as an explicit null.

Sources

• Official MCP registry API — canonical server identity and package coordinates.
• GitHub REST API — repository metadata, SPDX license, activity signals.
• npm and PyPI registry APIs — package existence, versions, publish dates.
• Community awesome-lists — discovery seeds only, credited in the SOURCES.md that ships in the pack; every field re-derived from the APIs above.

Freshness

• The pipeline is fully scripted and re-runs monthly; each snapshot is dated and the changelog records what moved. Staleness is treated as a defect, not a fact of life.