Census of 42,163 MCP servers finds thousands expose tools that can move money

A census of the public Model Context Protocol ecosystem, published as a post on dev.to, reports that thousands of MCP servers expose tools that can move money — and that a substantial share of them handle credentials inside the same trust boundary, meaning a successful prompt injection could result in unauthorized spending rather than a mere data leak.

What the census found

According to the post, the author froze a snapshot of the public MCP ecosystem on 12 October 2026, anchored with SHA-256 hashes, covering 42,163 servers and 229,539 tool parameter schemas. Every reported figure can supposedly be recomputed from the frozen exports using a screening script released under CC0.

The headline numbers are stark. Some 3,456 servers expose a funds-movement surface of some kind, and 1,301 of those include tools the author describes as having "write polarity" — tools that can actually initiate or transfer money rather than merely read balances or transaction history. A further 2,663 servers handle both money and credentials within a single trust boundary, which the author singles out as the most dangerous combination: a prompt injection that lands on one of these servers exposes more than data, it exposes the ability to authorise payments. Beyond payments, 9,761 servers touch account identity data in their tool parameters.

What is being released alongside it

The post is paired with three open artifacts intended to make the findings usable. The first is a risk gazetteer schema in which every label must carry an evidence chain: a frozen parameter path plus a reference to the vocabulary rule that produced it. Unlabeled claims are omitted by design, on the argument that a risk assessment without verifiable evidence is a liability rather than a safeguard.

The second is a signed receipt format. It uses Ed25519 signatures over RFC 8785 canonical bytes, with hash chaining and offline verification, so a third party can check an agent's decision record without having to trust either the agent or the MCP tool host.

The third is a fail-closed rollback-evidence receipt. A claim that a transaction was reversed is rejected by the checker unless it is bound to the original transaction reference — a verbal assurance that a loss was compensated does not count as proof.

The accompanying white paper is archived on Zenodo, and the gazetteer code and conformance vectors are published on GitHub under CC0, with an MIT-licensed checker. The author explicitly invites others to recompute the numbers and treats any discrepancy as a bug report.

Caveats

These figures come from a single self-published post, and the classification methodology — how a tool parameter is judged to relate to funds movement or credentials — lives in the released artifacts rather than in the post itself, so the numbers should be read as self-reported until independently reproduced. The author also flags a structural blind spot: a census can only see public MCP servers. Enterprise-internal deployments, which the author says are where regulated payment traffic actually runs, are invisible to this kind of measurement.

Why it matters

MCP is becoming the standard mechanism by which AI agents connect to external systems, and every tool parameter represents a capability an agent can be convinced to invoke. As agents gain autonomy over wallets, payments and accounts, the server ecosystem becomes an attack surface measured in tens of thousands of endpoints. Even read as directional rather than exact, the census identifies a concrete prompt-injection risk: thousands of publicly reachable servers that can move money, many of which also hold the credentials needed to do it. The released tooling — evidence-chained risk labels, offline-verifiable decision receipts and fail-closed reversal checks — is a notable attempt to make agent payment decisions auditable by parties that trust neither the agent nor the tool host.