177,000 AI Agent Tools. Zero Authentication. The MCP Ecosystem Has a Problem.

The first real census of the agent tool ecosystem tells a story of explosive growth, a structural shift toward action, and a security gap that should worry anyone building with agents today.

Someone finally counted.

As of February 2026, the Model Context Protocol ecosystem contains 177,436 distinct agent tools spread across 19,388 verified MCP servers. That number was roughly 4,888 in January 2025. If you’re keeping score, that’s about 35x growth in 13 months.

On the same day that census was published, a separate researcher reported scanning approximately 2,000 internet-exposed MCP servers for authentication. The result: none of them had it.

Two papers. Same day. One says the boomtown is thriving. The other says nobody installed locks on the doors.

What You’ll Learn in This Article:

• The First Census: The MCP agent tool ecosystem has exploded to 177,000 tools with 97M+ monthly SDK downloads, and someone finally mapped what’s inside it
• The Action Shift: Agents are rapidly moving from perception tools (reading data) to action tools (modifying environments), with action usage jumping from 27% to 65%
• The Security Gap: A scan of ~2,000 MCP servers found all lacked authentication, and even OAuth won’t solve the deeper delegation problem
• A Proposed Fix: The Agent Identity Protocol (AIP) introduces Invocation-Bound Capability Tokens, the first cross-protocol identity solution designed for multi-hop agent workflows

Act 1: The First Census of Agent Tools

Think of the MCP ecosystem like a frontier boomtown. Buildings going up on every block, the economy booming, population growing faster than anyone can track. That’s roughly where we are, and the “177,000 MCP tools” study from Merlin Stein (arXiv: 2603.23802) is the first serious attempt to take a census.

The research team built their dataset from three primary sources: a GitHub search for repos mentioning “mcp server,” the Smithery MCP registry, and curated server lists including the official MCP repo list. After filtering and an LLM-based validity check, they verified 19,388 servers exposing 177,436 tools.

But the growth curve is actually the less interesting part. The structural change underneath it matters more.

The Taxonomy: Perception, Reasoning, Action

The paper classifies every tool into three categories based on what it does to the world. Here’s the simplest way to think about it.

Imagine an agent helping you manage customer support tickets. A perception tool reads the ticket. A reasoning tool classifies the priority. An action tool assigns it to an engineer and updates the CRM.

The first two are information tools. They look at the world. The third one changes it.

And here’s the finding that should get your attention: action tool usage rose from 27% to 65% of download-weighted usage over roughly 16 months. Among tools published by registered commercial entities, the shift was even more dramatic, from 21% to 71%.

The boomtown isn’t just growing. Its economy is changing. The population is shifting from shopkeepers who sell information to construction crews who change the landscape.

The Software Development Concentration (and Why You Should Squint at It)

The study reports that 67% of tools target software development and IT tasks, and software accounts for about 90% of download-weighted usage.

That’s a striking number, but it deserves a raised eyebrow. The paper itself provides reasons for caution.

Usage distribution is extremely concentrated. On NPM, the top 1% of servers cover 79.3% of all downloads. On PyPI, the top 1% cover 42.9%. A small misclassification among those “superstar” servers could swing the category breakdown significantly.

There’s also a more fundamental question: is software the killer use case for agents, or is it just where the tool builders happen to be? MCP developers building tools for themselves will naturally create software development tools first. The 67% number might tell us more about who is publishing servers than about where agents will ultimately create the most value.

The most honest read of the data: the public MCP tool ecosystem is software-centric today. But action-tool growth in areas like finance, payments, and customer service suggests the action surface is widening, and anyone designing security architecture should assume “broader-than-software” impact is coming soon rather than later.

Open Environments and Risk

One more finding worth pulling out: the paper separately classifies tools by whether they operate in constrained or unconstrained environments. General-purpose tools grew from 41% to 50% of download-weighted share. And 94% of general-purpose server downloads involved action capabilities.

