MCP's Action-Tool Majority: When 65% of Live Endpoints Modify State

Sixty-five percent of live MCP tools now execute write, send, or delete operations — a number that stood at 27% just sixteen months ago. An analysis of 177,436 tools catalogued from the public MCP ecosystem between November 2024 and February 2026 shows that action-taking has become the dominant mode, not the exception. For site owners who have deployed or are evaluating MCP endpoints, the risk profile of the protocol has materially changed.

Method

The tool-mix data comes from an analysis of 177,436 tools published across the MCP ecosystem between November 2024 and February 2026. Vulnerability surface data comes from Endor Labs' examination of 2,614 MCP implementations, published in early 2026. Registry size figures come from the official MCP Registry API and GitHub's search API, both queried on May 24, 2026. Annotation adoption rates come from the MCP protocol team's March 2026 post on tool annotation semantics.

How the Mix Shifted

When MCP launched in late 2024, servers were primarily read-oriented: document search, database lookup, pricing retrieval. As of February 2026, that picture has reversed. Action tools — which write files, dispatch emails, execute code, or create records — account for 65% of all deployed tools, up from 27% at launch. Software development tooling drove much of the shift: it accounts for 67% of all deployed tools and 90% of downloads, and those tools predominantly write code, modify repositories, and trigger CI runs.

The pace matters. In sixteen months, action-tool share grew by 38 percentage points. The total server count grew in parallel: the official MCP Registry returned 9,652 unique server records as of May 24, 2026, and GitHub indexed 15,926 repositories carrying the mcp-server topic on the same date. More servers, more tools, and a rising proportion of them are taking actions on external systems.

The Annotation Gap

MCP introduced tool annotations in the March 2025 specification revision. The four hints — readOnlyHint, destructiveHint, idempotentHint, and openWorldHint — are the mechanism by which servers communicate risk to clients. A tool carrying readOnlyHint: true tells the client it will not modify state, enabling parallel dispatch and a lighter consent footprint.

Adoption of these hints has been slow. As of March 2026, the MCP protocol team described annotation coverage as "uneven," noting that many servers ship without them and clients vary in how strictly they honor the pessimistic defaults. The closest production proxy for annotation impact: the read-only filtering mode available in one major AI assistant client, which about 17% of users had enabled — roughly doubling tool dispatch rate for those who did. That 17% figure highlights the gap. As action tools have become the majority, the metadata that would let clients distinguish safe reads from risky writes has remained sparse. Consent interfaces cannot be calibrated without it.

Vulnerability Footprint

When most deployed tools write files, execute code, or call external APIs, the attack surface of an MCP deployment grows proportionally. Endor Labs analyzed 2,614 MCP implementations for vulnerability surface in early 2026.

Among those implementations: 82% used file system operations susceptible to path traversal (CWE-22), 67% called APIs with code injection risk, and 34% used patterns susceptible to command injection. These are structural properties of the tool implementations, not fringe edge cases. Public CVE databases recorded 30 MCP-related disclosures in a 60-day window in early 2026, including a CVSS 9.6 remote code execution flaw in a package with nearly 500,000 downloads.

The root pattern is familiar: a new integration surface, rapid adoption before security norms solidified, then a CVE pipeline that starts slow and accelerates. The action-tool majority is what makes the attack payoff significant. Poisoning a read-only tool description might cause an agent to return wrong data, but poisoning an action tool description can cause it to exfiltrate files, send unauthorized messages, or modify production data.

Discovery and the Server Cards Proposal

The proposed MCP Server Cards standard (SEP-2127) would let AI assistants and registries discover server capabilities without establishing a connection, by reading structured metadata from /.well-known/mcp/server-card.json. The proposal has early production implementations: Pipeworx Gateway shipped Server Cards across 811 servers. The 2026 release candidate for the MCP specification formalizes the extensions framework that makes card governance tractable.

Once Server Cards are standardized, the list of tools your MCP server exposes — including which ones take actions — will be indexable without a connection. That is a discoverability win, but it also makes tool description accuracy more consequential: a poisoned description in a card can misdirect agents before they ever connect.

What This Means for Site Owners

If you have deployed an MCP server, start with a tool audit. Separate read-only tools from action tools and confirm that the action tools genuinely need to be externally accessible. Search tools, retrieval tools, and pricing lookups do not need write access to your systems. For action tools that do belong in your MCP server, ensure authentication is enforced at the tool level, not only at session establishment.

Add annotations. The readOnlyHint, destructiveHint, and idempotentHint fields are not decorative metadata — they are the inputs to client consent logic. As MCP clients become more annotation-aware, servers that ship without hints will be treated as maximally risky by default. The annotation gap is solvable: it requires adding a few fields to your tool definitions before shipping.

Treat tool description strings as a security surface. The documented attack pattern is to inject instructions into tool descriptions that manipulate agent behavior. Descriptions should be terse and functional — what the tool does and what its parameters mean — with no open-ended natural language that an adversary could shadow or extend. If you are planning for Server Cards adoption, the same discipline applies to card content: accurate, minimal, and not a vector for injected instructions.