Data sources
MCP Toplist aggregates Model Context Protocol servers from five active registries. Each registry has its own sync schedule. Cross-registry deduplication uses a SHA256 of the canonical repository URL or package identifier.
| Registry | Cadence | Approx. count | Notes |
|---|---|---|---|
| Twice daily (delta) | ~27,000 | Canonical source maintained by the MCP project. Cursor + updated_since pagination. | |
| Twice daily | ~83,000 | Largest catalog by count. Cursor pagination via JSON API. | |
| Twice daily | ~5,300 | Exposes useCount adoption signal. Page-based pagination. | |
| Twice daily | ~21,000 | Curated catalog. No public API; data extracted from the public sitemap and listing pages. | |
| Twice daily | ~22,000 | Cursor-paginated JSON API. Provides GitHub stars, package registry, and remote transport metadata. |
Live measurements of each registry
The approximate counts above are a snapshot. The registry observatory shows the live catalog size, the time of the last successful sync, a 30-day trend and the known caveats for every registry in this table, refreshed twice daily with the pipeline.
Open the registry observatory →How servers are matched across registries
A canonical key is computed for each server in priority order:
- Repository URL (normalized, lowercased)
- Package identifier (first package in
packages[]) - Server name (fallback)
The SHA256 of the canonical identifier becomes the server's persistent ID. Two registries listing the same GitHub repo collapse to a single entry on MCP Toplist.
Wrong mapping? Missing data?
Email hello@biff.ai with the server name and what should change. Most issues stem from duplicate registry entries that resolve themselves on the next sync.