Action tools plus unconstrained environments. That’s exactly the combination where identity, delegation, and auditability failures get operationally dangerous. The tool surface is broad, the environment is unpredictable, and the blast radius is harder to contain.

Act 2: Nobody’s Checking IDs at the Door

On the same day the census was published, Sunil Prakash released “AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A” (arXiv: 2603.24775). The paper opens with a blunt observation: of approximately 2,000 internet-exposed MCP servers scanned, all lacked authentication.

Independent reporting from Dark Reading corroborates the picture, describing 1,862 internet-exposed MCP servers identified, with manual testing of a subset (119) finding none requiring authentication for a basic “tools/list” request.

Two clarifications before anyone panics.

First, these scans target internet-exposed servers, not every MCP deployment. Many servers are local, stdio-based, or internal. The takeaway isn’t “every MCP deployment is wide open.” It’s that the ecosystem has enough unauthenticated, exposed servers to create a real attack surface, and the defaults have historically encouraged insecure exposure.

Second, and this is the subtler point: “authentication exists” is not the same as “delegation identity is solved.” Even when a client authenticates to a server via OAuth 2.1 (which MCP’s spec now supports), multi-agent delegation still needs provenance. Who delegated what? What was attenuated at each hop? Is this downstream call legitimately “on behalf of” the original principal?

A Concrete Attack Scenario

Here’s what the gap looks like in practice.

Agent A is authorized to read your calendar. It delegates to Agent B, which claims it can book meetings on your behalf. Agent B actually has no authorization for booking, but there’s no mechanism to verify this. So Agent B books a meeting, accesses your contacts, and forwards them to an external server.

Every individual component might have its own auth. But the chain of delegation has no verification, no attenuation enforcement, and no audit trail.

This is the problem AIP is trying to solve.

Act 3: Invocation-Bound Capability Tokens

AIP’s answer to the delegation problem is a single object designed to answer five questions at once: who authorized this action? Which agents were involved? What constraints applied at each hop? What was the outcome? Can all of this be independently verified?

The object is called an Invocation-Bound Capability Token (IBCT).

Think of it as a signed permission slip that records exactly what you were authorized to do and who authorized you. Every time authority passes to another agent, a new entry gets appended to the chain. The chain can only reduce permissions, never expand them. And every entry is cryptographically signed.

How Identity Works

AIP defines two flavors of identity.

DNS-based identities look like aip:web:example.com/agent-a and resolve via a well-known HTTPS endpoint returning an identity document. This works when you have a domain and want discoverability.

Self-certifying identities look like aip:key:ed25519:<multibase> where the public key is the identifier. No resolution step needed. This works for ephemeral agents or scenarios where you want identity without infrastructure.

Both types sign their identity documents with Ed25519, making tampering detectable independent of transport.

Two Wire Formats: Simple and Chained

This is where the implementation gets practical. AIP defines two modes, and the choice depends on how many hops your delegation chain involves.

Compact mode uses a signed JWT for single-hop cases. If you’re making a simple API call, one agent calling one tool, a JWT is fine. It’s a signed envelope that says “I’m authorized to do X.”

Chained mode uses Biscuit tokens for multi-hop delegation. If Agent A delegates to Agent B, which delegates to Agent C, you need a chain of signed envelopes where each one references the one before it and can only contain a subset of the original permissions. That’s what Biscuit tokens give you. They use Datalog (a logic language) for policy evaluation, which means constraints can be expressed as actual rules rather than just flag checks.

Why Not Just Use OAuth?

Fair question. MCP is already converging on OAuth 2.1 for single-hop authorization, and it’s real progress. Clients authenticate to servers, PKCE is required, metadata checks are enforced.

But OAuth solves client-to-server access. It doesn’t natively encode “append-only delegation semantics where each hop can only reduce authority without contacting the issuer.”

OAuth 2.0 Token Exchange (RFC 8693) gets closer. It defines a mechanism for obtaining new tokens by presenting existing ones. But it typically requires an authorization server round-trip to mint the new token. AIP emphasizes holding-side attenuation without contacting the issuer, and local verification rather than network-dependent checks.

