Preface¶

The Model Context Protocol (MCP) is an open protocol that connects large language models with external tools and data sources. Since the launch of Remote MCP in late 2024, it has quickly become one of the de facto standards for Agent toolchains. Official blog data shows that Tier 1 SDKs have nearly 500 million monthly downloads, and the cumulative downloads of TypeScript and Python SDKs have both exceeded 1 billion.

On July 28, 2026, the MCP maintenance team officially released the 2026-07-28 specification. This is the largest protocol revision since the launch of Remote MCP: the core of the protocol has changed from a bidirectional stateful model to a stateless request/response model, removing the initialize/initialized handshake and the Mcp-Session-Id session header. For developers deploying Remote MCP Servers, this means servers can be horizontally scaled behind a load balancer like regular HTTP services, without needing to maintain sticky sessions or shared Session Stores.

This article sorts out the core content and implementation impact of this change, based on the MCP official launch blog, Release Candidate notes, and the original text of SEP-2567.

From Stateful to Stateless: What Changed at the Protocol Layer¶

In the 2025-11-25 specification, calling tools via Streamable HTTP required first establishing a session:

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

The server would return an Mcp-Session-Id, which had to be included in every subsequent request, locking the client to the exact instance that issued the Session. For horizontal scaling, gateways needed sticky routing, and backends often required shared Session storage.

The 2026-07-28 version condenses a single tool call into a single self-describing request that any instance can process (SEP-2567, SEP-2575):

POST /mcp HTTP/1.1
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/clientInfo":{"name":"my-app","version":"1.0"}}}}

The changes can be summarized in three points:

Handshake removed: The initialize/initialized exchange is no longer required; protocol version, client identity, and capabilities are now carried in the _meta field of each request.
Session header deleted: Mcp-Session-Id has been removed from the specification, and the protocol layer no longer maintains session lifecycles.
Optional discovery: If a client needs to learn server capabilities in advance, it can call the new server/discover RPC; not calling it will not affect subsequent requests.

Horizontal Scaling: Why This Matters for Production Deployments¶

The Release Candidate document summarizes the direct production benefits in one sentence: Remote MCP Servers no longer require sticky Sessions, shared Session Stores, or deep packet inspection of JSON bodies on gateways; regular round-robin load balancers can distribute traffic, gateways can route by the Mcp-Method header, and list responses like tools/list can also be cached based on the ttlMs declared by the server.

This aligns with the analysis in SEP-2567. Under the old model, the results of tools/list, resources/list, and prompts/list may vary across Sessions (for example, the tool list only appears after calling connect_database), so clients cannot safely reuse caches across Sessions. Orchestrators repeat pulling tool lists from each Server for every sub-Agent, with overhead reaching O(number of sub-Agents × number of Servers). After Sessions are removed, lists are decoupled from Sessions, and combined with the ttlMs and cacheScope hints introduced in SEP-2549, the tool directory of the same Server can be cached and reused across sub-Agents, reducing complexity to O(number of Servers).

Streamable HTTP transport also requires requests to carry the Mcp-Method and Mcp-Name headers (SEP-2243), which must match the method/name in the body. Load balancers, API gateways, and WAFs can directly分流 and rate-limit based on the headers without parsing JSON.

No Session Does Not Mean Stateless Applications: Explicit State Handles¶

Removing protocol-layer Sessions does not mandate stateless business logic. The pattern recommended by SEP-2567 is consistent with common practices for HTTP APIs: tools explicitly create and return state identifiers, which the model passes back as regular parameters in subsequent calls.

A typical implementation is as follows—the server provides create_basket, which returns a basket_id, and subsequent add_item calls carry that ID:

// tools/call → create_basket
{ "name": "create_basket", "arguments": {} }

// ← Response
{ "structuredContent": { "basket_id": "bsk_a1b2c3" } }

// tools/call → add_item
{ "name": "add_item", "arguments": { "basket_id": "bsk_a1b2c3", "sku": "shoes" } }

Officials believe that compared to Session state hidden in the transport layer, explicit handles are more visible to the model: Orchestrators can allow multiple sub-Agents to share the same basket_id, while assigning independent browser_ids to each, with granularity determined by application design, rather than being restricted by “one Session, one scope”.

Server-Initiated Interactions: MRTR Replaces Long Connections¶

The stateless model still needs to support scenarios such as “requesting user confirmation during tool execution”. Previously, server-initiated requests like elicitation/create and sampling/createMessage relied on open bidirectional streams; 2026-07-28 introduces Multi Round-Trip Requests (MRTR, SEP-2322) to solve this problem.

When processing a client request, the server can return resultType: "input_required" and pending inputRequests; after the client collects user input, it retries the original call with inputResponses and requestState. All related state is passed in the payload, so any instance can handle the request continuation without a persistent connection. Supabase and others have stated during the RC phase that it was precisely MRTR that allowed them to implement Elicitation flows such as payment confirmation and secondary confirmation for dangerous operations in a sessionless architecture.

Extension Framework: MCP Apps and Tasks¶

This release also formally establishes the extension (Extensions) mechanism (SEP-2133): extensions are identified by reverse DNS IDs, maintained in independent repositories, and their versions are decoupled from the core specification.

Two official extensions are worth noting:

MCP Apps (SEP-1865): Servers can provide interactive HTML interfaces rendered in sandboxed iframes, which Hosts can prefetch, cache, and perform security reviews on; UI operations still use JSON-RPC, and the audit trail is consistent with direct Tool Calls.
Tasks (SEP-2663): Moved from experimental core capabilities to the io.modelcontextprotocol/tasks extension, using polling-based tasks/get and tasks/update methods; suitable for long-running Agent tasks. AWS contributed the Tasks extension, which is now supported in Amazon Bedrock AgentCore.

In addition, the three core capabilities of Roots, Sampling, and Logging have been marked for deprecation (SEP-2577), with a minimum retention period of 12 months; the old HTTP+SSE transport has also entered the deprecation window. The specification also introduces a formal deprecation policy: features move from Active to Deprecated and then to Removed, with a minimum interval of 12 months, allowing teams to plan upgrades rather than reacting passively.

Regarding authorization, clients must validate the iss parameter in authorization responses according to RFC 9207 (SEP-2468); Dynamic Client Registration (DCR) has been officially deprecated, shifting to Client ID Metadata Documents (CIMD), where client credentials are bound to their issuer and cannot be reused across Authorization Servers.

SDKs and Ecosystem: Tier 1 Aligned, Cloud Vendors Support Day Zero¶

The four Tier 1 SDKs for TypeScript, Python, Go, and C# have already supported 2026-07-28, with the Rust SDK in Beta. The official provides migration guides for breaking changes; integrations that depend on Session IDs will require key modifications.

The ecosystem has responded quickly. AWS and Anthropic stated that the new specification is now available in Amazon Bedrock AgentCore, and MCP Servers can be deployed on standard scalable infrastructure; Netlify said that the sessionless core makes hosting MCP on its platform as simple as hosting regular web services; Cloudflare Agents SDK, Google Cloud, Microsoft Foundry, FastMCP 4.0, and others have also announced Day Zero or upcoming support.

For teams building Agent toolchains, the following migration items can be prioritized:

Remove dependencies on initialize handshakes and Mcp-Session-Id, and instead pass client information in _meta.
Integrate Mcp-Method / Mcp-Name headers into gateways and observability tools; use ttlMs for list interfaces to reduce repeated pulls.
If your business relies on cross-call state, design explicit handle tools instead of assuming Session scope.
If you are using the experimental Tasks API, migrate to the extended lifecycle; pay attention to MRTR to support user confirmation interactions.

Summary¶

The 2026-07-28 version of MCP aligns the protocol core with modern HTTP operational paradigms: sessionless, routable, cacheable, and horizontally scalable. This is the most important architectural revision since the launch of Remote MCP. While there are many Breaking Changes, with the 12-month deprecation window and extension framework, the official intent is that after this “clean break”, future evolution will focus on optional extensions and incremental iterations.

For developers, MCP Servers are finally closer to the mental model of “deploying a REST service”; for Agent platforms, the costs of tool directory caching, parallel sub-Agents, and enterprise-grade gateway governance will all decrease. If you are running Remote MCP in production, it is recommended to review the official SDK migration documentation and SEP original texts and start adaptation as soon as possible—this is not a minor patch update, but a foundational overhaul of the protocol layer.

Model Context Protocol Releases July 28, 2026 Update: Remove Session, Move Towards Stateless HTTP Deployment