Methodology

Coverage first, not a fake score

About 43% of the catalog publishes no code — it’s a hosted endpoint, not a package. A naive 0–100 score would read “no known vulnerabilities” on those servers as “safe,” rating the opaque half of the ecosystem green. Instead we assess each server as a matrix of dimension × coverage, and make not applicable a first-class state. The headline is categorical and carries a coverage clause (“assessed on 3 of 5 dimensions”) — we do not publish a single composite number until it can be calibrated and its methodology published here.

The dimensions

• ProvenanceWhether the server's origin is independently verifiable — for example a published source repository versus an unverifiable hosted endpoint.
• Supply chainWhether the published package and its dependencies carry known vulnerabilities. Applies only to servers that ship installable code — there is nothing to scan on a hosted remote.
• MaintenanceSignals that the server is actively maintained — including its registry status and the liveness of its source repository.
• Manifest integrityWhether the tools the running server exposes match its claims, and whether they change over time. This live-manifest signal is rolling out — see What's next.
• Behavioral trustThe uptime and reputation of a live endpoint. Applies to remotes; there is no hosted endpoint to observe on a package-only server.

The states

• Pass — Assessed and clear.
• Review — Assessed, with something worth a closer look.
• Fail — Assessed and a blocker was found.
• Pending — Applies to this server, but the source hasn't reported yet.
• Not applicable — There is nothing to assess — e.g. no package to scan on a remote-only server. Neither a gap nor a failure.

Sourced and reproducible

Every verdict cites the sources that concluded it, with an “as of” timestamp. We land each source’s raw response and compute off our own copy — never reading a third party live on the page — so every verdict is attributable, reproducible, and retractable. We sync from the official MCP registry and enrich it — we don’t compete with it.

Reading a verdict

These are automated assessments formed from sourced, timestamped data — signals to inform your own review, not guarantees, certifications, or accusations. Coverage is uneven and is stated on every verdict. Think a verdict is wrong or out of date? Let us know and we’ll review it.

What’s next

More sources conclude the pending cells without changing the model — package vulnerability data, and a live manifest probe that records each server’s tools over time to surface changes and rug-pulls. Coverage grows; the verdict stays honest about what it has and hasn’t seen.