The honest framing: OAuth and AIP solve adjacent problems. OAuth handles “can this client access this resource?” AIP handles “how did authority flow through a chain of agents to reach this specific action, and was it properly constrained at every step?”

Performance: Is the Overhead Worth It?

AIP reports sub-millisecond verification overhead in both modes. Compact mode runs at about 0.049 ms in Rust, 0.189 ms in Python. In real HTTP tool-call measurements, the overhead above a “no auth” baseline lands around 0.22 ms for compact mode and 0.18 ms for chained mode.

For chained mode, token size and verification time scale linearly with depth, staying under 1 ms at the recommended maximum depth.

Given that a typical LLM inference call takes hundreds of milliseconds to several seconds, identity verification overhead is effectively invisible.

The paper also reports adversarial testing across 600 attempts spanning six attack categories, with a 100% rejection rate. Notably, it identifies two attack types that plain JWT deployments miss: delegation depth violations and “audit evasion” via empty context strings.

The Gap Test: What Both Papers Don’t Tell Us

Good research is honest about its limits, and both papers have them.

The 177K study gives us the best picture we have of the MCP tool ecosystem, but it measures installations, not runtime tool invocations. “Action tools are 65% of downloads” means the installed ecosystem is increasingly action-capable. It doesn’t mean 65% of all tool calls in the world are action calls. The paper also excludes major deployment channels like hosted connectors, mirrored installs, and cached dependencies. Production usage is almost certainly undercounted.

AIP is technically sound but has a hard adoption problem. As of April 2026, it has an arXiv preprint, an alpha-stage PyPI package (version 0.1.1, released April 2), and individual IETF drafting activity. Neither Anthropic (which created MCP) nor Google (which created A2A) has endorsed it. The PyPI metadata explicitly labels the development status as “Alpha.”

For identity protocols, the hard question is coordination and convergence, not correctness. A technically perfect protocol with no adoption is an academic exercise.

That said, the ecosystem clearly knows authentication is a problem. The MCP Dev Summit (April 2–3, 2026) dedicated multiple sessions to authentication and security. Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation in late 2025, signaling a move toward vendor-neutral governance. These are the institutional patterns that mature protocols develop.

The question isn’t whether agent identity will get solved. It’s which solution the ecosystem converges on, and how much damage happens in the gap between “we know this is a problem” and “we’ve adopted a standard.”

What This Means for Builders

If you’re building MCP tools or deploying agents with action capabilities, three practical takeaways.

Design for identity now. Assume authentication and delegation verification are coming. Build your tool schemas with identity-aware interfaces. Add stable request IDs and context-binding fields, even if nothing checks them yet. Retrofitting provenance into opaque tool execution is much harder than building it in from the start.

Respect the action shift. When agents could only read data, a permissions failure meant information leaked. When agents modify databases, send emails, deploy code, and manage customer accounts, a permissions failure means real-world damage. The risk model has structurally changed, and your security architecture should reflect that.

Watch the governance layer. The technical solutions exist. AIP is one proposal. OAuth 2.1 plus token exchange is another direction. SPIFFE-style workload identity is a third. The real variable is which of these the ecosystem standardizes on. Follow the Agentic AI Foundation, the MCP Dev Summit outputs, and the IETF drafting activity. That’s where convergence will (or won’t) happen.

The Boomtown Needs a Sheriff

The story of these two papers, published on the same day, is the story of a technology that grew up faster than its infrastructure. 177,000 tools. 97 million monthly SDK downloads. A structural shift from observation to action. And an identity layer that’s still in alpha.

The boomtown is real. The economy is booming. The construction crews are outnumbering the shopkeepers.

But the sheriff’s office is still under construction.

The protocol stack is growing up. The question is whether identity and delegation can mature fast enough to match the action capabilities the ecosystem is already deploying. The research says the gap is real, the solutions exist in prototype, and the window for getting this right is closing.

Build accordingly.