Not a badge bought from a vendor and not a checkbox: our own engine, run on every listing before it can be installed and again on every release. The grade it produces is published on the listing whether it passes or not, the report behind it wherever the scanner has published one, and it costs nobody anything — not the buyer, not the publisher, not on a free listing.
It is ours — the same scanner we build and publish as its own product, not a service we buy in and not a wrapper around somebody else's linter. What it implements is the Capability-Flow Trust Model: a methodology written from scratch for MCP, which scores a server the way an attacker reasons about it — what each tool can reach, what that combination makes possible, and what a release quietly changed since you installed it.
Because it is a product rather than an internal script, the rules, the grade bands and the reasoning are public and the same engine can be run against any server on the internet, including ours. A grader nobody outside the company can inspect is a grade nobody has to believe.
A grade is evidence about one build and nothing else. A dependency published clean in March can be taken over in June without the listing changing a line, which is why the report on a listing carries the date it was produced and the version it was produced against — read those before you read the letter.
MCP Trust Checker implements the Capability-Flow Trust Model — written from scratch for MCP rather than a general code scanner pointed at it: 81 deterministic rules across 37 attack techniques, no model in the loop, and the same input always producing a byte-identical score. Four of those families are things a linter structurally cannot do.
Every tool is tagged by what it can actually do, then the graph looks for the combination rather than the call: private data reachable, untrusted content reachable, and an exfiltration path out. A server whose tools are each harmless and lethal together is the case single-tool review is built to miss.
Tool descriptions are executable in practice. We read them for tool poisoning, line jumping, shadowing, instructions to keep something from the user, and parameters shaped to carry data out — and the same pass checks unicode integrity, where a tags-block, a variation selector, a bidi run or a homoglyph hides a second instruction from your eyes but not from the model's.
Every release is pinned by SHA-256, so a republished same version is a finding rather than a silent update. Supply chain runs beside it: typosquat and combosquat names, install scripts, provenance.
Capability is extracted from the source a tool actually runs and compared with what the manifest claims. A tool that declares read access and can write is a finding; the declaration is the claim being tested, not the evidence.
410 automated tests · 30,000+ real servers scanned · no telemetry. Determinism is the point: a grade you cannot reproduce is a grade you cannot argue with.
| Static analysis | Source, manifest and every dependency at the version the release locked. |
| Capability flow | What each tool can reach, against what it declares. |
| Secret scan | Repository and image, with a liveness check — rotating the key clears it, deleting the line does not. |
| Description drift | Word-level diff of every tool name, description and input schema against the previous release. |
| Dependency audit | Known advisories, producing the grade — A+ to C, published either way. |
| Egress observation | The first 200 real calls, compared with the declared allowlist. |
Every grade is on the page of the listing it belongs to, signed out included, and so is the report behind it wherever one has been published. Publishers pay 12% of what they sell and nothing for the scan; buyers pay nothing for the marketplace at all. A trust layer that only paying accounts can see would be a trust layer nobody could check.