How we score MCP servers for trust

Every MCP server on VerifyMCP gets a single 0–100 trust score. A 100 means a server passed every verifiable trust check that applies to its type. The number is designed to be honest, reproducible, and explainable down to the individual signal.

A shared core, plus what makes each one different

A package you download and a remote endpoint you connect to are delivered in completely different ways, and they fail in completely different ways. But both speak MCP, and both expose a tool surface an agent has to understand and rely on.

So half of every score is a shared core: the four categories that measure the MCP contract itself, scored by exactly the same checks whichever kind of component you are looking at. The other half is what only that kind of component can be judged on:

• package rubric: supply-chain security and provenance, for npm, PyPI, NuGet, OCI and MCPB components.
• remote endpoint rubric: endpoint security, and the transport it can actually be reached over.

A logical server that ships both (say, an npm package and a hosted endpoint) gets each component scored on the rubric that fits it; the headline score is its best component.

Each half is worth 50%, so both rubrics still add up to 100.

The shared categories are scored from the schema a component actually serves. For a remote endpoint we read that live. For a package there is nowhere to read it from, so we install and run the package in an isolated sandbox and score what it serves there. Every category is always counted: until a verified capture exists, the shared four score 0 and say why, exactly like any other check we cannot confirm.

Stability is the one shared category measured differently on each side, because the underlying risk is different. A remote endpoint can change under everyone connected to it at any moment. A published package version cannot change at all, so what matters there is what changes between versions, which is what you meet when you upgrade.

The principles

Log-weighted signals

Within a category, signals sit on a geometric weight ladder (16 · 8 · 4 · 2 · 1), so the first few wins matter most and each additional one adds less. A heavy check like a clean malware verdict or valid TLS can’t be outweighed by a pile of niceties. This rewards getting the fundamentals right instead of gaming a long checklist.

Critical failures cap the score

Some findings are disqualifying, not gradual. A confirmed-malware verdict, an unpatched critical CVE that has a fix available, or a broken or plaintext-HTTP connection caps the score at 0 regardless of how strong everything else is. A high score has to mean safe. (A critical vulnerability with no published fix, or a mere LLM suspicion of malware, is surfaced but does not cap: you can’t install your way out of an advisory with no fix, and a model’s guess never brands a package failed.)

Only what’s verifiable

We score what we can check from public evidence: registry metadata, the source repository, a live MCP handshake, the TLS certificate, DNS, and, for a published package, one run of it in an isolated sandbox with no credentials so we can capture the MCP schema it serves. We do not judge private behaviour, and we never inspect anything a person installing the package could not see for themselves. That keeps every score reproducible and defensible.

Stable, reproducible findings

Every finding is stored as a stable machine identifier plus its supporting details, not as baked-in prose. That’s what keeps scores reproducible, lets a server page deep-link a finding straight to the fix guide that explains it, and lets us improve the wording of an explanation without re-scoring anything.

The math model

Every signal resolves to a value between 0 and 1, then rolls up by weight, first into its category and then into the total for the component’s scoring track (the two tracks being the two rubrics: installable packages and remote endpoints). There are three kinds of signal value:

• Binary: pass = 1, fail or absent = 0 (e.g. HTTPS enforced).
• Ordinal: a fixed level map (e.g. streamable-http 1.0 › SSE 0.6 › stdio 0.2).
• Log-normalised: unbounded counts like downloads or uptime, with diminishing returns near the top.

A category is the weighted average of its signals, scaled to 100. The track’s total is the weighted average of its categories, unless a critical trigger fires, which forces the whole track’s score to 0:

Category = 100 * sum(w_i * s_i) / sum(w_i)

Total = 0                                        if any critical trigger fires
Total = round(sum(catW * catScore) / sum(catW))  otherwise

Because every unverifiable signal scores 0 while keeping its weight, a server that blocks most of our checks lands low even with nothing provably wrong; the denominator still counts what we couldn’t confirm.

When a server dies

The rubric answers “how trustworthy is this component if it works?” A separate signal, liveness, answers “is it still there at all?” We re-probe every indexed component daily; a component that stops responding walks through a fixed lifecycle before it’s declared dead, so a deploy or a brief blip is never mistaken for a death.

A few things make this conservative on purpose:

• “Unreachable” means a genuine connection failure. A valid handshake, an auth wall, or an endpoint that answers but isn’t MCP all prove the host is up and reset the streak. For a package, unreachable means a confirmed unpublish or 404 in its registry.
• Death is per-component, and terminal. A server as a whole is only marked dead when every one of its channels is dead; a server with one live channel is still alive. Once dead, a component’s score does not recover automatically: even if it starts responding again it stays dead until it is manually reinstated, and it’s dropped from the daily re-scoring queue in the meantime.
• Dead servers leave the directory. They’re hidden from the directory and leaderboard, though their page is retained. Degraded servers stay listed with an amber badge and a “decaying” notice.
• An upstream deletion forces death. If the official MCP registry marks a server deleted, we treat it as dead, but we keep the record (clearly flagged) for reference rather than hard-deleting it.

