Scan of 7,749 public MCP tool manifests blocks a third for risky tool pairings

What the scan covered

On August 31, security firm BackBond pulled the tools/list response from every MCP server in the public registry that answered an unauthenticated request. That produced 8,147 reachable endpoints, 7,749 distinct manifests and 130,322 tool definitions. Writing on dev.to, Ari Katz of BackBond explains that the analysis ran entirely over saved metadata: no server code was executed and no tool was ever called. The scanner, at version 0.6.3 with ruleset 2.0.2, reads only the information a client sees at attachment time.

The headline numbers

Of the 7,749 manifests, 28% returned no blocking finding, 39% were classed as "review" (something the static check cannot resolve on its own), and 33% matched at least one high-severity rule and would be stopped by a pre-attachment gate.

The finding people tend to expect turned out to be rare. Descriptions that try to steer the model — the prompt-injection class, such as a tool telling an agent to always call it, to hide what it does, or to hand over credentials — appeared in just 91 manifests, or 1.2%. Explicit forced-invocation language showed up in only 10.

Composition, not injection, drives the blocks

According to the post, three patterns account for almost every block, and each is about how tools sit next to each other rather than any single tool being malicious:

• 27% of manifests include a network tool that accepts an arbitrary URL-like destination with no allowlist in its schema.
• 22% place a fetch-shaped tool in the same manifest as a tool with destructive or privileged scope. Each is fine separately; together they form the path where a fetched page can instruct an agent to delete something.
• 21% contain a persistent-write tool whose input can carry untrusted content.

The classic worry — untrusted input reaching a shell or code executor — appeared in 3.5% of manifests.

The metadata itself has gaps. 68% of manifests were only partially analyzable from static metadata alone, and 10% ship at least one tool with no input schema at all, leaving both the client and any checker to guess what the tool accepts.

Size is the strongest signal

Small manifests rarely trip a rule: those with five or fewer tools were blocked 13% of the time. Large ones almost always do: manifests with more than 25 tools were blocked 85% of the time. The median manifest exposes 7 tools; the largest exposes 1,082. The reasoning is mechanical — the more tools a server exposes, the likelier it is that a fetch, a write and a destructive action end up side by side.

What a block is, and what it is not

Katz is careful to define the term: a block is a metadata match against a fixed rule, not a vulnerability, not an incident, and not a claim about what the server actually does. The rules and their exact conditions are published, and false-positive reports are answered within 72 hours.

Two honesty notes accompany the data. First, the corpus is the reachable, unauthenticated subset of one registry snapshot, not the ecosystem at large. Second, TLS verification was off during collection, so the authenticity of every endpoint cannot be vouched for — the manifests are simply what those hosts returned.

The numbers also depend on the ruleset. An earlier version (0.5.15) blocked 3,477 of the same files; tightening the write, network and interpreter rules in 0.6.x brought that down to 2,532, removing roughly 950 blocks that had matched on help text and ambiguous paths.

BackBond says the scanner is open source, pinned to the version used here, runs locally with no network requests, and prints a decision plus findings. Aggregate numbers come from identity-free summary output; per-server results are never published.

Why it matters

As agents get attached to more MCP servers, the trust decision happens at attachment time, before anything runs. This scan suggests the real exposure is structural: not tools that lie in their descriptions, but ordinary network, write and destructive tools combined in one manifest where an injected page can chain them. Treating manifest size and tool composition as first-class signals — and insisting on input schemas — would catch more than hunting for injection text. The results are also a reminder that any static verdict is ruleset-dependent, so scans like this should ship their versioned rules and caveats alongside the headline figure.