The State of MCP Security
What 1,787 MCP servers can actually do to your systems.
We classified every tool on every Model Context Protocol server we could enumerate from the public registries — 25,329 tools across 1,787 working servers. The data shows an ecosystem that hands AI agents wide, dangerous, and almost entirely unannounced control over the systems they touch.
1. What MCP servers actually do
Every tool we found was classified into one of six risk categories: read-only, write, execute, destructive, financial, or other. The chart below shows how many of the 1,787 servers in our dataset expose at least one tool in each category.
Servers usually expose tools in multiple categories — an integration that lists, creates, and deletes records lands in Read, Write and Destructive simultaneously. Percentages are of the 1,787 servers in the dataset.
2. One in four MCP servers can permanently destroy data
438 servers (24.5%) 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 486 servers (27.2%) 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.
The single most common destructive verb across the dataset is delete:
it appears as the first token of 321
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.
3. The average MCP install gives an AI agent 14.4 tools
The median MCP server exposes 7 tools. The mean is
14.4. The 99th percentile exposes 122.
The fattest single server is io-fusionauth-mcp-api, which exposes
310 tools to any agent that connects.
The full classifier output for every server we scanned is in our
public MCP tool catalogue.
| Server | Tools |
|---|---|
| io.fusionauth/mcp-api | 310 |
| io.github.aibtcdev/mcp-server | 288 |
| Financial Modeling Prep | 253 |
| Trello | 200 |
| Google Super | 200 |
| io.github.alxpark/propresenter-mcp | 177 |
| Leaper Vision Toolkit | 169 |
| Apiosk | 160 |
| io.github.Antonytm/mcp-sitecore-server | 153 |
| SmartBear MCP | 147 |
A server exposing 200+ tools is unauditable in practice. No human reads 200 tool descriptions before installing. The model sees them all by default, and a context-window's worth of tool schemas competes with whatever task the user actually asked for.
4. Destructive MCP surface is concentrated in a few servers
Most MCP servers are not dangerous. The 24.5% 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.
5. When MCP servers touch money, most can also destroy data
Only 60 MCP servers in our dataset expose financial tools — payments, transfers, wallet operations. They are rare. They are also the cohort with the highest combined risk in the entire ecosystem.
28 of 60 servers
43 of 60 servers
Across the 28 servers that combine financial and destructive surface, an agent connecting to a single one of them gets, on average, 3.0 ways to destroy data and 2.4 ways to move money. The single worst dual-risk server gives the agent 12 destructive tools and 15 financial tools — 27 ways to either break things irreversibly or move money — in a single MCP install.
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.
| Source | Servers | Tools | Avg risk | % destructive | % execute |
|---|---|---|---|---|---|
crawler | 2,799 | 9,814 | 0.233 | 5.5% | 6.6% |
smithery | 791 | 9,620 | 0.197 | 4.1% | 3.5% |
seed | 350 | 5,747 | 0.321 | 6.7% | 6.1% |
user_scan | 78 | 148 | 0.205 | 8.1% | 3.4% |
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.
7. Two of the six most common MCP verbs are destructive
The MCP ecosystem speaks one language: CRUD. Across 25,329
tools, the four most common verbs after get and list are
create, search, update, and delete.
Two of the top six are mutations the model cannot undo. The protocol provides no
separation between any of them.
get_* 4,098 list_* 1,033 create_* 677 search_* 670 update_* 349 delete_* 321 generate_* 244 check_* 210 add_* 149 retrieve_* 108 validate_* 107 analyze_* 106 delete_* appears 321
times. That is roughly one destructive-named tool for every five servers in the
dataset, before counting tools that are destructive without using the word
("drop", "remove", "wipe", "purge"). Verb shape is the cheapest signal a client could
act on; nothing in MCP requires clients to use it, so they don't.
8. MCP tools don't brief the agent. 96.8% give no warning at all.
MCP tool descriptions go directly into the model's context as the only briefing it gets. We searched all 25,329 classified tool descriptions for warning language — "irreversible", "permanent", "cannot be undone", "destroys", "wipes", "deletes", "drops", "purges". Only 803 tools (3.2%) contain any of those phrases.
The other 96.8% 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 14.3% of servers (255)
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.
9. The trust boundary is the developer's restraint
The MCP specification ships with no built-in authorisation, no rate limits, no spend caps, and no audit trail. Servers expose whatever their authors decided to expose, in whatever shape, with whatever description. Clients pass tool lists to models with no enforced filter. Models call tools with whatever arguments they think appropriate. The trust boundary is the developer's restraint when they write the server.
This dataset puts numbers on the consequences:
- One in four MCP servers can delete or destroy data.
- One in four can execute arbitrary commands on its host.
- The average install hands the agent 14.4 tools, often more than 30.
- 3.2% of tools warn the model about what they do. The other 96.8% don't.
- Official, semi-official and community registries show no meaningful risk gap.
Most teams would not ship an internal API where every endpoint is unauthenticated and uncategorised, where 1 in 4 endpoints can delete production data, and where 96.8% of endpoints have no documentation about side effects. That is the median MCP server today. Whether your agent runs on it is a control-plane decision, not a server-author decision.
The fix is not to ban destructive tools. The fix is enforcement at the transport layer: every tool call evaluated against a deterministic policy before it reaches the server. For the broader picture of how the protocol breaks under production conditions, see the canonical MCP security overview.
PolicyLayer is the MCP control plane:
- A gateway in front of every MCP server in your fleet, with managed OAuth that holds and refreshes upstream tokens transparently.
- A policy editor that discovers each server's tools so you can gate by category — destructive, financial, execute — instead of by tool name.
- Scoped per-agent grants, decoupled from user identity, so revoking one agent doesn't break the rest of your stack.
- A per-call audit log keyed to the grant that made the call, with full arguments, outcome, and latency.
One install. Every server. Scan your config to get the same picture this report shows, but for your stack — in 30 seconds.
Methodology
PolicyLayer maintains a continuously-updated catalogue of MCP servers harvested from the official Model Context Protocol registry, npm, Smithery, and Glama. For each server we attempt to extract its tool list through one of three paths:
- Static analysis — grep the published npm tarball for tool definitions.
- README extraction — parse README for tool tables and code blocks.
- Live execution — spawn the server via
npxin a sandboxed container and read itstools/listresponse.
The 1,787 servers in this report are those for which at least one path produced a parseable tool list. Tools are classified into six risk categories (Read, Write, Execute, Destructive, Financial, Other) using a verb-based classifier with input-schema heuristics. 72.3% of tool classifications are marked high-confidence, 15.4% verified.
Risk weights are floats from 0.0 (read-only) to 1.0 (destructive financial). The
full classified catalogue — one row per server, one row per tool — is
published as an open dataset on Hugging Face under CC-BY-4.0:
huggingface.co/datasets/PolicyLayer/mcp-server-catalogue.
Loadable via load_dataset("PolicyLayer/mcp-server-catalogue"). Per-month
editions are tagged (current: 2026-05). Methodology questions or custom
cuts: research@policylayer.com.
Limitations. The dataset only covers servers reachable through public registries; private and self-hosted servers are not included. Tool-level classification can mislabel ambiguous verbs ("update" can be safe or destructive depending on parameters); the confidence breakdown above surfaces these. Some registry-listed servers were unreachable through our scan pipeline and are excluded from the figures here; the dataset is therefore a lower bound on the real ecosystem.
Control what your agents can do through MCP.
Get the gateway. Get the dashboard. Get the audit log.