MCP Trust Index

Methodology

Every number this site publishes can be traced back to a named signal with a stated weight. The figures below are read directly from the code that computes the scores, so they cannot fall out of step with it.

This is not a security score.It measures whether a project looks maintained. A high score does not mean a server is safe to install, and a low score does not mean it is dangerous. Conflating the two would be the easiest way to make this index useless, so the two are kept structurally separate.

The activity & maintenance score

Five signals, summing to 100 points. Each is computed independently and reported with its own explanation on every server page, so you can see which signal earned or cost the points rather than being handed a single opaque number.

recency
35 pts
How recently code was pushed. Full marks within 30 days, decaying linearly to zero at 12 months. An archived repository scores zero regardless of its history.
responsiveness
20 pts
A proxy for whether maintainers keep up with their issue tracker, measured as open issues relative to project popularity. A Phase 1 approximation — real issue close-times replace it later.
cadence
15 pts
Whether the registry entry has been re-published or version-bumped recently, showing the server is still being released rather than merely edited.
community
15 pts
Stars and contributor count, log-scaled so a single very large project does not flatten the rest of the curve.
metadata
15 pts
Completeness and clarity of what the publisher declared: an OSI-approved licence, a real description, and a working repository link.

Why these weights

Recency carries the most weight because it is the least ambiguous signal available: a repository that has not been touched in a year is telling you something concrete, whatever its star count. Community size is capped and log-scaled deliberately — a handful of very famous servers would otherwise flatten everything else into the bottom of the range, and a small, well-kept server is not a worse server.

Issue responsiveness is the weakest signal here and is marked as a proxy: it compares open issues against popularity rather than measuring how quickly issues actually get closed. Real close-time data replaces it once the index has enough history to compute it fairly.

Servers without GitHub data

Not every server declares a GitHub repository, and some point elsewhere or nowhere. Those are marked unverified activity rather than being silently scored as inactive. The signals that depend on repository data score zero because nothing was measured — not because the project is dormant. The distinction is shown on the server page, and you can filter the leaderboard to verified servers only.

Licences we recognise

The metadata signal awards full marks for an OSI-approved licence. The list is a short allowlist of what actually appears on MCP servers rather than the whole SPDX corpus: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, GPL-2.0, GPL-3.0, LGPL-2.1, LGPL-3.0, AGPL-3.0, MPL-2.0, Unlicense, 0BSD. A licence outside it scores partial credit and is flagged for a read, not treated as absent — if something legitimate is missing here, tell us and it gets added.

Heuristic risk flags

Flags are separate from the score and are never folded into it. A well-maintained server can carry flags; a dormant one can carry none. They come from published metadata only — nothing is downloaded, installed or executed.

No licence declared
medium
Without a licence, no one has been granted the right to use, modify or redistribute the code — a legal blocker for commercial adoption, independent of code quality.
Licence is not OSI-approved
low
The project declares a licence we do not recognise as OSI-approved. It may still be perfectly usable, but it warrants a read before adoption.
Package runs an install script
medium
A preinstall/postinstall script executes code on the installing machine before the server is ever run. This is a legitimate and common practice for native builds — and also the most common supply-chain exfiltration vector — so it is flagged for review, never blocked.
Known vulnerability in declared dependencies
high
A public advisory (OSV/GHSA/CVE) matches a package version this server declares. Check whether a fixed version is available.
Repository is archived
medium
The maintainers have marked the repository read-only. No fixes — including security fixes — should be expected.
No code pushed in over a year
low
The project may be finished and stable, or abandoned. The distinction matters for anything you intend to depend on.
No source repository declared
medium
The registry entry points at no public source, so the code behind this server cannot be independently reviewed at all.
Remote endpoint is not HTTPS
high
A plaintext HTTP endpoint exposes everything the agent sends — including credentials and tool arguments — to anyone on the network path.
Description is missing or very short
info
Too little declared detail to judge whether the server's stated purpose matches the access it asks for.

What a flag is and is not

A flag is an invitation to look, never a verdict. An install script is flagged because it is the usual supply-chain exfiltration route — and also because native modules legitimately need one. Both are true, which is exactly why it is surfaced for review rather than scored against. Every flag on every server page carries a caveat saying what it does not imply.

Where the data comes from

  • The official MCP registry — names, descriptions, versions, declared packages and endpoints. Only the latest version of each server is indexed.
  • The GitHub REST API — stars, forks, open issues, licence, archive status, last push and contributor count, for servers whose repository is on GitHub.
  • OSV.dev — public vulnerability advisories matched against declared package versions.

The index refreshes weekly. Scores are stored as a time series with the breakdown and the algorithm version that produced them, so a historical score can always be explained by the weights that were actually in force when it was computed.

Known limitations

  • Vulnerability matching covers declared package versions only, not a resolved dependency tree. No advisory found means no advisory against that version — not that a server is free of vulnerabilities.
  • GitHub's open-issue count includes open pull requests, which slightly inflates the responsiveness proxy for busy repositories.
  • Contributor counts above 100 are reported as a lower bound, because of how the GitHub API paginates them.
  • A server that is finished and stable looks identical to one that is abandoned on the recency signal. That ambiguity is real and is not resolvable from metadata alone.

Corrections

If a record is wrong, stale or misattributed, email contact@klars.ai and it gets fixed. Publishers will soon be able to claim their own servers and request a re-scan directly.

← Back to the leaderboard