MCP CheckHow we check
Every result on this site comes from the rules below: six on the registry metadata, and a deep scan that reads each server's package code and live tool descriptions the way an AI would, looking for the things an AI won't flag. Nothing is ever run. This page lists the rules exactly, and what they found.
Rubric version 1.0. Scanned is not the same as safe: these are automated checks on registry metadata, run on one version on the date shown. They cannot prove a server is free of malicious or vulnerable behaviour, and you should check permissions and run untrusted servers with least privilege.
Levels
| Level | Status | What it means |
|---|---|---|
| In the registry | Every entry: 50,990 | An active, latest-version entry in the official MCP Registry. No judgement implied. |
| Listed | 19,454 of 50,990 | Passed our listing filter, so it has its own indexed page: a source repository is linked, the description is at least 30 characters and not duplicated by more than two other entries, and the publisher has fewer than 100 entries. The rest are unlisted. Details below. |
| Scanned (metadata) | The only level awarded in v1 | The metadata checks below ran. It applies to every entry, listed or unlisted. Warnings are allowed and shown. It says nothing about code or behaviour. |
| Code reviewed | A small, hand-picked set | A person read every line of the package's own code, for one exact version, without running it, and wrote down what it talks to, which files it touches, whether it runs programs, and what its tool descriptions tell the AI. Big or minified packages are skipped because they can't honestly be read line by line. The packages it depends on are not covered. The label lasts only while the listed version is the one we read. A server where we found serious problems shows a warning instead. |
| Verified | Not offered yet | Will require: an install pinned to an exact version or digest we recorded; no install scripts, or scripts reviewed; build provenance or a recorded human review; static code analysis and a sandboxed look at tool descriptions, with no high-severity findings; a named reviewer and review date. |
| Maintained | Not offered yet | Will require Verified, plus a rescan on every new version and on a fixed schedule, and a maintainer who answers findings within a stated period. |
The checks, and what they found
Counts cover all 50,990 active latest-version entries in the registry. They are computed from the data files on this site, which came from registry.modelcontextprotocol.io and were fetched on . "Applies to" is how many entries the check could run on: a remote-only server has no package to pin, so it gets no version check.
| Check | Exact rule | Applies to | Pass | Warn | Fail | Info |
|---|---|---|---|---|---|---|
| Source repository linked | Pass if the registry entry links a source repository. Warn if it does not. | 50,990 | 34,405 | 16,585 | 0 | 0 |
| Version pinned | Only for entries with packages. Pass if every package declares a version other than "latest". Warn if any package has no version or says "latest". | 19,011 | 18,263 | 748 | 0 | 0 |
| Remote uses HTTPS | Only for entries with remote endpoints. Pass if every remote URL starts with https://. Fail if any starts with http://. Warn for any other scheme. | 33,724 | 33,724 | 0 | 0 | 0 |
| Secrets requested | Warn if the server declares three or more environment variables marked as secret. Otherwise Info, listing them. | 50,990 | 0 | 559 | 0 | 50,431 |
| Known package registry | Only for entries with packages. Pass if every package comes from npm, PyPI, OCI, NuGet or MCPB. Warn for any other registry type. | 19,011 | 18,910 | 101 | 0 | 0 |
| Namespace ownership | Info only. States whether the name prefix is a GitHub account or a domain, as the registry recorded it. Not judged. | 50,990 | 0 | 0 | 0 | 50,990 |
| Registry text aimed at the AI | The title, description and setting descriptions are searched for hidden characters (invisible tag characters, bidi overrides, zero-width clusters), instructions to the AI (ignore your instructions, don't tell the user, fake <system> tags), asks for key or config files, and data-collection endpoints. Fail on the first three, Warn on the rest. | 50,990 | 50,989 | 1 | 0 | 0 |
| Install scripts | npm: Warn if the package runs a preinstall, install, postinstall or prepare script; Fail if that script fetches a URL, decodes base64 or pipes into a shell. PyPI: Warn if setup.py makes network or process calls; Fail if it does and there is no wheel, so pip runs it at install. | 16,371 | 15,877 | 494 | 0 | 0 |
| Code red flags | npm, PyPI and MCPB packages are downloaded and unpacked in memory, never run, and every code file outside tests and docs is searched. Fail: code run from base64, obfuscated JavaScript, the whole environment sent over the network. Warn: piping a download into a shell, reading SSH, cloud, browser or wallet credentials, hard-coded data-collection endpoints, very long encoded blobs. Info when the package could not be read or its type (Docker, NuGet, Cargo) is not read yet. | 19,011 | 16,253 | 941 | 40 | 1,777 |
| Text aimed at the AI | Every text file in the package, comments and README included, is searched for hidden characters, text telling an AI reviewer the code is safe or not to flag it, and text telling the AI to hide something from the user. Warn only, with the evidence, since security tools quote these on purpose. | 17,234 | 17,186 | 48 | 0 | 0 |
| Tool descriptions read | Remote servers only: we connect as an MCP client and ask for the tool list, without signing in. Info: the tools listed, or that the server needs sign-in first. | 31,396 | 0 | 0 | 0 | 31,396 |
| Hidden instructions in tools | Every tool name, description and parameter description from that list, and the server's instructions, go through the same search as registry text. Fail on hidden characters, instructions to the AI or asks for key files; Warn on the rest. | 18,744 | 18,726 | 18 | 0 | 0 |
Each result is shown as text and colour together: Pass, Warn, Fail, Info. Info means we report a fact without judging it.
Popularity & health score
Every listed server with a GitHub repository or a package download count gets a score from 0 to 100. It has four parts. Popularity (40) is the best two of GitHub stars, weekly npm or PyPI downloads, and Hacker News points, each on a log scale. Activity (25) is how recently the code was pushed or released, plus commits in the last 90 days. Issue health (15) is the share of GitHub issues that are closed, from 10 issues on. Our checks (20) start full; each warning costs a fifth, and a failed check or a failed code review sets this part to zero and caps the whole score at 40. An archived repository is capped at 10. A part with no data gets half marks. Each server page shows its parts and the numbers behind them.
The numbers come from the GitHub API, npm, pypistats.org and Hacker News search, refreshed by script with no AI involved. It is not a review score and not a safety rating: a popular server can still be unsafe. Nobody can pay to change it, and sponsored placements never affect it.
What listed means
The registry has 50,990 entries. Every one is checked and has a JSON report, but 19,454 are listed and get their own indexed page. The rest are unlisted: they open in a plain viewer at /server/?s=<slug> that says the entry didn't pass our listing filter. The checks are the same.
An entry is listed when all four hold: it links a source repository; its description is at least 30 characters; no more than two other entries share that description word for word; and its publisher has fewer than 100 entries in the registry. On top of that, within each category and subcategory the quarter of entries with the fewest GitHub stars is left unlisted (archived or missing repositories count lowest), so every group keeps its better-known three quarters. Stars measure popularity, not safety, and official company servers are never cut this way. The bulk number is the bulk-publisher threshold. A publisher at or above it is treated as a bulk publisher, because a real organisation rarely lists that many separate servers, and mass-generated entries are where duplicates and spam sit. The threshold and counts are in /data/meta.json. Listed is not an endorsement. It only decides which pages we index.
What none of this covers
Nothing is executed: packages are read, never installed or run, so behaviour that only shows at run time, code fetched after install, and a server that changes its tools after you connect (a rug pull) are not caught. Tool descriptions of remote servers that need sign-in, and of local servers, are only seen where they sit in the package code. Docker, NuGet and Cargo packages are not read yet. Pattern searches miss what they have no pattern for, and a clean result is not a guarantee. Sandboxed runs are planned, not built. The config scanner is a separate tool with its own static checks, run in your browser on text you paste.
Disputing a result
If a result about your server looks wrong, a contact address for disputes is coming soon. Most results come straight from registry fields, so the fastest fix is usually a corrected entry (a pinned version, a linked repository); the next data fetch picks it up. If the rule itself misjudged your server, we'll say so here and change the rule.
Reporting a vulnerability
We don't test other people's servers for vulnerabilities and we don't publish findings of that kind. If you find one in a listed server, tell its maintainer first and give them reasonable time to fix it; tell the registry if you think an entry is malicious. If you find a flaw in this site or the scanner, a contact address for reports is coming soon. We'll acknowledge it, fix it, and won't pursue anyone who reports in good faith.