Introducing the MCP Trust Registry: a Security-Scanned Directory of MCP Servers

Today the MCP Trust Registry goes live on mcptrustchecker.com: a browsable directory of Model Context Protocol servers where every single listing has been security-scanned before you see it. At launch it covers more than 1,200 servers across 23 categories — from databases and browser automation to AI agents and cloud & DevOps — and it grows continuously as new packages are checked.

This post explains why we built a registry at all, what makes it different from the many MCP lists that already exist, and how to read a listing before you connect anything to your assistant.

Why another MCP directory?

There is no shortage of places to find MCP servers. What every one of them has in common is that they answer only the first question: what does this server do? None of them answer the second, more important one: what could it do to you?

An MCP server is not an ordinary dependency. It sits inside the trust boundary of your AI assistant: its tool descriptions are read and obeyed by the model, its tools run with whatever access you granted, and a malicious or sloppy server can turn a helpful assistant into an exfiltration channel — the tool-poisoning and toxic-flow patterns we have written about before. Choosing a server off a popularity list is installing code you have never read, into the most privileged position software can occupy on your machine.

The MCP Trust Registry closes that gap: a directory where the security check has already happened, for every entry, before it was listed.

How every listing is scanned

Each server in the registry was analyzed by the same open-source mcptrustchecker engine that powers the CLI and the free API. The engine downloads the actually published npm or PyPI package and inspects its code and tool surface with deterministic rules — the Capability-Flow Trust Model. Three properties matter:

• Deterministic. The same package version always produces the same score. There is no AI, no LLM and no human judgement anywhere in the scoring path — every finding is a rule firing on observable evidence, and you can reproduce any result yourself with npx mcptrustchecker.
• Evidence-first. A listing does not just say "grade B". It shows the individual findings, each with the rule that fired and what it matched, plus an honest statement of what the scan could not see.
• No pay-to-list. Placement and ranking cannot be bought. A server is listed because it was scanned, and ranked by what the scan found — nothing else.

Reading a listing: three axes, not one number

Every server page shows three independent signals, and they are designed to be read together:

• Trust Score (A–F, 0–100) — how safe the published surface and source look. Treat it as a first filter, not a verdict.
• Capability — the blast radius: what the server's tools could reach if it went rogue. Filesystem, processes, network — and how they combine. A perfectly honest server with critical capability still deserves more caution than a mediocre one that can only read the weather.
• Coverage — how much of the package the scanner could actually inspect. A grade earned on full source coverage carries more weight than one computed from metadata alone, and the registry never hides which one you are looking at.

Beyond the score, each listing links the source repository, records a scan history per published version — the engine is deterministic, so a changed score always means the package itself changed — and offers a styled raw report if you want every detail.

Badges for your README

If you maintain an MCP server, every listing ships an embeddable badge: a small SVG showing the current Trust Score, served straight from the registry and updated automatically after every rescan. One line of Markdown puts a live, independently computed security signal in your README — something a self-written "secure ✅" note can never be. The embed snippets (Markdown and HTML) are on every server page.

How servers get in — and how to check one that isn't

The registry is fed by a scanning queue: published npm and PyPI packages are checked in bulk by the engine, and a package only appears after a successful scan. If the server you are evaluating is not listed yet, you do not have to wait: scan it yourself in seconds with the free scan API or locally with npx mcptrustchecker scan <package> --online. Maintainers who want a listing corrected, rescanned or removed can simply email [email protected].

One honest caveat

A Trust Score is an automated opinion about published code at a point in time — not a certification, and not a guarantee. New versions ship, coverage varies, and automated analysis has limits that the registry states openly on every page. Use the registry to narrow the field and to see the evidence; keep the final decision, and the principle of least privilege, for yourself.

Browse it now: mcptrustchecker.com/registry.

npx mcptrustchecker