MCP at 97 Million Downloads: The Protocol's Growing Pains and What Comes Next

The Model Context Protocol has become the fastest-growing developer protocol since GraphQL. With 97 million monthly SDK downloads, 10,000+ active servers, and 2,300+ entries in public directories, MCP is the de facto standard for connecting AI agents to external tools and data sources. Every major AI development tool — Claude Code, Cursor, Copilot, Gemini CLI, Codex — now supports MCP natively.

But scale has brought growing pains. In April 2026, the conversation around MCP is shifting from "how do we adopt it?" to "how do we make it work at scale?" — and for some teams, the answer has been to walk away.

MCP by the Numbers — April 2026

Metric	Value
Monthly SDK Downloads	97 million
Active MCP Servers	10,000+
Public Directory Entries	2,300+
Official Servers	50+
Community Servers	150+
Governance	Linux Foundation (AAIF)
Platinum Members	Google, Microsoft, AWS, Cloudflare, Bloomberg
Supported Clients	Claude Code, Cursor, Copilot, Gemini CLI, Codex, Windsurf

The Context Bloat Problem

The most immediate pain point is context bloat. Every MCP tool a model can access consumes context window tokens — not just when the tool is used, but simply by being available. Tool descriptions, parameter schemas, and usage examples must be loaded into the model's context so it knows what tools exist and how to call them.

Here is what context consumption looks like in practice:

In practice, tool descriptions consume 40–50% of available context tokens when an agent connects to multiple MCP servers. A team running five MCP servers with 20 tools each can lose half their effective context window before the conversation even begins.

This creates a paradox: MCP's value proposition is connecting agents to more tools, but connecting to more tools reduces the agent's ability to reason about complex tasks. The larger the toolbox, the smaller the workspace.

Mitigation Strategies

Strategy	How It Works	Who Uses It
Deferred Tool Loading	Load only tool names; fetch full definitions on-demand	Claude Code
Tool Namespacing	Load only tools from relevant namespaces	Custom implementations
Dynamic Selection	Use conversation context to filter available tools	Experimental
MCP Server Cards	Machine-readable metadata for intelligent filtering	Planned (June 2026)

Claude Code addresses this with deferred tool loading — only tool names are loaded into context initially, with full definitions fetched on-demand when the model references a specific tool. This is effective but requires model-side support for tool search, which not all providers implement.

The broader MCP ecosystem has not converged on a standard approach to context management. There is no specification-level solution yet.

Authentication Friction

MCP's original design assumed local, trusted connections — an MCP server running on the same machine as the client, communicating over stdio. The move to Streamable HTTP as the primary transport opened MCP to network deployments, but authentication was left underspecified.

The 2026 roadmap includes OAuth 2.1 with PKCE as the standard authentication mechanism. Microsoft has contributed support for Entra ID integration with pre-authorized clients. But as of April 2026, authentication implementations vary widely across servers and clients.

This inconsistency creates real friction. A team deploying MCP servers in a corporate environment needs to configure authentication differently for each client that connects — Claude Code, Cursor, Gemini CLI, and internal tools may each handle OAuth flows differently. Some clients don't support OAuth at all, falling back to API key authentication or no authentication.

For teams building agent platforms like Neumar, where MCP is the primary tool integration mechanism, authentication friction is a deployment blocker. Every MCP server added to the platform needs authentication configured for every supported client, creating an O(n*m) integration matrix.

Security Gaps

Authentication is only one dimension of MCP security. The protocol currently lacks several security primitives that production deployments need:

Security Gap	Current State	Risk Level	Expected Fix
Tool-level authorization	Not specified	High	No timeline
Input validation standard	Type-only schemas	High	Under discussion
Audit trail format	Not specified	Medium	Planned
Rate limiting	Not specified	Medium	No timeline
Data classification	Not specified	High	No timeline

No tool-level authorization. MCP authenticates the connection between client and server, but does not provide mechanisms for authorizing specific tool invocations. A user authenticated to an MCP server can call any tool that server exposes, regardless of whether they should have access to that specific capability.

No input validation standard. Tool parameter schemas define types but not security constraints. An MCP tool that accepts a file path parameter has no standard way to restrict that path to a safe directory. Each server must implement its own input validation, and many don't.

