How mcpgrade grades MCP servers

MCP servers run with real access — files, network, shell, credentials — but until now there was no way to tell a safe one from a risky one before you installed it. mcpgrade grades every server in the official registry A–F so you can check before your agents trust it. Here is how the grade is produced.

Six checks, weighted by risk

Every server is scored 0–100 across six checks, each weighted by how directly a failure enables a real attack:

Injection surface (25%) — tool descriptions and manifests scanned for instruction-injection patterns: imperatives aimed at the model, hidden text, “ignore previous instructions,” data-exfiltration URLs.
Supply chain (25%) — package provenance: namespace verification, repository linkage, maintainer count, account age, postinstall scripts, typosquat distance.
Credential hygiene (15%) — how the server takes secrets (env vs. plaintext config vs. hardcoded), and whether secrets appear in tool schemas.
Permission scope (15%) — declared tools vs. actual breadth (filesystem, network, exec); flags shell-exec and unbounded filesystem access.
Version behaviour (10%) — diffs tool definitions between versions to catch new permissions or changed descriptions slipped into a patch release.
Transport config (10%) — for remote servers, TLS and auth mode; for local servers, whether the manifest phones home.

The 0–100 score maps to a letter: A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 40, F below 40.

Coverage caps the grade

A grade is only as trustworthy as what could be inspected. If too little of a server can be analyzed, it doesn’t get a passing grade by default — it’s marked insufficient, a distinct state that is never a silent pass. An A requires both a high score and enough coverage to stand behind it. This is why a server can score well on the few checks that ran but still hold at B: clean on what was seen, but not enough was seen to certify.

Static analysis, plus runtime where reachable

Three of the six checks want the server’s live surface — its actual tool list — which only exists when the server is running. So mcpgrade pairs static analysis of the published package and manifest with runtime probing where a server can be reached: remote endpoints are connected to live, and local servers are run inside an isolated sandbox to read their real tool list. What can’t be reached or booted stays insufficient rather than guessed at.

Facts, not intent

Grades reflect what’s observable, not a judgement of the maintainer. Every score is recomputable from its findings — nothing is a black box — and every grade is disputable. The point isn’t to shame; it’s to give you, and your agents, an honest signal before trust is extended.

Browse the full register at mcpgrade.dev, or see the scoring rubric for the checks and weights in detail.