The components
Each server is scored on five components. Every one is shown on the server's own page with its weight and the reason for its value, so you can disagree with any individual judgement.
| Component | Weight | How it is measured |
|---|---|---|
| Maintenance | 30% | Full marks for a commit within 30 days, decaying linearly to zero at two years. An archived repository scores zero outright. |
| Adoption | 20% | GitHub stars and npm weekly downloads, each on a log curve (stars saturate at 2,000; downloads at 20,000) and averaged over whichever are available. Log scale because 10 → 100 users means more than 10,000 → 10,100. |
| Transparency | 20% | Four equal checks: a public source repo, a declared license, documentation we could fetch, and a tool list the server would disclose. |
| Provenance | 15% | Full marks for an official reference implementation, or for a package whose declared repository matches the registry entry. Half marks for a fork. Zero if there is no repo, or if the package and registry disagree about where the code lives. |
| Packaging | 15% | Whether a stdio server pins a version (an unpinned install resolves to whatever is latest at launch), or a remote server documents its authentication. Zero for a deprecated package or an entry with nothing installable. |
The formula
Components are normalised to 0–1, multiplied by their weight, and divided by the weight actually measured — not the total:
score = round(100 × Σ(value × weight) / Σ(weight of measured components)) grade = A ≥ 80 · B ≥ 60 · C ≥ 40 · D < 40
Missing data is never a penalty
That denominator is the important part. If we could not resolve a server's repository, its maintenance component is excluded rather than scored zero — otherwise the score would punish servers for our own gaps in coverage. When less than half the weight is measurable we show no score at all instead of a misleading one.
What this does not measure
It is not a security audit. Nothing here inspects the code. A server can score an A and still be malicious: a well-maintained, widely-installed, properly-licensed package is exactly what a competent attacker would publish. The score measures whether a project looks looked after — not whether it is safe to trust with your credentials.
It also cannot see runtime behaviour. What a server does with the data you send it is not observable from a registry entry, so read the tool list and the documentation before connecting anything that holds real credentials.
Where the inputs come from
- Repository metadata: GitHub GraphQL API, daily.
- Package metadata: the npm registry, daily.
- Tool lists: read from the live server over MCP, daily.
- Everything else: the entry as published in the official MCP Registry.
Think a component is weighted wrong? Tell us — the formula lives in src/lib/health.ts and is open to argument.