{"slug": "scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates", "title": "Scaling AI Agent Infrastructure with the MCP Stateless updates", "summary": "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.", "body_md": "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.\n\nBut 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.\n\nTo 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.\n\nToday, 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.\n\nIt’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**.\n\nIn the original protocol model (specification version 2025-11-25) [392], connecting to an MCP server over HTTP required a stateful initialization process:\n\n```\n// POST /mcp - Legacy 2025-11-25 Handshake\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 1,\n  \"method\": \"initialize\",\n  \"params\": {\n    \"protocolVersion\": \"2025-11-25\",\n    \"capabilities\": {},\n    \"clientInfo\": {\n      \"name\": \"my-app\",\n      \"version\": \"1.0\"\n    }\n  }\n}\n```\n\nThe server responded with an `Mcp-Session-Id`\n\nheader. 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.\n\nThis stateful constraint breaks the horizontal scaling models that cloud-native engineers depend on:\n\n`400 Session Not Found`\n\nerror.The new 2026-07-28 specification solves this by making the protocol core completely stateless. **The handshake is gone**. The `initialize / initialized`\n\nhandshake (SEP-2575) and the logical `Mcp-Session-Id`\n\nheader (SEP-2567) have been removed entirely.\n\nInstead, **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`\n\nfield inline on every single request.\n\nHere is how a stateless tool call looks under the new 2026-07-28 specification:\n\n```\nPOST /mcp HTTP/1.1\nHost: mcp-server.example\nMCP-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: search\nContent-Type: application/json\n\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 1,\n  \"method\": \"tools/call\",\n  \"params\": {\n    \"name\": \"search\",\n    \"arguments\": {\n      \"q\": \"otters\"\n    },\n    \"_meta\": {\n      \"io.modelcontextprotocol/protocolVersion\": \"2026-07-28\",\n      \"io.modelcontextprotocol/clientCapabilities\": {},\n      \"io.modelcontextprotocol/clientInfo\": {\n        \"name\": \"my-app\",\n        \"version\": \"1.0\"\n      }\n    }\n  }\n}\n```\n\nWithout 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].\n\nStreamable HTTP POST requests now carry specific HTTP headers:\n\n`Mcp-Protocol-Version`\n\n: The version of the protocol.`Mcp-Method`\n\n: The JSON-RPC method being executed (such as `tools/call`\n\n).`Mcp-Name`\n\n: 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`\n\nheader mismatch code.\n\nBy 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.\n\nTo 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`\n\n(Time-to-Live in milliseconds) and a `cacheScope`\n\n. Clients know exactly how long a `tools/list`\n\nresponse is fresh and whether it is safe to cache across multiple users.\n\nOne 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.\n\n**Multi Round-Trip Requests (SEP-2322)** solves this problem beautifully by restructuring the interaction lifecycle into self-contained steps:\n\nInstead of blocking the thread or holding a connection open, the server immediately returns an `InputRequiredResult`\n\nwith a `requestState`\n\npayload containing serialized context [398]:\n\n```\n// InputRequiredResult Returned from Server\n{\n  \"resultType\": \"inputRequired\",\n  \"inputRequests\": {\n    \"confirm\": {\n      \"type\": \"elicitation\",\n      \"message\": \"Are you sure you want to delete these 3 files?\",\n      \"schema\": {\n        \"type\": \"boolean\"\n      }\n    }\n  },\n  \"requestState\": \"eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0=\"\n}\n```\n\nThe client prompts the user, gathers the boolean answer, and reissues the call with `inputResponses`\n\nand the echoed `requestState`\n\n. Because the `requestState`\n\ncontains everything needed to resume the task, **any server instance behind your load balancer can pick up the retry request**!\n\nSometimes 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.\n\nThe **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`\n\nand kicks off the execution in the background:\n\n```\n// Example: Kicking off an async task in a TypeScript server\nserver.tool(\n  \"process_refund\",\n  { orderId: z.string(), amount: z.number() },\n  async ({ orderId, amount }) => {\n    const taskId = randomUUID();\n    \n    // Store initial task state in a shared datastore (e.g. Redis)\n    await setTaskState(taskId, { status: \"working\" });\n    \n    // Process the refund asynchronously in the background\n    processRefundAsync(taskId, orderId, amount);\n    \n    // Return immediately to keep the conversation flowing\n    return {\n      content: [\n        {\n          type: \"text\",\n          text: JSON.stringify({\n            taskId,\n            status: \"working\",\n            message: `Refund of $${amount} for order ${orderId} is processing. Task ID: ${taskId}`\n          })\n        }\n      ]\n    };\n  }\n);\n```\n\nThe client continues the conversation, telling the user their request is processing, and can poll or subscribe using standard `tasks/get`\n\nand `tasks/update`\n\nprimitives to monitor progress and fetch the final results.\n\nAs 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:\n\n`iss`\n\nparameter on authorization responses, protecting against session hijacking and redirect-based attacks in multi-server architectures.`oneOf`\n\n, `anyOf`\n\n, `allOf`\n\n) 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:\n\n`stderr`\n\nfor `stdio`\n\nconnections, 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.\n\nIn Python, the `MCPServer`\n\ndecorator API is fully compatible [303]. You can install the beta directly with:\n\n```\npip install \"mcp[cli]==2.0.0b1\"\n```\n\nTypeScript v2 replaces the monolithic `@modelcontextprotocol/sdk`\n\npackage with modular, focused libraries to keep your dependencies light. Install them with:\n\n```\nnpm install @modelcontextprotocol/server@beta\nnpm install @modelcontextprotocol/client@beta\n```\n\nA convenient codemod is available to handle standard API renames (like renaming `.tool()`\n\nto `registerTool`\n\n):\n\n```\nnpx @modelcontextprotocol/codemod@beta v1-to-v2 .\n```\n\nThe 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.\n\nThank 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/).\n\nGoogle’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.\n\nBy 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!", "url": "https://wpnews.pro/news/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates", "canonical_source": "https://developers.googleblog.com/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates/", "published_at": "2026-08-05 18:39:14.282804+00:00", "updated_at": "2026-08-05 18:39:16.651611+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "developer-tools"], "entities": ["Google", "Hugging Face", "Model Context Protocol", "MCP Transports Working Group", "SEP-2575", "SEP-2567", "SEP-2243"], "alternates": {"html": "https://wpnews.pro/news/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates", "markdown": "https://wpnews.pro/news/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates.md", "text": "https://wpnews.pro/news/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates.txt", "jsonld": "https://wpnews.pro/news/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates.jsonld"}}