MCP's Tool Mix Has Inverted: 65% of Agent Tools Now Modify External State

Between January 2025 and February 2026, the number of MCP servers capable of executing financial payments grew from 47 to 1,578. In the same 13 months, the proportion of all MCP tool calls classified as direct environmental actions — file writes, API submissions, database updates, transaction executions — rose from 27% to 65%. A protocol that looked like a read-only data access layer is now, by the weight of its actual tool calls, action-taking infrastructure. Forty-one percent of the publicly listed servers running that infrastructure have no authentication.

Method

This post draws on three sources. First, a March 2026 arXiv preprint (arXiv:2603.23802) by a researcher at the UK AI Security Institute and the University of Oxford, which analyzed 177,436 MCP tools created in public server repositories from November 2024 through February 2026 and classified each by environmental impact. Second, the Zuplo State of MCP Report, surveying MCP builders from mid-November to mid-December 2025 on authentication, production readiness, and adoption pace. Third, TapAuth's February 2026 direct scan of 518 publicly reachable MCP endpoints, measuring authentication presence at the protocol layer.

The Read/Write Inversion

The Model Context Protocol launched in late 2024 as a structured interface for AI assistants to query data: read a database, search a knowledge base, retrieve a file. Early adopters built data-access layers. Tool calls were predominantly perception-type — read without modifying.

By February 2026, that profile had inverted. Action tools, which directly modify external state, grew from 27% to 65% of all tool calls across 177,436 analyzed tools. Software development is the dominant MCP category, accounting for 67% of all tools and roughly 90% of server downloads. Development tools are action-type by function: they edit source files, run tests, push commits, trigger deployments. As developer tooling came to dominate MCP deployments, the aggregate tool-use profile shifted from read-heavy to write-heavy.

The structural implication is direct: agent tool calls are no longer predominantly observable and reversible. Most MCP activity in early 2026 modifies something in the world. The question of what authorization model governs those modifications is not abstract — it is a live operational question for every MCP server exposed to external agents.

Payment-Capable Servers: 33x Growth in 13 Months

In January 2025, 47 MCP servers listed payment execution capabilities — tools that could initiate a financial transfer on behalf of a user. By February 2026, that number had grown to 1,578: a 33-fold increase in 13 months. Many of these servers enable cryptocurrency transactions, where executions are irreversible by design.

The same analysis reports that AI-generated code now appears in 28% of all observed MCP servers and in 62% of servers newly created in February 2026. An ecosystem where the majority of newly created server code is machine-generated and the dominant tool category modifies external state is one that scales both capability and risk faster than typical software deployment cycles.

The Authentication Gap

TapAuth's direct scan of 518 publicly reachable MCP servers in early 2026 found 41% with no authentication at the protocol layer. Zuplo's broader review of 17,000+ listed servers independently reached the same figure. Among builders actively developing MCP servers, the Zuplo survey found that 24% reported running at least one server with no auth, 50% named security and access control as their top challenge, and 38% said security concerns were actively blocking their organizations from expanding MCP adoption.

The numbers reflect a structural issue beyond individual misconfiguration. MCP server registries aggregate public endpoints indiscriminately. A development server with a test endpoint that was never intended for production can appear in the same registry listing as a deployment serving live agent queries. The 41% with no authentication are not uniformly reckless — some are development or internal servers accidentally exposed at a public address. From the perspective of an AI agent discovering endpoints via a registry, an unauthenticated endpoint is indistinguishable from an authenticated one until a call is attempted.

Discovery: Still No Standard

The .well-known/mcp.json path for automated server discovery remains non-standard. An IETF Internet-Draft (draft-serra-mcp-discovery-uri) defines an "mcp" URI scheme and a well-known discovery mechanism, but as of March 2026 the draft was at revision 04 and had not yet reached RFC status. The MCP specification includes enhancement proposals for structured server cards via .well-known, but these are proposals rather than ratified specification elements.

In practice, MCP server discovery in 2026 operates through human-curated registries — aggregators that index servers submitted by their operators. Automated discovery of MCP capability from a domain name alone is not yet possible in a standardized way. Manual registration with aggregators is the operative mechanism for any server that wants to be discoverable.

What This Means for Site Owners

The read/write inversion changes the risk profile of MCP exposure. A read-only tool that returns product data carries bounded risk — the worst case is stale or incorrect information returned to an agent, with no external state changed. A write-capable tool that submits orders, modifies records, or executes transactions against an unauthenticated endpoint is a different category entirely. Operators who built MCP servers in early 2025 under the assumption that tools were mostly read-type should audit their current exposure: what proportion of their tools are action-type, what those tools can modify, and whether authentication gates those operations.

Authentication gaps in MCP servers often have straightforward remediation. The Zuplo survey found that 58% of builders are wrapping existing APIs rather than building new ones — meaning most MCP servers sit in front of an API layer that already handles access control. The gap between an existing API with authentication and an MCP server that exposes auth-gated tools is frequently a configuration step rather than a re-architecture. The protocol supports OAuth 2.0 and API key authentication natively; servers lacking both are not constrained by technical limitations of the standard.

For discovery: publishing a .well-known/mcp.json file is low-cost and positions a server for the expected standardization outcome as the IETF draft progresses. It does not currently drive automated discovery from major agent frameworks. Registering with established aggregators — the official MCP Registry, PulseMCP, Smithery — is the mechanism that drives actual agent discovery today. Both steps are worth taking; neither alone is sufficient.