How MCP Rating scores servers
We publish our scoring method in full so you can judge it for yourself. Scores are automated estimates computed from public metadata — not certifications, audits, or guarantees.
Every server gets two independent scores: a Quality score (how good and maintained it is) and a Safety score (supply-chain risk signals). They're separate on purpose — a popular server can still carry safety flags, and a safe server can be low-quality.
Quality score (0–100)
A weighted blend of five signals. Each is scored 0–100, then combined by weight:
| Signal | Weight | What it measures |
|---|---|---|
| Popularity | 30% | GitHub stars (60%) + weekly downloads (40%), log-scaled against the index's 95th percentile so a few runaway projects don't flatten everyone else. |
| Freshness | 20% | Days since last activity: ≤7d → 100, ≤30d → 80, ≤90d → 60, ≤180d → 40, ≤1y → 20, older → 5. |
| Completeness | 20% | Description (+25), license (+20), install command (+30), README/description (+25). |
| MCP Compliance | 20% | Detected tools (+35), resources (+20), prompts (+15), and explicit MCP tagging in GitHub topics / npm keywords (+30). |
| Community | 10% | Forks (60%) + open-issue activity (40%), capped. |
The overall score is the weighted sum, Σ(signal × weight). The per-signal breakdown is shown on every server page, so you can always see exactly where a score comes from.
What Quality does not mean: it is not a security review, and a high score does not certify that an entry is even an MCP server (see the note below).
Safety score (0–100)
A heuristic supply-chain signal — higher is safer. Every server starts at 100, and we subtract a penalty for each risk flag detected from already-crawled metadata:
| Flag | Penalty | Meaning |
|---|---|---|
deprecated |
−30 | Publisher marked the package deprecated |
install-script-risk |
−30 | Install uses a curl | bash-style shell pipe |
archived |
−25 | Source repository is archived |
abandoned |
−25 | No activity for over a year |
possible-typosquat |
−20 | Name closely resembles a popular package |
no-repository |
−15 | No public source to inspect |
stale |
−10 | No activity for over 6 months |
no-license |
−10 | No license declared |
no-install-command |
−8 | Can't tell how it's run |
unverified-publisher |
−8 | No author / owner attribution |
low-adoption |
−5 | Effectively no usage signal |
Bands: safe ≥ 80 · caution 50–79 · risk < 50.
What the Safety score is — and isn't: it's a supply-chain risk screen built from public metadata (maintenance, license, provenance, install shape) — not a code analysis, vulnerability scan, or security audit. It flags servers worth a closer look before you run them; a clean score means "no obvious red flags", not a guarantee. To actually run an untrusted server safely, see the MCP Gateway (sandbox + audit trail).
Why a non-MCP repo can still show a score
Because Quality weights MCP Compliance at only 20%, a very popular general repository that isn't an MCP server can still score moderately on popularity, freshness, and completeness alone. The tell is the MCP Compliance signal: a 0/100 with ".well-known/mcp not detected" and no tools/resources/prompts means the entry is not a verified MCP server — treat it as a raw source match, not an endorsement. We now filter these out: entries from broad GitHub scrapes with no MCP signal are hidden from listings, and new ones are gated at ingestion.
Limitations & data quality
We'd rather you trust the numbers because you know their edges. The honest caveats:
- A low or
0/100MCP Compliance score usually means tools weren't introspected — not that the entry is non-MCP. We only record tools, resources, and prompts when a crawl captured them; many real servers (especially ones listed in the official registry by name) show low compliance simply because we haven't connected and inspected them yet. Read it as "unverified", not "not MCP". - Scores can lag a crawl. Quality and safety are recomputed in a separate pass, so freshly-crawled servers may briefly show low or zero scores until that pass runs.
- Safety is heuristic. It reads metadata, not code — useful signal, not a guarantee, and the absence of flags doesn't certify a server is safe.
- The index is precise but not perfectly representative. Published packages (npm) are far easier to crawl than the long tail of un-packaged GitHub repos, so npm is over-represented and raw-GitHub servers under-represented relative to the true ecosystem; Docker is under-crawled. PyPI and remote track reality closely.
- A small number of non-MCP entries may remain. We hide the clear false positives (broad GitHub scrapes with no MCP signal), but the npm / PyPI / Docker long tail may still contain a few entries that aren't really MCP servers. If you spot one, the MCP Compliance signal is the tell.
- "Remote" uses a strict definition. We classify roughly 10% of servers as web-reachable and count only those we can actually reach over the network; broader, self-reported definitions elsewhere report higher (~19%).
- Data is continuously updated, not real-time. Stars, downloads, and freshness reflect the most recent crawl, not the current instant.