# What 7,749 public MCP tool manifests look like before you attach them

> Source: <https://dev.to/ari_katz_bb/what-7749-public-mcp-tool-manifests-look-like-before-you-attach-them-25n2>
> Published: 2026-10-01 17:01:54+00:00

*I'm Ari from BackBond; we maintain the scanner this post is about.*

On August 31 we pulled the `tools/list` response from every MCP server in the public registry that answered an unauthenticated request. That gave us 8,147 reachable endpoints and 7,749 distinct manifests, 130,322 tool definitions in total. We then ran BackBond Agent Scan over the saved files. No server code was run, no tool was ever called; the scanner reads the metadata a client sees at attachment time and nothing else.

Here is what that metadata says, with the scanner at 0.6.3 and ruleset 2.0.2.

Of 7,749 manifests, 28% came back with no blocking finding, 39% came back as "review" (something the static check can't resolve on its own), and 33% matched at least one high-severity rule and would be blocked by the pre-attachment gate.

The thing people expect to be common is rare. Descriptions that try to steer the model, the prompt-injection class (a tool telling the agent to always call it, to hide what it does, or to hand over credentials), appear in 91 manifests, 1.2%. Forced-invocation language specifically: 10 manifests out of 7,749.

The thing people don't expect is what dominates. Three composition patterns account for almost every block:

Untrusted input reaching a shell or code executor, the classic worry, is in 3.5% of manifests.

Then there's what the metadata doesn't say. 68% of manifests are only partially analyzable from static metadata alone. One concrete gap: 10% of manifests ship at least one tool with no input schema at all. The client has to guess what the tool accepts, and so does any checker.

A manifest with five or fewer tools is blocked 13% of the time. A manifest with more than 25 tools is blocked 85% of the time. The median manifest has 7 tools; the largest has 1,082. Composition findings scale with surface, because the more tools a server exposes, the more likely it is that a fetch, a write and a destructive action end up side by side. If you're about to add a server that exposes forty tools, the odds are that something in it will need a look.

It's a metadata match against a fixed rule, not a vulnerability, not an incident, not a claim that the server does what its description says. It's the same decision a client would get from the scanner at attachment time: here is a pattern, decide whether you accept it. We publish the rules and the exact conditions for each; the false-positive form is in the repo and we answer within 72 hours.

Two honesty notes on the data. First, this is the reachable, unauthenticated subset of one registry snapshot, not the ecosystem. Second, TLS verification was off during collection, so we can't vouch for the authenticity of every endpoint we talked to; the manifests are what those hosts returned, nothing more.

Earlier versions of the ruleset flagged more. On the same 7,749 files, our 0.5.15 ruleset blocked 3,477 manifests; the precision work in 0.6.x took that to 2,532 by tightening the write, network and interpreter rules (about 950 fewer blocks, mostly rules that had matched on help text and ambiguous paths). We mention this because the number you get depends on the ruleset version, and we'd rather say so than present one figure as the truth.

Everything above comes from one command per manifest. Save your client's `tools/list` response as `tools-list.json`, then:

```
npx -y @backbond/agent-scan@0.6.3 vet-tools --stdin < tools-list.json
```

It runs locally, makes no network requests, and prints a decision plus the findings. There's a browser version with three synthetic examples if you want to see it before installing anything: [https://backbond.ai/agent-scan/try/](https://backbond.ai/agent-scan/try/)

Source, pinned: [https://github.com/BackBond/agent-scan/tree/v0.6.3](https://github.com/BackBond/agent-scan/tree/v0.6.3). Aggregate numbers above come from the identity-free `--summary-only` output, one row per manifest, counted up; we never publish per-server results, and we don't intend to.

*Figures: scanner @backbond/agent-scan 0.6.3, ruleset backbond-local-rules/2.0.2, profile backbond-pre-attach/v1, run 2026-10-01 on the 2026-08-31 corpus (7,749 manifests, CSV SHA-256 596c0664…, archive SHA-256 dfd7c131…). Prior-version figures: 0.5.15 / ruleset 1.4.0 (block 3,477 / review 1,961 / no blocking finding 2,311) and 0.6.2 / ruleset 2.0.1 (2,535 / 3,020 / 2,194), from the internal reruns on the same files.*
