This is what happens when every Model Context Protocol server in the MCP Trust Registry is read by one deterministic engine instead of being ranked by stars: 30,351 npm and PyPI packages, each scanned from its real published code, each graded by the same auditable rules. Nothing below is a popularity chart, an activity feed or a survey — every number is a scan result, and the same input would produce it again.
94.4% of scanned packages hold an A. That is the honest headline, and it is less reassuring than it sounds: the story worth reading is the 1,707 packages that do not — they are the ones carrying the prompt injection, the tool poisoning and the unreviewable install scripts.
A grade describes the exact version that was scanned, never the project in general. Percentages are of 30,351 scanned packages.
Every package starts at 100 and loses points for what the engine actually finds. The result is not a bell curve — it is a wall at the top and a long, thin tail, which is exactly what a deterministic rule set does to a population where most packages are boring and a few are not.
100 is kept as its own column: “perfect” and “nearly perfect” are different claims.
The grade answers “is this dangerous”. These two answer the questions that decide how much the grade is worth: how much damage could this server do if it went rogue, and how much of the package was actually readable. A high capability is not a finding — it is the reason a finding would matter.
Ranked by how many packages each rule flagged, not by how alarming it sounds. The bars are packages; the table also gives raw findings, because one rule can fire several times inside one package. Rule ids and their thresholds are part of the published engine — nothing here is a human judgement call.
Bar length is packages affected; colour is the rule’s severity.
| Rule | Severity | Packages | Findings |
|---|---|---|---|
MTC-SRC-002 |
high | 7,588 | 17,124 |
MTC-SUP-011 |
info | 5,566 | 5,566 |
MTC-SUP-012 |
info | 4,432 | 4,432 |
MTC-SRC-002 |
low | 2,110 | 4,259 |
MTC-SRC-003 |
medium | 1,580 | 2,552 |
MTC-SRC-001 |
high | 1,464 | 1,985 |
MTC-CAP-005 |
low | 1,100 | 1,957 |
MTC-SUP-010 |
low | 1,041 | 1,041 |
MTC-SRC-005 |
medium | 1,032 | 1,556 |
MTC-SRC-009 |
medium | 874 | 1,369 |
MTC-NET-005 |
info | 859 | 859 |
MTC-CAP-001 |
high | 819 | 1,326 |
This is the reconciliation between the two numbers above: most packages carry something, but the bulk of it is low-severity supply-chain hygiene, which is why the grade distribution still leans hard on A. info notes are counted here for completeness and are never scored.
Counts are individual findings, so one package can appear in several rows.
Each bar is normalised to full width, so these compare mix, not size. If downloads predicted safety, the mix would shift visibly from bottom to top. Read it for that, and for nothing else.
Covers 22,027 packages — 72.6% of the catalog. Only packages carrying an npm weekly-download figure can appear here; the rest publish no such number and are excluded rather than silently counted as zero.
Bucket counts are on the right of each bar; segment labels are that grade’s share of the bucket.
A score belongs to a version, not to a project, so the interesting question is what happens when a package ships a new one. 30,332 packages have been scanned more than once and 6 of them changed grade — the drop column is the rug-pull signal worth watching.
Only the latest rescan against the one before it — one comparison per package, so a single flapping package cannot dominate the summary. A drop means the new version scored lower than the version before it.
| Server | Grade move | Detected |
|---|---|---|
| Phren Cli | B→A | 2026-09-07 |
| Memoir Cli | C→A | 2026-09-07 |
| Sinataoke Cn | A→B | 2026-09-07 |
| Brave Real Browser | A→C | 2026-09-07 |
| Trace | A→B | 2026-09-07 |
| Phren Cli | A→B | 2026-09-06 |
| Par5 | A→B | 2026-09-06 |
| Brave Real Browser | C→A | 2026-09-06 |
The full feed, with versions and the engine build behind each move, is on what changed.
Context for everything above: which ecosystems these packages come from, whether the publisher could be verified, and how the top categories are weighted. These count packages, so they add up to 30,351 — the catalog’s own category pages count products and read lower on purpose.
Top 12 by package count.
“vendor” means the package is published by the vendor it claims to integrate; “source” means the repository was confirmed.
Scanning runs on a queue, not on page load. These figures are recomputed at most once a minute from the stored scans, and this snapshot was built 2026-09-07 15:43 UTC.
A package scanned on an older engine build carries that build's rules until it is re-read, so part of any difference between two packages can be our methodology rather than their code. That is why every scan records the engine version that produced it, and why what changed marks the rows where the engine moved. Re-check any package yourself with the free API or the CLI — same input, same score, no account needed.