How MCP Toplist ranks servers
Every Model Context Protocol server gets a composite score derived from six signals. All are log-normalized so that one large repo doesn't dominate the ranking, and so that older, multi-version, actively-maintained servers can compete on their own merits. Four are supply-side signals about the project itself; two are minor demand-side terms — organic search reach and package-download volume — that nudge, rather than dominate, the result.
Composite score weights
| Signal | Weight | Source |
|---|---|---|
| GitHub stars | ~20% | GitHub REST API, log10-scaled |
| Version count | ~20% | Distinct versions across all registries |
| Release activity | ~20% | Commits in last 30 days + 3× releases in last 90 days |
| Listing age | ~15% | Months since first publish, log10-scaled |
| Organic reach | ~15% | Position-aware organic search impressions, log10-scaled |
| Package downloads | ~10% | npm / PyPI 30-day downloads above a floor, log10-scaled |
Weights are approximate and periodically retuned. The two demand-side signals — organic reach (how often a server's page surfaces in organic search, read position-aware) and package downloads (npm / PyPI install volume) — count only above a floor, and we keep their exact weighting and formulas undisclosed.
How often the data refreshes
Each registry has its own sync job. Rankings reflect the most recent data from every source. See /sources for the full table, and the registry observatory for when each registry last returned new data and how its catalog moved over the last 30 days.
- · Official MCP Registry — twice daily (delta sync)
- · Smithery — twice daily
- · Glama — twice daily
- · mcp.so — twice daily
- · PulseMCP — twice daily
- · GitHub stars and commit signals — twice-daily refresh via the feature builder job
What the score does not measure
- Code quality. The composite score is a popularity and activity signal, not a quality assessment.
- End-user adoption. We fold npm / PyPI download volume in as a minor signal, but it only covers servers that ship a public package — coverage is uneven, so a high-adoption server distributed another way (or a registry usage count like Smithery's
useCount) won't move the score. Treat the downloads term as a partial adoption proxy, not a complete one. - Security or trust.A high score doesn't imply a server is safe to run. Always review the repository before installing.
- Servers without a public repository.Stars and commit activity terms collapse to zero, so closed-source or repo-less servers will rank low even if they're widely used.
- Repositories we can't attribute.Stars and commit activity only count when the linked repository is attributable to the server itself. A repository shared by several listed servers is split between them, a listing that points inside a monorepo gets none of it, and a listing that comes only from a registry with unverified free-form submissions gets none of it either unless the listing itself describes an MCP server — so a product repository pasted into a directory doesn't rank as a server.
Research dataset
We publish a daily-refreshed open dataset of the MCP ecosystem on Hugging Face — the only place our data is available in bulk: every canonical server we track with per-registry membership flags, first-seen dates, transport and setup classifications, plus a daily per-registry growth series. Raw observables only — the composite score and its components are not included. Licensed CC BY 4.0; if you use it in research, please cite mcptoplist.com (a ready-made BibTeX block is on the dataset page).