MCP's Remote Revolution: Streamable HTTP, OAuth, and the Path to 18,000 Servers

Executive Summary

Fifteen months after Anthropic open-sourced the Model Context Protocol in November 2024, MCP has completed a transformation from a local-first developer experiment into a cloud-native, enterprise-grade standard for connecting AI agents to tools. Three interrelated shifts define MCP's Q1 2026 posture:

Transport maturation. The replacement of HTTP+SSE with Streamable HTTP in the March 2025 spec created a single-endpoint, stateless-capable transport that works behind load balancers, through proxies, and across organizational boundaries — solving the deployment pain that kept MCP servers trapped on localhost.
Security hardening. OAuth 2.1 with PKCE, dynamic client registration, and mandatory Resource Indicators (RFC 8707) give enterprises the authorization framework they demanded. The June 2025 spec update closed a critical attack surface where a rogue server could trick clients into leaking tokens for other services.
Ecosystem explosion. Community registries now index over 18,000 MCP servers. The official MCP Registry entered preview in September 2025, Cloudflare offers one-click remote deployment, and the Agentic AI Foundation (AAIF) under the Linux Foundation provides neutral governance with OpenAI, Google, Microsoft, and Block as co-founders.

The practical takeaway: MCP is no longer a local convenience for Claude Desktop power users. It is the production wiring layer for enterprise agent systems, and its complementary relationship with Google's Agent-to-Agent (A2A) protocol is crystallizing into a two-layer stack — MCP for tool access, A2A for agent coordination.

Background: The Local-First Era (Nov 2024 - Feb 2025)

When MCP launched with the 2024-11-05 specification, it offered two transports: stdio (for local subprocess communication) and HTTP with Server-Sent Events (for remote connections). In practice, nearly all early adoption used stdio: Claude Desktop spawned MCP servers as child processes, piping JSON-RPC messages over stdin/stdout.

This architecture was elegant for single-user development. A developer could drop an MCP server binary into their Claude config and immediately gain access to databases, file systems, or APIs. But it had fundamental limitations:

No network boundary crossing. Stdio requires the server to run on the same machine as the client.
Single client per server. Each Claude Desktop instance spawned its own server process — no sharing.
No authentication. The 2024-11-05 spec had no standardized auth model, leaving developers to improvise.
No discoverability. Servers were configured by manually editing JSON files with command paths.

The early HTTP+SSE transport attempted to address remote use cases, but it required two separate endpoints (one for connection initialization, one for messages), created sticky session requirements that broke load balancing, and offered no standard security model. Adoption was minimal.

The Streamable HTTP Breakthrough (March 2025)

The 2025-03-26 specification release introduced Streamable HTTP, the single most impactful change in MCP's history. The design is deceptively simple: everything goes through a single /mcp endpoint using standard HTTP POST and GET requests.

How It Works

When an AI agent calls a tool on a remote MCP server, it sends a POST request to the /mcp endpoint. The server has three response options:

Immediate response. For fast operations, the server returns a standard HTTP response with the JSON-RPC result. No streaming, no long-lived connections.
SSE upgrade. For long-running tasks, the server dynamically upgrades the response to an SSE stream, sending progress notifications and the final result over the same request.
Stateless operation. The server can operate without maintaining session state between requests, allowing deployment behind standard load balancers with round-robin routing.

This flexibility is the key innovation. A simple "get current weather" tool responds with a plain HTTP response. A complex "analyze this codebase" tool upgrades to SSE mid-request and streams results over minutes. The client handles both cases transparently.

Why Statelessness Matters

The ability to run MCP servers statelessly fundamentally changes the deployment model. With the old HTTP+SSE transport, servers needed sticky sessions — each client had to keep hitting the same server instance. This made horizontal scaling impractical without session-affinity load balancers.

Streamable HTTP allows deploying multiple MCP server instances behind a standard load balancer. Any instance can handle any request. This maps directly onto existing cloud infrastructure: Kubernetes pods, serverless functions, edge workers. Organizations can scale MCP servers the same way they scale REST APIs — a pattern every DevOps team already understands.

The OAuth Security Layer (March - June 2025)

The 2025-03-26 spec simultaneously introduced a comprehensive authorization framework based on OAuth 2.1. The specification explicitly classifies MCP servers as OAuth resource servers and MCP clients as OAuth clients, reusing battle-tested standards rather than inventing new ones.

Core Security Architecture

The authorization flow works as follows:

The MCP client discovers the server's OAuth metadata via /.well-known/oauth-authorization-server.
The client initiates an OAuth 2.1 flow with PKCE (Proof Key for Code Exchange), which eliminates the authorization code interception vulnerability.
Dynamic client registration allows MCP clients to register with servers they have never connected to before — critical for an open ecosystem where new tools appear daily.
Access tokens are scoped to specific resources using Resource Indicators (RFC 8707).

The Token Leakage Fix (June 2025)

The June 2025 spec update addressed a critical vulnerability discovered in the early OAuth implementation. Without Resource Indicators, a malicious MCP server could potentially trick a client into obtaining an access token that was valid for a different, legitimate server. The fix mandated that clients must include the target resource server URI in token requests, ensuring tokens cannot be replayed across servers.

This class of vulnerability — where a rogue integration point harvests credentials for other services — is exactly the kind of attack that enterprise security teams worry about. Closing it was a prerequisite for serious enterprise adoption.

Tool Annotations for Safety

The March 2025 spec also introduced tool annotations — metadata that lets tools describe their behavior. A tool can declare itself as readOnly, destructive, idempotent, or open-world (produces effects visible outside the agent environment). Clients can use these annotations to enforce policies: automatically approve read-only tools, require human confirmation for destructive ones, or block open-world tools entirely in sandboxed environments.

The Registry and Marketplace Explosion

Official MCP Registry

In September 2025, the MCP project launched the official MCP Registry as a preview. It serves as the primary source of truth for publicly available MCP servers — analogous to npm for Node packages or Docker Hub for container images. Organizations can create sub-registries with custom criteria for curated server sets.

Third-Party Marketplaces (March 2026 Numbers)

The community has not waited for the official registry to mature:

Registry	Server Count	Last Updated
Glama.ai	18,374	March 7, 2026
MCP.so	18,250+	Active
MCP Market	Active directory	Active
LobeHub	Marketplace	Active

The numbers are staggering for a protocol that is barely 15 months old. By comparison, npm took years to reach this density of packages. The low barrier to entry — an MCP server is just a JSON-RPC endpoint exposing tools, resources, and prompts — has enabled rapid community contribution.

Cloudflare's One-Click Deployment

Cloudflare has positioned itself as the default hosting platform for remote MCP servers. Their platform offers:

One-click deployment of pre-built MCP servers on Cloudflare Workers.
Built-in OAuth via workers-oauth-provider, a TypeScript library that wraps Workers code with authorization.
Streamable HTTP support out of the box, with no transport configuration needed.
Python support alongside TypeScript, broadening the developer base.

The combination of serverless deployment and built-in auth removes the two biggest barriers to publishing remote MCP servers. A developer can go from "I have a useful API" to "my MCP server is live and authenticated" in minutes.

Enterprise Adoption Patterns

Scale of Adoption

The numbers tell the story of enterprise momentum:

97M+ monthly SDK downloads across Python and TypeScript.
50+ enterprise partners actively implementing MCP, including Salesforce, ServiceNow, and Workday.
Organizations report 40-60% faster agent deployment times when using MCP versus custom integrations.
Gartner predicts 75% of API gateway vendors and 50% of iPaaS vendors will have MCP features by end of 2026.

Governance Transition

In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation. OpenAI and Block joined as co-founders, with AWS, Google, Microsoft, Cloudflare, and Bloomberg as supporting members. This governance transition was critical for enterprise confidence — organizations are far more comfortable building on a Linux Foundation-governed standard than on a protocol controlled by a single AI vendor.

Enterprise Security Gaps

Despite the progress, enterprises deploying MCP at scale are encountering gaps:

Audit trails. MCP does not yet mandate structured logging of tool invocations. Enterprises need to know exactly which agent called which tool with what parameters and what result was returned — for compliance, debugging, and security forensics.
Over-permissioning. MCP servers often expose all tools to all clients. Fine-grained, role-based tool access is still primarily an application-layer concern.
Observability. Standard telemetry integration (OpenTelemetry spans for MCP calls) is not part of the spec but is needed for production monitoring.

Salesforce's Agentforce platform has started addressing these gaps with enterprise governance layers on top of MCP, and similar patterns are emerging across the ecosystem.

The November 2025 Spec: Agentic Capabilities

The 2025-11-25 anniversary specification release — one year after MCP's launch — added features that move MCP from a tool-calling protocol toward an agentic coordination layer.

Sampling with Tool Calling