No audit trail specification. MCP does not define a standard format for logging tool invocations, making it difficult to build consistent monitoring across heterogeneous MCP deployments.

No rate limiting. There is no specification-level mechanism for rate limiting tool invocations, leaving servers to implement their own throttling logic.

These gaps are not hypothetical. The CVEs disclosed against MCP implementations in 2025 demonstrated that underspecified security leads to inconsistent implementations, and inconsistent implementations lead to exploitable vulnerabilities.

Companies Walking Away

Not everyone is doubling down on MCP. Reports in early 2026 indicate that some companies — including Perplexity — have moved away from MCP internally, citing overhead, authentication friction, and the context bloat problem.

The argument against MCP is straightforward: for teams with a small number of well-defined tool integrations, the overhead of running MCP servers, managing authentication, and paying the context window tax exceeds the benefit of standardized tool definitions. A direct API call is simpler, faster, and consumes no context window tokens.

Factor	MCP Favored	Direct API Favored
Number of tools	Many (10+)	Few (1–3)
Number of AI clients	Multiple providers	Single provider
Tool reusability	Shared across teams	Team-specific
Authentication needs	Standard OAuth patterns	Custom auth
Context budget	Large windows (1M+)	Small windows (128K)
Latency sensitivity	Moderate tolerance	Sub-millisecond

MCP's value increases with the number of tools and the diversity of clients that need to access them. A team with three internal tools and one AI client gets less value from MCP than a platform supporting dozens of tools across multiple AI providers.

The June 2026 Specification Update

The MCP roadmap targets a major specification update in June 2026, developed in collaboration with Google and Microsoft. The planned features directly address the current pain points:

Feature	Problem Solved	Impact
Stateless Server Deployments	Cannot load-balance stateful servers	Cloud-native MCP at scale
Task Capability	No support for long-running workflows	Autonomous agents with retry/expiry
Server-Initiated Triggers	Client-only initiation model	Reactive agent architectures
MCP Server Cards	Context bloat from loading all tools	Intelligent tool subset selection
Retry Semantics	No failure recovery standard	Reliable tool execution
Native Streaming	Batch-only responses	Real-time agent feedback

Stateless server deployments. Currently, MCP servers maintain connection state, which complicates load balancing and horizontal scaling. The June update will standardize stateless server patterns, enabling MCP servers to run behind standard cloud load balancers.

Long-running autonomous workflows. A new "task" capability will support workflows that run for extended periods — minutes to hours — with retry semantics, expiration policies, and native streaming. This moves MCP from request/response tool calling to supporting genuine autonomous agent workflows.

Server-initiated triggers. Currently, MCP is client-initiated: the agent calls a tool, the server responds. Server-initiated triggers will allow MCP servers to proactively notify agents of events — a new file was uploaded, a deployment completed, a ticket was updated — enabling reactive agent architectures.

MCP Server Cards. Standardized metadata discovery through machine-readable server cards will help clients understand what an MCP server provides without loading all tool definitions into context. This directly addresses the context bloat problem by enabling intelligent tool subset selection.

MCP Evolution Timeline

What This Means for Agent Platform Builders

For teams building agent platforms, the current state of MCP requires pragmatic decisions:

Invest in context management. Deferred tool loading, dynamic tool selection, and tool namespacing are not optional optimizations — they're requirements for any deployment connecting to more than a few MCP servers.
Standardize authentication internally. Don't wait for the specification to solve authentication. Pick an auth pattern (OAuth 2.1 + PKCE is the likely standard), implement it consistently across your MCP servers, and build client adapters for the tools your users need.
Plan for June 2026. The specification update will likely require changes to MCP server implementations. Design servers with the expectation that stateless deployment and server-initiated triggers will become baseline requirements.
Keep escape hatches. MCP is the right default for tool integration, but direct API calls remain appropriate for high-frequency, latency-sensitive, or security-critical integrations where the MCP overhead isn't justified.

MCP at 97 million downloads is not a protocol in crisis — it's a protocol experiencing the growing pains of rapid adoption. The question is whether the specification evolution can keep pace with the production demands of the teams building on it.