A worked example

Illustration: not a live reading of any indexed server.

Take an OAuth-protected remote endpoint. Its endpoint security category is fully verifiable from the outside:

That category scores 100 × 29/31 ≈ **94**.

But the same OAuth wall means the unauthenticated probe gets a 401 and can’t enumerate tools, and there’s no scan history at all, so schema quality, stability, and capabilities are all unverifiable, and each scores 0 while keeping full weight. The displayed total lands in the high-20s, with an informational “Unverified: N categories” coverage banner (a note about what we could read, not a grade on the score). Claiming the server and supplying a read-only token turns those three categories from “couldn’t check” into real scores and lifts the number.

Reading a score

On a server’s page each category shows its sub-score and the reasons behind it. Green-band signals are passing; amber signals scored partially; red are failing or unverifiable (which score 0). Every finding links to a fix guide with concrete, copy-pasteable steps.

• 80+ high trust
• 60–79 medium
• below 60 low

Scores refresh as the registry and the servers themselves change (typically daily) so improving a signal is reflected on the next crawl.

Occasionally a score moves because we changed how we score, not because the server changed. Every one of those changes is recorded, in date order, in the scoring changelog.

Frequently asked

How does VerifyMCP score MCP servers? Every MCP server gets a single 0–100 trust score. npm packages and remote endpoints are judged on completely separate rubrics; a 100 means we positively verified every trust check for its type. Signals are log-weighted, any critical failure caps the score at 0, and anything we can’t verify (for example an access-gated endpoint) scores 0 and counts against the score until the owner verifies it.

How are npm packages scored? A package is code you download, so the score leads with verifiable supply-chain (36%) and provenance (24%) signals. Supply chain covers the malware verdict, known CVEs across the resolved production dependency tree, install-script risk and dependency health; provenance covers signed build provenance, a reachable source repo, an OSI licence, maintenance recency and a security policy. The remaining 40% scores the MCP schema the package actually serves, captured by running it once in an isolated sandbox: schema quality and AI usability (25%) and tool coverage (15%), using the same signals as the remote rubric. Both are always counted: until a verified capture exists they score 0 and say why. A clean, well-provenanced npm package with a well-documented captured schema can reach 100. Because malware coverage is npm-first, some non-npm ecosystems reach lower ceilings until we extend the same analysis to them.

How are remote endpoints scored? A remote server is a hosted endpoint you connect to but don’t run, so it’s scored on the connection, the operator and the quality of what it exposes, across five categories: endpoint security (TLS, HTTPS, HSTS, RFC 9728 authorization, DNSSEC), schema quality and AI usability, tool coverage (deterministic checks on the tool definitions themselves), stability, and capabilities (which includes transport verification). Anything we can’t read (usually an auth-gated endpoint) scores 0 and counts against the score; owners can verify ownership to lift it.

What happens to a server’s score if it goes offline? Nothing for the first two days (grace). From day three it’s degraded and its last good score decays; after seven days unreachable it’s marked dead: pinned to 0, hidden from the directory, and it stays dead until manually reinstated even if it comes back. A server is only dead when all of its channels are.

What counts as a good score? Higher is better, and 100 means a component passed every verifiable check that applies to its type. The badge colour bands the number into three tiers: 80 and above is high trust (green), 60–79 is medium (amber), and below 60 is low (red). A component flagged Unverified has not so much earned a low score as blocked or outrun our checks. When the cause is an auth wall, verifying ownership lifts it; when it is a sandbox capture we have not made yet, it is ours to resolve and it clears on its own.

How often are scores updated? We re-crawl the registry and re-probe indexed components daily, so a signal you fix is typically reflected within a day on the next crawl.

Can I pay to raise my score, or buy a better ranking? No. There is no paid tier, sponsored placement, or any way to buy a higher score or a better position in the directory. Every score is an independent estimate derived from public evidence, and the only way to move it is to fix the underlying signal (or, for an auth-gated check, claim the server and supply a read-only token so we can verify what we otherwise can’t read). We never fabricate a passing signal: anything we can’t verify is marked inconclusive and counts against the score rather than being faked into a pass.

Is VerifyMCP affiliated with Anthropic or the server vendors it scores? No. VerifyMCP is an independent project and is not affiliated with, endorsed by, or connected to Anthropic or any of the MCP server operators it scores. Scores are our own independent estimates, not the vendors’ self-assessments.