SkillTotal
← Back to home

We scanned every MCP server in the official registry

Four in five expose tools to an agent. Two in three can reach the network. Nearly a third can execute shell commands. Almost none of that is a vulnerability — and that is exactly why it is worth measuring.

Want the smaller, weekly-refreshed study of curated components instead? See State of AI Component Security. To check one server rather than the population, scan it.

Deterministic static scan of every distinct component in the public MCP registry — 17,535 of them — engine v0.41.0, ruleset 45, generated 2026-08-20. The registry lists a server per published version, so its 73,460 entries collapse to 17,535 distinct components; counting the raw list would count one package many times.

What these components can do

Every figure is a capability: something the shipped code is able to do. A capability is not a vulnerability — a server that runs shell commands may exist precisely to run them. What it shows is the reach an agent inherits when it hands work to a component.

Exposes MCP tools
81.5%
Can reach the network
65.2%
Can execute shell commands
29.3%
Reads the filesystem
25.3%
Writes the filesystem
21.1%
Runs code at install time
7.5%
Delegated (OAuth/OIDC) authentication
5.9%
Evaluates code dynamically
3.5%
Scoped, short-lived identity
0.5%
Carries a prompt-injection surface
0.4%

Risk levels

A capability contributes zero to the risk score; only risky constructs and malicious indicators do. The distribution is therefore far flatter than the table above — and that gap is the finding.

LOW
97.2%
MEDIUM
0.9%
HIGH
1.6%
CRITICAL
0.2%

65 components (0.4%) carry at least one deliberate malicious indicator.

Coverage

15,538 of 17,535 components were scanned (88.6%). Nothing was dropped silently — each exclusion is counted under its reason.

Not scanned becauseComponentsShare
repository or package no longer reachable1,5939.1%
slower than the time bound1941.1%
larger than the size bound1460.8%
other600.3%
access denied40.0%

The registry itself

  • 73,460 entries resolve to 17,535 distinct components.
  • 9.1% of the population points at a repository or package that is gone or private.
  • 7,312 components are hosted on GitHub across 4,325 owners — yet a single owner accounts for 18% of them, and the ten largest for 29.1%.

What this report does not claim

No count of leaked credentials. The engine does detect embedded secrets, but a sample of those hits in this population was dominated by values published on purpose — analytics project keys vendors document as safe to expose, on-chain addresses, public vendor constants. A raw count would measure shape rather than exposure, and presenting it as a number of leaks would be a false statement about named projects. A figure will appear when it can carry a precision estimate from a labelled sample.

No component is named. These are population statistics.

Method and data

  • Deterministic regex + AST analysis. The component is never executed and no LLM is involved, so the same population through the same engine reproduces the same numbers.
  • Two disclosed bounds: 50 MB per fetch and 60s of wall clock per component.
  • Full report · Raw JSON · The harness that produced it