The State of MCP Security

2. One in four MCP servers can permanently destroy data

508 servers (25%) expose at least one destructive tool — deleting records, dropping tables, wiping indexes, force-pushing branches, removing cloud resources. These are operations that a human operator would normally guard with a confirmation dialog or a four-eyes review. When invoked through MCP, they fire on the model's first decision.

Another 600 servers (29.5%) can execute arbitrary commands — shell, scripts, container exec, SQL with no read-only enforcement. Combine the two: roughly four in ten MCP servers give an agent a way to do something it cannot easily undo.

Exposure compounds with every server you add

42.2% of MCP servers expose a destructive or execute tool on their own. Stacking servers is the common case — an agent rarely connects to one. If the per-server rate holds independently, the probability that a stack of N servers exposes at least one such tool is 1 − (1 − 0.42)N. It passes 93.5% by the fifth server and 99.6% by the tenth.

Independence is an approximation — tool overlap between servers makes the true figure slightly lower — but the direction holds: multi-server exposure is the default, not the tail.

The single most common destructive verb across the dataset is delete: it appears as the first token of 466 tool names. create, update, and delete together form the standard CRUD trio that virtually every "integration" MCP server ships. The protocol provides no separation between them.

4. Destructive MCP surface is concentrated in a few servers

Most MCP servers are not dangerous. The 25% headline number obscures a much sharper truth: destructive surface is heavily concentrated in a small minority of servers, while the long tail of CRUD-shaped integrations sits in the middle. Three out of every four MCP servers expose zero destructive tools at all.

A handful of servers carry the lion's share of the protocol's risk. They tend to be the same shape: large integrations — identity providers, project-management platforms, all-in-one cloud SDKs — that ship hundreds of CRUD endpoints with equal policy weight, and one or two of those endpoints turn out to be the kill switch.

The classifier's top 5% on its own accounts for an outsized share of the destructive calls an MCP-connected agent could make. The protocol does not surface this asymmetry to the model. The model sees a flat list of tools, with no hint that some are load-bearing for the host system and some are not.

The named riskiest ten

Ranked by risk score — tool count weighted by average per-tool risk. These are the servers carrying the most concentrated destructive surface in the dataset.

5.5 Deep dive: the Stripe MCP

Stripe's MCP server exposes 27 tools to any agent that connects. 4% of them are classified destructive and 11% touch money directly. Ranked by risk weight, the three highest are create_refund, finalize_invoice, cancel_subscription. One MCP install hands all of them to the model as a flat list.

What it can move

3 of Stripe's tools are financial — the calls that move balances, charges, refunds, payouts, and transfers. An agent with the server connected can invoke any of them directly, with whatever arguments it infers from the request. In policy terms these are the operations that take money out of the account.

create_refundfinalize_invoicecreate_payment_link

What it can destroy

1 tools are classified destructive — deletes, cancellations, and voids that the same API cannot reverse. None of them carry warning language the model reads before calling; the category is inferred from the verb in the tool name, not declared by the server.

cancel_subscription

What a deny-by-default policy looks like

A deny-by-default posture starts every Stripe tool denied and allows back only the read paths an agent needs — listing charges, retrieving a customer, reading a balance. The 4 destructive and financial tools stay denied unless a policy grants them explicitly, and the ones that are granted route through an approval gate rather than firing on the model's first decision. A worked example is published at policylayer.com/policies/stripe.

Stripe's MCP is well-built; the point is not that it is unusually dangerous. The point is that the server cannot know which agent should be allowed to issue a refund. That decision belongs to the control plane in front of it.

6. Official MCP registries are not noticeably safer

A common assumption is that "official" MCP listings are curated and therefore safer. The data does not support it. Average risk weight per tool barely moves between sources, and seed-listed servers (those originally added by hand to bootstrap the ecosystem) are actually the highest-risk cohort.

Every registry leaves risk evaluation to the developer installing the server. None of them gate on tool category, parameter danger, or the presence of unconfirmed write paths. Listing is curation only by name.

8. MCP tools don't brief the agent. 96.1% give no warning at all.

MCP tool descriptions go directly into the model's context as the only briefing it gets. We searched all 31,000 classified tool descriptions for warning language — "irreversible", "permanent", "cannot be undone", "destroys", "wipes", "deletes", "drops", "purges". Only 1,208 tools (3.9%) contain any of those phrases.

The other 96.1% rely on the model inferring danger from the verb in the tool name. For a request like "clean up duplicate rows", an agent given fifty CRUD tools and no warnings will pick the one whose name matches the verb. delete_rows is the obvious match. There is no semantic signal that distinguishes it from list_rows.

A further 15% of servers (304) accept parameters whose names imply filesystem paths or shell command strings — path, filename, command, script, exec, stdin. These tools provide direct write or execution surfaces against the host the server runs on, regardless of whether they are classified as destructive. The wider catalogue of documented MCP attack patterns shows how prompt injection, tool poisoning, and supply-chain compromise convert these surfaces into incidents.