The Session Wall in Cloud-Native AI
Running AI agents in production used to mean fighting fragile network sessions. When Anthropic open-sourced the Model Context Protocol in late 2024, it solved the M×N integration mess. Developers no longer had to craft bespoke API connectors for every database, file system, or SaaS platform. Early adopters like Block and Apollo quickly hooked MCP into their systems, while toolmakers like Zed, Replit, Codeium, and Sourcegraph wired it straight into their editors.
Local setups worked fine over standard input and output streams (stdio). A local desktop application launched a server process, exchanged JSON-RPC messages, and shut it down cleanly. But cloud deployments hit a wall fast. Early remote servers relied on Server-Sent Events (SSE) tied to in-memory session stores.
That architecture failed under load. If an enterprise load balancer routed a request to a sibling container, the task died. Node restarts dropped active sessions, forcing expensive reconnect handshakes and killing execution mid-task. As detailed in our analysis of MCP's stateless session overhaul, stateful servers simply don't scale when thousands of automated clients demand sub-second context access.
Recognizing these operational bottlenecks, lead maintainers David Soria Parra and Den Delimarsky pushed through an enterprise overhaul of the specification. The updated standard strips in-memory session pinning out of remote transport, turning MCP into a cloud-native protocol built for horizontal autoscaling.
Decoupling Context Through Three Core Primitives
The core architecture defined at modelcontextprotocol.io relies on a clean three-layer model split between the host, client, and server.
- MCP Host: The front-end AI application—such as Claude Code, Cursor, or VS Code—that orchestrates context and drives model requests.
- MCP Client: An internal client process managed by the host. It handles a direct 1:1 JSON-RPC session with a target server.
- MCP Server: A standalone program providing context, executing actions, or supplying prompt templates to requesting clients.
According to the official architecture documentation, servers expose their capabilities through three primary primitives:
- Tools: Executable functions that allow models to trigger side effects, such as running SQL queries, deploying cloud infrastructure, or triggering external webhooks.
- Resources: Passive data sources that models read directly into context, including application logs, configuration trees, or file system nodes.
- Prompts: Standardized workflow templates that structure how users and automated agents kick off complex, multi-step operations.
Under the updated data layer, servers announce these capabilities during a mandatory discovery sequence (server/discover). Before executing any tool or reading a resource, the client exchanges metadata with the server to agree on capabilities and versioning upfront. This clear separation ensures hosts stay decoupled from the backend logic powering individual servers.
Streamable HTTP and Per-Request Session Metadata
The biggest technical shift in the new specification is the migration from legacy SSE to Streamable HTTP. Legacy SSE forced servers to keep stateful connection objects open in application memory. Streamable HTTP moves that burden entirely into the request payload.
Every JSON-RPC 2.0 request now carries its state inside a standardized _meta field. This payload includes protocol versioning, capability flags, and specific request identifiers.
Because every incoming HTTP POST request contains its own operational context, remote servers behave like stateless microservices. A Kubernetes ingress controller can round-robin incoming agent traffic across dozens of server pods without session affinity rules. If a server pod terminates unexpectedly mid-workflow, the next available replica picks up the incoming request without failing the agent's task.
+-------------------+ +-----------------------+
| MCP Host | | Stateless Load |
| (Claude Code / | | Balancer / Ingress |
| Cursor IDE) | +-----------+-----------+
+---------+---------+ |
| HTTP POST (JSON-RPC + _meta) | Round-Robin
+---------------------------------->+
|
+--------------------------+--------------------------+
| |
v v
+-------------------------+ +-------------------------+
| Remote MCP Server Pod A | | Remote MCP Server Pod B |
| (Stateless Handler) | | (Stateless Handler) |
+-------------------------+ +-------------------------+
As highlighted in technical implementation guides on DEV Community, this stateless model has powered massive adoption. Monthly SDK downloads surpassed 97 million, with over 200 production servers connecting tools like PostgreSQL, GitHub, Slack, and AWS. By standardizing session creation and migration across Streamable HTTP, maintainers eliminated the main bottleneck holding back production agent clusters.
OAuth 2.1 and Resource Indicators for Enterprise Rigor
Connecting autonomous agents directly to internal enterprise data sources creates massive security exposure. Handing an unauthenticated server full database access invites disaster. As discussed in our research on action-based governance for enterprise agents, relying on simple identity scope is insufficient without robust authorization controls. The updated specification fixes this by mandating OAuth 2.1 for all remote Streamable HTTP endpoints.
Under this security model, remote MCP servers function as OAuth Resource Servers. When an MCP client initiates a connection, it queries standardized .well-known endpoints to discover authorization endpoints and security requirements. Public clients—such as browser-based AI assistants—must use Proof Key for Code Exchange (PKCE) with SHA-256 code challenges (S256). Plaintext code challenges are explicitly banned by the standard.
To stop token theft and relay attacks in multi-tenant cloud setups, the standard enforces RFC 8707 Resource Indicators. When an agent requests an access token from an enterprise Identity Provider (IdP) like Okta or Entra ID, the token is explicitly scoped to a target server URI (resource="https://mcp.example.com/v1").
{
"authorization_endpoint": "https://auth.example.com/authorize",
"token_endpoint": "https://auth.example.com/token",
"grant_types_supported": ["authorization_code"],
"code_challenge_methods_supported": ["S256"],
"resource": "https://mcp.example.com/v1",
"scope": "tools:read tools:execute resources:read"
}
If a rogue agent tries to replay that token against a different internal service, the target server drops the request instantly. Furthermore, as we noted in our coverage on securing IDEs against rogue servers, strict token scoping and input validation prevent malicious repositories from hijacking tool channels.
Interactive Elicitation and the Multi-Agent Ecosystem
Beyond basic tool calls and resource fetching, real-world workflows require bidirectional communication. The spec defines two specific patterns for handling interactive decisions during execution:
- Elicitation: Allows a server to send a reverse request back to the host, asking the end user for explicit input or confirmation before proceeding.
- Sampling: Enables a server to request an inference cycle from the host LLM mid-task when context parsing or reasoning is required.
Elicitation provides a critical safety valve for high-risk actions. Imagine a database migration server running an automated schema update. If the tool encounters a destructive operation—like dropping a column with live production records—it issues an elicitation request back to the user interface. Execution halts until a human operator confirms the change.
As the ecosystem expands, MCP operates alongside complementary protocols like Google's Agent-to-Agent (A2A) standard. In late 2025, industry leaders formed the Agentic AI Foundation under the Linux Foundation to govern both projects. The distinction between them is sharp:
| Protocol Feature | Model Context Protocol (MCP) | Agent-to-Agent (A2A) |
|---|---|---|
| Primary Focus | Agent-to-Tool / Data Integration | Agent-to-Agent Coordination |
| Architectural Role | "USB-C" port for external tools | "TCP/IP" layer for multi-agent messaging |
| Protocol Base | JSON-RPC 2.0 over stdio & Streamable HTTP | JSON-RPC 2.0 & gRPC |
| Discovery Mechanism | server/discover & MCP Server Cards | Signed Agent Cards |
| Security Layer | OAuth 2.1 + PKCE + RFC 8707 | OAuth 2.1 Multi-Tenant Governance |
In modern cloud environments, individual agents rely on MCP to fetch internal context and execute specialized tools, then communicate across agent boundaries using A2A.
The enterprise roadmap through late 2026 targets automated server discovery through standardized MCP Server Cards, native enterprise IdP integrations, and a central MCP Registry featuring verified server directories and audited security SLAs. By removing stateful connection limits and enforcing OAuth 2.1 standards, David Soria Parra and Den Delimarsky have positioned MCP as the core plumbing for enterprise AI systems.