How the Top-MCPs score is computed
Every MCP detail page shows a single 0–100 score. The score is a weighted average of seven verifiable inputs. Nothing on that list is a subjective judgement — each input is a fact you can check in under a minute against the MCP’s GitHub repo, npm listing, or record on this site.
This page documents the formula in full so the score is reproducible and auditable. If we change the rubric, the version identifier bumps. The current version is 2026-04.
The seven inputs
Each sub-score is normalized to a number between 0 and 1, then multiplied by its weight. Weights sum to 100, so the final score is a straightforward 0–100.
| Input | Weight | Source |
|---|---|---|
| Popularity | 25% | GitHub stars (fetched at build time from the public API). |
| Maintenance | 20% | Date of the latest commit on the default branch (GitHub API). |
| Provenance | 15% | Derived: the MCP is marked Official if its GitHub owner is a first-party service vendor (e.g. `github/github-mcp-server`) or carries the legacy Official label. |
| License | 10% | SPDX license identifier in the MCP record. |
| Install ergonomics | 10% | Combination of the MCP record’s `setupTime` field and its `authModel` field. |
| Client breadth | 10% | Count of entries in the MCP record’s `compatibleWith` field. |
| Verification freshness | 10% | The `lastVerified` date on the MCP record — when we last confirmed the install snippet works. |
Input definitions
Popularity — weight 25%
Source. GitHub stars (fetched at build time from the public API).
Scale. Log-scaled: 0 stars → 0.0, 100 → 0.5, 1 000 → 0.7, 10 000 → 0.9, 50 000+ → 1.0. Clamped at 1.0.
Why. Stars are an imperfect signal but the best widely-available proxy for "other people found this useful." Log scaling keeps a 50× difference in stars from swamping every other input.
Maintenance — weight 20%
Source. Date of the latest commit on the default branch (GitHub API).
Scale. <30 days → 1.0, 30–90 days → 0.8, 90–180 days → 0.5, 180–365 days → 0.2, >365 days → 0.0. Unknown commit date → 0.3 (neutral).
Why. A server that has not shipped a commit in a year is much more likely to be broken against the current MCP spec. An unknown date is treated as unknown, not dead.
Provenance — weight 15%
Source. Derived: the MCP is marked Official if its GitHub owner is a first-party service vendor (e.g. `github/github-mcp-server`) or carries the legacy Official label.
Scale. Official → 1.0, community / unknown → 0.5.
Why. An MCP maintained by the service it connects to (GitHub’s own GitHub MCP, Stripe’s own Stripe MCP) is materially less likely to break on API changes than a third-party wrapper. Community MCPs are not penalized — they receive the neutral 0.5.
License — weight 10%
Source. SPDX license identifier in the MCP record.
Scale. MIT / Apache-2.0 / BSD-* / ISC / MPL-2.0 → 1.0; GPL / AGPL / LGPL → 0.7; proprietary / unknown → 0.3.
Why. Permissive licenses are friendliest to the "drop it into my project" use case these MCPs are built for. Copyleft still gets most of the credit; unknown / proprietary gets only partial credit because it carries real downstream risk.
Install ergonomics — weight 10%
Source. Combination of the MCP record’s `setupTime` field and its `authModel` field.
Scale. setupTime ≤ 2 min AND no auth → 1.0; ≤ 5 min with no/api-key auth → 0.8; ≤ 10 min → 0.5; otherwise 0.3.
Why. A two-minute install with no credentials is strictly easier than a ten-minute install with an OAuth dance. This sub-score exists to reward MCPs that respect a builder’s time.
Client breadth — weight 10%
Source. Count of entries in the MCP record’s `compatibleWith` field.
Scale. 5+ clients → 1.0; 3–4 → 0.7; 2 → 0.5; 0–1 → 0.2.
Why. MCPs that work across Claude, Cursor, VS Code, Zed, and the rest of the ecosystem are more portable. A single-client MCP is not useless, but it is less versatile.
Verification freshness — weight 10%
Source. The `lastVerified` date on the MCP record — when we last confirmed the install snippet works.
Scale. <90 days → 1.0; 90–180 days → 0.6; 180–365 days → 0.3; >365 days → 0.0.
Why. The install snippets here are only useful if they still work. A stale verification date is a quality signal about our own work, not the MCP, and it is rewarded / penalized in the score accordingly.
Worked example — Filesystem
At the time of writing, the Filesystem MCP (/mcp/filesystem) scores 100. The breakdown:
| Input | Raw | Weight | Contribution |
|---|---|---|---|
| Popularity (48k stars) | 1.00 | 25 | 25.0 |
| Maintenance (commit within 30 days) | 1.00 | 20 | 20.0 |
| Provenance (official Anthropic repo) | 1.00 | 15 | 15.0 |
| License (MIT) | 1.00 | 10 | 10.0 |
| Install ergonomics (2 min, no auth) | 1.00 | 10 | 10.0 |
| Client breadth (5+ clients) | 1.00 | 10 | 10.0 |
| Verification freshness (< 90 days) | 1.00 | 10 | 10.0 |
| Total | 100 | ||
What the score is not
The score is not a user rating. We don’t collect reviews, and the SoftwareApplication JSON-LD on MCP pages deliberately omits aggregateRating. Emitting a fabricated rating without real reviews would violate Google’s structured data policy and — more importantly — it would not tell you anything true.
The score is also not an endorsement. A score of 87 means seven verifiable inputs combined to that number given the current rubric. The inputs and the math are on this page; form your own judgement.
Changes
Rubric changes are versioned. When a change ships, the rubricVersion field on each score bumps, and every MCP’s cached score is recomputed on the next build. The current version is 2026-04.