On this page
MCP servers are scored on four public checks - authentication, maintenance, known CVEs and transport safety - and every server in the directory carries the resulting A–D trust grade. It is an assessment from public signals only, not a penetration test or a code audit. It tells you where a server sits before you invest time in your own review.
The four checks
Each server is checked on four things. Every check has a few bands, from full marks down to nothing, and the grade comes from the combined result. Authentication counts the most, maintenance and known CVEs come next, and transport safety counts a little less.
| Check | Full marks | Partial | Nothing |
|---|---|---|---|
| Authentication | Scoped, revocable auth (OAuth 2.1 or a token with scopes) is the default, not an opt-in flag. | Auth is off by default or coarse (one all-scopes token), or only an unscoped API key in a config file. | No authentication at all. |
| Maintenance | A commit or release in the last ~60 days and more than one active maintainer. | Recent activity from a single maintainer, or last activity 60–180 days ago. | No activity for more than 180 days. |
| Known CVEs | No advisories, or every past CVE patched within 30 days of disclosure. | Past CVEs patched slowly (30–90 days), or an open advisory with a documented mitigation. | An open, unpatched advisory with no mitigation. |
| Transport safety | Transport fits its exposure, HTTP options use TLS, and nothing shells out on untrusted input. | stdio-only with no shell-out (fine for local use), or it shells out to helper binaries, or serves HTTP without enforced TLS. | Shells out on model-controlled input, or uses a plaintext remote transport. |
What the grades mean
- A - strong on all four checks. At most one gap, such as a coarse token or a closed-source server whose update cadence we can't verify.
- B - solid overall, with gaps in one or two checks.
- C - a real weakness, such as no authentication, an unsafe default transport, or an unofficial way into your own account at another platform, that you need to work around before you rely on it.
- D - serious problems: for example an open, unpatched CVE, no maintainer activity, or several checks with nothing earned. Look for an alternative.
When the platform is the risk
Some servers act on your own account at another platform, such as your WhatsApp number or your Garmin login, by a route that platform doesn't offer to outside software: a linked-device bridge, a login that pretends to be the platform's app, a private API or copied browser cookies. When that's the case, we cap the grade at C, however well the server does on the four checks. A well-built bridge can still get your account blocked, and that has nothing to do with build quality.
The four checks are still scored as usual, and the trust meter still shows what each one earned. The listing also gets one of two labels:
- Account risk - the platform's own pages say this route breaks its rules or can get an account restricted or banned. Example: apisapp WhatsApp, where WhatsApp's help pages say linking an account to unofficial apps can lead to a ban.
- Unofficial login - the route isn't official, but we found no platform page that says so. The platform can still block it at any time. Example: Garmin MCP, which signs in the way the Garmin Connect app does.
The workaround is to use an account you can afford to lose, or a server that uses the platform's official API. The cap comes off when the server moves to that API. It doesn't apply when the vendor gathers data from a platform without touching your account (for example, search-results APIs), or to general tools like browser automation, where the risk depends on what you point them at.
The grade is still an assessment from public signals, not a promise that a given account will or won't be banned.
What the grade does not tell you
- Whether the server is safe for your specific data - that depends on the credential you give it and what your agent is allowed to do with the results.
- Whether the current release has a bug that has not been disclosed yet.
- Anything about the hosted infrastructure of a remote server beyond what the vendor documents.
- Whether a platform will block or ban your account. Where a server's route into your account isn't official, we cap the grade at C (see When the platform is the risk), but we can't predict what a platform will do with a given account.
Frequently asked questions
How are MCP servers scored?
Each server is checked on authentication, maintenance, known CVEs and transport safety. The combined result becomes an A–D grade built from public signals. See the four checks for the bands.
What is an MCP server security rating?
The trust grade is our version of one: an assessment from public signals, not a penetration test or code audit. It does not tell you whether a server is right for your specific data.
Can an MCP server get my account banned, such as a WhatsApp MCP?
Possibly. A server that reaches your own account at another platform by a route the platform doesn't offer, such as a linked-device bridge or an unofficial login, is capped at C and labelled Account risk or Unofficial login. See When the platform is the risk.
Why is a well-built server capped at grade C?
The cap reflects the platform's rules, not build quality. A well-built bridge can still get your account blocked. The cap comes off when the server moves to the platform's official API.
Re-grading
Listings are re-checked when a server ships a major release, when a CVE is
disclosed against it, or on a rolling quarterly pass - whichever comes first. The
last_updated field on each listing shows the maintenance date we last verified,
not the date we graded it.
Disagree with a grade?
Find the server in the directory and use the "Request a re-grade" link on its page. Tell us which check you think is wrong and link a public source. We'll re-check it and reply by email. Grades move on evidence.