Sampling allows MCP servers to request LLM completions from the client. In the original spec, sampling was limited to text generation. The November release added tool calling within sampling, enabling a server to ask the client's LLM to reason about a problem, use tools, and return structured results. This turns the protocol bidirectional in a meaningful way: the server is no longer just a passive tool provider — it can orchestrate multi-step reasoning flows.

Elicitation

Elicitation allows servers to request structured input from users through the client. A server can define a schema describing what information it needs (e.g., "I need a project name, a target date, and a priority level"), and the client presents an appropriate UI for the user to fill in. This enables richer human-in-the-loop workflows where servers can actively request clarification rather than failing on ambiguous inputs.

2026 Roadmap: Servers as Agents

The most forward-looking item on the MCP roadmap is allowing MCP servers to act as agents themselves — connecting to other MCP servers, using tools, and coordinating sub-tasks. This recursive capability, targeted for the tentative June 2026 spec release, would enable complex decomposition patterns: a "project manager" MCP server that delegates code analysis to one server, documentation generation to another, and test execution to a third, all coordinated via the protocol.

MCP + A2A: The Two-Layer Stack

Complementary, Not Competitive

The relationship between MCP and Google's Agent-to-Agent (A2A) protocol has resolved from early "protocol wars" speculation into a clear complementary architecture:

MCP standardizes how agents access capabilities — calling tools, reading resources, executing prompts. It is the agent-to-tool layer.
A2A standardizes how agents collaborate with each other — discovering peers, negotiating tasks, streaming results. It is the agent-to-agent layer.

An enterprise agent system uses both: individual agents use MCP to access their tools (databases, APIs, file systems), and A2A to coordinate with other agents on complex workflows.

Convergence Timeline

Key milestones in the convergence:

Q1 2026: A2A v1.0 stable release alongside continued MCP spec evolution.
February 2026: NIST announced the AI Agent Standards Initiative, focusing on protocol interoperability.
Q3 2026 (projected): First joint MCP/A2A interoperability specification, with major vendors including Google, Anthropic, Microsoft, and Salesforce committed to the effort.

Both protocols now sit under Linux Foundation governance (AAIF for MCP, the A2A Project for Agent-to-Agent), creating institutional alignment for future convergence.

Implications for Agent Platform Builders

Architectural Recommendations

For teams building AI agent platforms in 2026, the MCP evolution suggests several concrete decisions:

Default to Streamable HTTP for remote tool integration. The transport is mature, stateless-capable, and works with existing infrastructure. Reserve stdio for local development and testing only.
Implement OAuth 2.1 with Resource Indicators from day one. Do not defer authorization to "later" — the attack surface is well-understood, and the spec provides a clear implementation path via dynamic client registration and PKCE.
Plan for the MCP Registry. As the official registry matures, agents will discover tools dynamically rather than through static configuration. Design agent architectures that can incorporate new tools at runtime.
Layer A2A on top of MCP. If your system involves multiple agents, adopt A2A for coordination. Do not try to force agent-to-agent communication through MCP tool calls — it works but misses the task lifecycle management that A2A provides.
Invest in observability now. The spec does not mandate it, but production MCP deployments need structured logging of every tool invocation, latency tracking, and error classification. Build this into your MCP client layer from the start.

What to Watch

June 2026 spec release: Expected to include server-as-agent capabilities and finalized Spec Enhancement Proposals from Q1 2026.
MCP Registry GA: The transition from preview to general availability will likely include signing, verification, and trust scoring for servers.
MCP/A2A interoperability spec: The Q3 2026 joint specification could define how an MCP tool invocation can trigger an A2A agent delegation and vice versa.

Conclusion

MCP's evolution over 15 months mirrors the maturation pattern of every successful infrastructure protocol: start simple and local, prove value, then systematically address the security, scalability, and governance requirements of production deployment. The protocol has navigated this arc faster than most — aided by the urgency of the AI agent boom and the pragmatic decision to build on existing standards (OAuth, HTTP, JSON-RPC) rather than inventing new ones.

The current state of MCP — Streamable HTTP for transport, OAuth 2.1 for security, 18,000+ community servers, Linux Foundation governance, and a clear complementary relationship with A2A — represents a protocol that has crossed the threshold from "interesting experiment" to "enterprise infrastructure." The remaining gaps (audit, observability, fine-grained authorization) are being addressed by both the spec process and the vendor ecosystem.

For AI agent builders, the message is clear: MCP is the tool integration layer. Build on it.

Sources: