Some servers on HostedMCP carry a Verified mark. This page explains exactly what the mark measures, so you can decide how much weight to give it.
Verified means a server passed our automated checks, version 2, on its public repository, packages, dependencies, tool descriptions and endpoint. It does not mean a person reviewed the code, and we never run the server on your behalf. Read it as "no obvious problems found in public data", not as a guarantee of safety.
The checks
We run eleven checks, once a week and whenever a listing's README or packages change. Each result keeps its evidence and a link to the public source it came from, so you can check it yourself.
| Group | Check | Weight | Source | What fails it |
|---|---|---|---|---|
| Origin | Source repository | 10 | GitHub | a package with no linked repository, or one we can't reach |
| Origin | Package names the same repository | 5 | npm, PyPI | the package's own metadata points at a different repository |
| Origin | Build provenance | 10 | Sigstore attestations on npm and PyPI | counts only when an attestation exists; its absence is not a finding |
| Origin | License | 5 | GitHub, SPDX | no license, or one that isn't OSI-approved |
| Practices | Maintenance | 5 | GitHub | no commit and no release in the last 365 days |
| Practices | OpenSSF Scorecard | 15 | OpenSSF | below 7 out of 10 earns part of the weight, in proportion to the score |
| Supply chain | Package name | 10 | our list of popular packages | a name one or two letters away from a popular package under another owner |
| Supply chain | Advisories | 15 | deps.dev, OSV | a critical advisory in the package or any resolved dependency of that version |
| Tool safety | Hidden instructions | 15 | tool descriptions, README | text aimed at the model ("ignore previous instructions", <IMPORTANT> blocks), invisible Unicode, or a tool description that points at files like ~/.ssh |
| Tool safety | Destructive tools | 5 | tool annotations | a tool named like delete_*, drop_* or exec* without the destructiveHint annotation |
| Endpoint | MCP handshake | 5 | a live request from us | a remote endpoint on plain HTTP, or one that doesn't answer initialize |
How the score is counted
A check only counts when we have the data for it. A hosted server has no package, so the package, provenance and advisory checks don't apply to it; a repository Scorecard hasn't analysed has no Scorecard result. Skipped checks leave the total, so a server is never marked down for something we couldn't look at.
The score is the weight of the checks that passed, out of the weight of the checks we ran. To be Verified a server needs:
- a score of 80 or more,
- no serious finding (package name, plain HTTP, hidden instructions or a critical advisory),
- at least 60 of the 100 points checked, so a listing with almost no data can't pass by default,
- a public source repository that passed its check.
Each server page lists every check with its result, its evidence, the date it ran and, where Scorecard reports it, the commit it describes. We keep the last ten results per server.
What it doesn't tell you
The checks read public data and make one handshake request to remote endpoints. They don't execute a server's code or audit its logic. A server can pass every check and still do something you wouldn't want, and a well-built server can miss the mark because the data we need isn't published. An official server from the vendor of the product is usually a better signal of trust than this mark.
Before you install a local server, remember it runs with your user's permissions. Read the source, prefer servers published by the product's own company, and give each one a token with the narrowest access it needs. Our MCP security guide goes through this in more detail.
Something wrong?
If a check flagged your server by mistake, claim the listing and tell us, or email legal@hostedmcp.org. If you think a Verified server is harmful, write to the same address and we'll look at it within 72 hours.