mcpwatchman

An independent audit of the Model Context Protocol registry

Every point is subtracted for a reason you can read.

mcpwatchman scans the servers in the official MCP registry and publishes what it found, not just what it concluded. A score is a ledger: it opens at 100, and every deduction names the finding, the file and the line that produced it.

Browse all 492 serversGet the data as JSON

428 of 492 shipped source we could read; 51 declare a repository nobody can reach. Last scanned .

Code Safety worked example

  1. starting score 100 Every axis opens at 100.
  2. shell exec in a tool handler −20.0 Critical, medium confidence. First of its severity: the full 20.
  3. SSRF, no host allowlist −15.0 Critical, medium confidence. Second of its severity: 75% of 20.

Axis score 65

65 kept −20.0 −15.0
Real arithmetic from the shipped engine. Only the score is rounded, never a deduction. The second finding of a severity contributes 75% of its deduction, the third 50% — so twenty criticals and one critical don't score the same, and the worst finding still takes the undiminished hit.

What this can and cannot see

50.5%of a 100-server registry sample ships source we can read

48 of those 99 active servers were remote-only — an endpoint, no published source, nothing to analyse. We will say so on their page rather than show you an empty score that looks like a verdict.

The analysis is static, always. We read published source, manifests and lockfiles; we never execute the code we scan and never connect to a running server. So the blind spot is whatever that source doesn't determine — behaviour gated on remote configuration, code fetched at runtime, or a deployment that differs from the repository it declares.

Publishing a coverage figure we'd rather were higher is the point, not an aside. The numbers everyone quotes about MCP security come from parties with something to sell, and nobody can check them.

Five axes, each scored on its own

  • 30

    Code Safety

    Shell exec in tool handlers, unvalidated URL fetches, unsafe deserialization, path traversal — matched against an MCP-specific semgrep ruleset.

    scored for 305 of 492

  • 20

    Auth Posture

    Whether a server requires a key, uses OAuth, or accepts anyone — read against the transport it declares.

    scored for 488 of 492

  • 20

    Dependency Health

    Known CVEs in the resolved dependency set, via OSV. Transitive coverage where a lockfile exists, and said plainly where it doesn't.

    scored for 71 of 492

  • 15

    Maintenance

    Last commit, release cadence, open-to-closed issue ratio, sole-maintainer risk.

    scored for 398 of 492

  • 15

    Transparency

    License presence and SPDX validity, and whether the manifest's claims match what the code actually does.

    scored for 428 of 492

The hatched share of each bar is servers that axis could not be assessed for — a missing lockfile, an unreachable repository — and each server's page says which.

Each axis ships its own 0–100 score, and the weights beside them are provisional. The weighted composite is computed but not published until a hand-audited gold set says the weights are right — publishing an uncalibrated single number is how a methodology becomes marketing.

Where it actually is

Live
492 server pages, every deduction linked to its file and line. The same data as JSON, per server or as one file, an llms.txt index for agents, an Atom feed of new critical and high findings, and mcpwatchman check to read a server from a terminal. Every server is rescanned nightly; the current data was scanned on .
Next
The gold set: about thirty servers audited by hand, which measure each rule's false-positive rate and calibrate the weights.
Not yet
The weighted composite, withheld until calibrated, and the feed of its drops. The badge.
Browse all 492 serversRead the sourceTell us where the methodology is wrong