Scaling AI Agent Infrastructure with the MCP Stateless updates

Google, Hugging Face, and other industry partners released the 2026-07-28 Model Context Protocol specification candidate, which removes transport-level session management to make the protocol stateless and scalable on ordinary HTTP load-balanced infrastructure. The update eliminates the initialize/initialized handshake and the Mcp-Session-Id header, replacing them with self-describing requests that include protocol version and client info in a _meta field on every request. This is the biggest change to the MCP spec since its launch, enabling enterprise-scale deployment across millions of concurrent queries on Google Cloud.

As you deploy agentic workflows and scale up your users, your bottlenecks change. When the Model Context Protocol MCP was first introduced in late 2024, it provided an elegant, session-oriented framework that allowed LLMs to negotiate capabilities, invoke external tools, and retrieve contextual resources. It was perfect for a single client talking to a single server on a local machine and optimized for stdio. But when we at Google began deploying MCP servers across our cloud-native infrastructure, we hit a hard wall. The original protocol-level session model required persistent state, handshakes, and session pinning. In short, it was built on stateful transports that broke the core tenets of modern cloud-native scalability. To solve this, Google led the charge https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575 to decouple the protocol from stateful transport constraints. Our teams needed MCP to scale across millions of concurrent queries on Google Cloud, and we knew that you all needed MCP to be ready for real-world enterprise scale too. Working closely with Hugging Face and other industry partners, we co-founded the MCP Transports Working Group. Today, we are thrilled to celebrate the culmination of that work: the 2026-07-28 Model Context Protocol specification release candidate , which is already being widely adopted https://aaif.io/blog/the-ecosystem-responds-to-stateless-mcp . This landmark release removes transport-level session management entirely, giving you a stateless protocol core that scales on ordinary HTTP load-balanced infrastructure. It’s the biggest change to MCP spec since launch, and if you don’t read the rest of this article, rest assured, it’s a change for the better - more scale, more secure, just as easy . In the original protocol model specification version 2025-11-25 392 , connecting to an MCP server over HTTP required a stateful initialization process: // POST /mcp - Legacy 2025-11-25 Handshake { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-11-25", "capabilities": {}, "clientInfo": { "name": "my-app", "version": "1.0" } } } The server responded with an Mcp-Session-Id header. To make any subsequent tool call or resource query, the client had to include that unique session ID on every request, pinning the client to the specific container or pod that held its in-memory session state. This stateful constraint breaks the horizontal scaling models that cloud-native engineers depend on: 400 Session Not Found error.The new 2026-07-28 specification solves this by making the protocol core completely stateless. The handshake is gone . The initialize / initialized handshake SEP-2575 and the logical Mcp-Session-Id header SEP-2567 have been removed entirely. Instead, every request is now self-describing and independent . Protocol version, client info, and client capabilities that used to be exchanged once at connection setup now travel in a meta field inline on every single request. Here is how a stateless tool call looks under the new 2026-07-28 specification: POST /mcp HTTP/1.1 Host: mcp-server.example MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" }, " meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientCapabilities": {}, "io.modelcontextprotocol/clientInfo": { "name": "my-app", "version": "1.0" } } } } Without protocol sessions, we needed standard mechanisms to route and govern traffic efficiently. Working under the Transports Working Group, we helped design SEP-2243 HTTP Standardization 302, 542 . Streamable HTTP POST requests now carry specific HTTP headers: Mcp-Protocol-Version : The version of the protocol. Mcp-Method : The JSON-RPC method being executed such as tools/call . Mcp-Name : The specific tool, prompt, or resource name being invoked.These headers are mirrored to match the JSON-RPC body. If they disagree, the server rejects the request with a -32020 header mismatch code. By promoting these values to standard HTTP headers, proxies, gateways, and load balancers can route, rate-limit, and audit traffic without inspecting the request body . For security and logging teams, this is a massive win that drastically lowers the latency and processing overhead at the gateway layer. To eliminate the need for long-lived Server-Sent Events SSE connections just to monitor if a tool or prompt list changed, the spec introduces caching fields modeled after HTTP's Cache-Control. Tool and resource results can now return a ttlMs Time-to-Live in milliseconds and a cacheScope . Clients know exactly how long a tools/list response is fresh and whether it is safe to cache across multiple users. One of the most complex challenges we faced in a stateless world was how to handle server-to-client requests. Under previous versions, if an MCP server needed user clarification an "elicitation prompt" or a confirmation during a tool call, it had to keep an SSE connection open to push that request to the client. Multi Round-Trip Requests SEP-2322 solves this problem beautifully by restructuring the interaction lifecycle into self-contained steps: Instead of blocking the thread or holding a connection open, the server immediately returns an InputRequiredResult with a requestState payload containing serialized context 398 : // InputRequiredResult Returned from Server { "resultType": "inputRequired", "inputRequests": { "confirm": { "type": "elicitation", "message": "Are you sure you want to delete these 3 files?", "schema": { "type": "boolean" } } }, "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0=" } The client prompts the user, gathers the boolean answer, and reissues the call with inputResponses and the echoed requestState . Because the requestState contains everything needed to resume the task, any server instance behind your load balancer can pick up the retry request Sometimes a tool call simply takes a long time to run. A database backup, a CRM sync, or a refund through a payment gateway can take anywhere from 10 to 60 seconds. Holding the client connection open blocks the customer conversation and creates massive connection queues. The Tasks Extension graduates from an experimental feature to a robust, first-class protocol extension. Now, when a client calls a long-running tool, the server immediately returns a taskId and kicks off the execution in the background: // Example: Kicking off an async task in a TypeScript server server.tool "process refund", { orderId: z.string , amount: z.number }, async { orderId, amount } = { const taskId = randomUUID ; // Store initial task state in a shared datastore e.g. Redis await setTaskState taskId, { status: "working" } ; // Process the refund asynchronously in the background processRefundAsync taskId, orderId, amount ; // Return immediately to keep the conversation flowing return { content: { type: "text", text: JSON.stringify { taskId, status: "working", message: Refund of $${amount} for order ${orderId} is processing. Task ID: ${taskId} } } }; } ; The client continues the conversation, telling the user their request is processing, and can poll or subscribe using standard tasks/get and tasks/update primitives to monitor progress and fetch the final results. As the responsibility of managing state shifts from the transport layer to the application layer, security becomes paramount. The 2026-07-28 spec delivers several crucial security enhancements: iss parameter on authorization responses, protecting against session hijacking and redirect-based attacks in multi-server architectures. oneOf , anyOf , allOf and local $ref definitions, making parameters highly descriptive and strictly validated.For the first time, MCP now has a formal deprecation policy. Features move through a structured Active - Deprecated - Removed lifecycle with a minimum 12-month transition window . Three features enter deprecation today: stderr for stdio connections, or OpenTelemetry for structured cloud observability.All four Tier-1 SDKs TypeScript, Python, Go, and C already have beta releases available supporting the 2026-07-28 specification. We highly encourage you to start testing these in your staging environments today. In Python, the MCPServer decorator API is fully compatible 303 . You can install the beta directly with: pip install "mcp cli ==2.0.0b1" TypeScript v2 replaces the monolithic @modelcontextprotocol/sdk package with modular, focused libraries to keep your dependencies light. Install them with: npm install @modelcontextprotocol/server@beta npm install @modelcontextprotocol/client@beta A convenient codemod is available to handle standard API renames like renaming .tool to registerTool : npx @modelcontextprotocol/codemod@beta v1-to-v2 . The 2026-07-28 specification marks a watershed moment for the Model Context Protocol, transitioning it from a promising local integration layer into the foundational, open infrastructure for enterprise AI applications. Thank you to the huge effort from all of the MCP Transports Working Group https://github.com/modelcontextprotocol/transports-wg/blob/main/GOVERNANCE.md members and other teams who worked to make this happen, from across many companies. Thanks also to the Google team who maintain the Go MCP SDK https://github.com/modelcontextprotocol/go-sdk and shipped v1.7.0 https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.7.0 on July 28th which was ready on launch day and powers major integrations like Github MCP Server https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/ . Google’s push for stateless transports was born out of necessity. We needed a protocol robust enough to handle the massive scale of our global developers, and we wanted to ensure that every developer, whether building on Google Cloud or anywhere else, had access to highly reliable, secure, and infinitely scalable agentic infrastructure. By decoupling state from the transport layer, we have made load balancing boring, autoscaling seamless, and serverless deployment a reality. We can’t wait to see the incredibly scalable AI agents you build on top of this new stateless foundation