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 or remote endpoint (+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: no install command, and no remote endpoint |
unverified-publisher |
−8 | No author / owner attribution, and not published under a namespace the official MCP registry verified (by GitHub sign-in or a DNS/HTTP challenge) |
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).
Start test
Scores are read from metadata. The start test checks the server itself: on a schedule, with no credentials, we try it and record what happens.
- Packages (npm and PyPI): we start the package in a disposable container and ask it to list its tools, resources and prompts, within 45 seconds. Each package gets its own container, with no secrets and its own network.
- Hosted servers: we connect to the endpoint the listing publishes and list its tools, within 20 seconds. We use Streamable HTTP, falling back to SSE as the protocol specifies, and connect only to public addresses.
Each attempt records one of four outcomes:
| Outcome | Meaning |
|---|---|
| Verified | It started (or, if hosted, answered) and listed its tools |
| Needs credentials | It asked for something we deliberately withhold: an API key, a login (HTTP 401/403), a payment (HTTP 402). Not a failure |
| Failed to start / didn't answer | It crashed or timed out; the endpoint was gone (404, a domain that doesn't resolve, a server error); or it answered in a way no standard MCP client accepts, such as a tool list it advertises but can't list, or a protocol version it can't negotiate |
| Unsupported | We can't test it here: another OS, a runtime we don't provide (Docker images), a URL with placeholders, or a protocol version our clients don't speak yet. No evidence either way |
"Passed our start test" on the homepage counts listed servers whose latest result is verified. The test runs weekly, re-checking a server after 30 days: 500 packages and 2,000 hosted servers a run.
What it is and isn't. It's a floor on what works, not a verdict. We supply no credentials, so many good servers stop at "needs credentials". "Didn't answer" means it didn't answer then. "Verified" doesn't mean safe to use: a server that starts can still do harm. When a server starts, we also scan its tool descriptions for patterns worth a human look, and note when its set of tools changes between checks.
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.