Jul 29, 2026 12:37:00

MCP, the common standard for connecting AI and external tools, has received its biggest update yet. What has changed with the elimination of sessions?

The new specification ' 2026-07-28 ' for the Model Context Protocol (MCP), developed by

the Aggent AI Foundation under the Linux Foundation, was released on July 28, 2026. This update, the largest since the introduction of MCP, shifts MCP to a session-independent 'stateless' design and includes revamped mechanisms for long-running processing, user confirmation, caching, and authentication.

The 2026-07-28 Specification | Model Context Protocol Blog
https://blog.modelcontextprotocol.io/posts/2026-07-28/

MCP 2026-07-28 spec: stateless core, coming to Claude | Claude by Anthropic
https://claude.com/blog/bringing-mcp-2026-07-28-to-claude

GitHub MCP Server supports the next MCP specification - GitHub Changelog
https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/

MCP is an open, common standard for connecting applications that utilize AI agents or large-scale language models with external data, tools, and web services. Released by Anthropic in November 2024, its aim is to enable the use of the same tools from various AIs by supporting MCP, rather than developing different connection methods for each AI service.

Anthropic proposes and open-sources 'Model Context Protocol,' a universal protocol for bridging data between existing apps and AI systems - GIGAZINE

MCP has since been adopted by numerous AI services and development tools, and as of the time of writing, it is being developed as a project of the Agentic AI Foundation. In the version released on '2026-07-28,' the initial mechanism, which was designed as an experimental AI collaboration standard, has been revised and reconfigured to be easier to operate even in large-scale services.

The main differences between the previous specifications and MCP 2026-07-28 are summarized below.

◆Stateless
The biggest change in this update is that the MCP communication method has shifted from 'stateful' to 'stateless.' In the previous MCP, the client and server would initially exchange messages called 'initialize' and 'initialized,' and then maintain the same connection state using the 'Mcp-Session-Id.'

However, when operating a large number of MCP servers using this method, a 'sticky session' is required, which continuously sends communications from the same user to the same server, as well as a database that shares session information among multiple servers. This makes it difficult to increase or decrease the number of servers, or to transfer processing from a server that has failed to another server, hindering large-scale operation.

The new specification eliminates the initialization process using `initialize` and the McP-Session-Id, and each request now individually communicates the protocol version, client information, and available features. If you want to check the features offered by the server in advance, you can use the newly created 'server/discover' function, but this process is not mandatory.

Because each request is self-contained, there is no need to continuously send communications to the same server, and processing can be distributed to available servers using a standard load balancer. This makes it easier to deploy MCP servers to Kubernetes, serverless environments, edge environments, etc., just like a regular HTTP service, and to scale them up or down according to the number of accesses.

Before, running a remote MCP server meant managing session state, which limited where you could run it.

Now that MCP is stateless, you can deploy on serverless and edge infrastructure, or scale horizontally behind any load balancer. pic.twitter.com/2Rfs2kdgb8

— ClaudeDevs (@ClaudeDevs) July 28, 2026

◆App status is managed as an identifier
Statelessness doesn't mean that the app's state itself, such as the contents of the shopping cart or the browser's activity, can no longer be saved. When it's necessary to maintain information across multiple calls, the server issues a state identifier, which the AI agent explicitly passes in subsequent tool calls.

Information that was previously hidden within the communication session will now be explicitly handled as tool arguments. This makes it easier for AI agents and developers to understand which state is being used for processing, and eliminates the need for the server to maintain a specific connection.

◆ 'MRTR' allows for multiple user confirmations.
With the shift to stateless processing, 'Multi Round-Trip Requests (MRTR)' have also been introduced to receive additional information from the user during processing. For example, if confirmation is needed when an AI agent attempts to delete data, the server will return a result of 'input_required' along with the question.

The client receives the response from the user, adds that information, and resends the original request. This eliminates the need for the server to send a question back to the connected client, allowing for stateless communication to handle user confirmations and input of missing items.

◆HTTP headers and cache have also been revamped.
To facilitate traffic routing and monitoring, HTTP headers are now required to include 'Mcp-Method,' which indicates the function being called, and 'Mcp-Name,' which indicates the tool name, etc. Gateways, rate limiting systems, and web application firewalls can route traffic and control access simply by looking at the headers, without having to parse the JSON in the request body.

The list of available tools, prompts, and resources now includes 'ttlMs' to indicate the expiration date and 'cacheScope' to indicate the cache scope. This eliminates the need for clients to retrieve an unchanged list of tools each time, reducing the amount of data transmitted to the server.

Since the order of the tool list will also be consistent, the content of the prompts passed to the AI will change with each connection, which helps to mitigate the problem of cache invalidation. This is especially effective when the MCP server provides a large number of tools or when many users connect simultaneously.

◆Long-term processing and screen display should be handled by extensions.
A formal extension mechanism has also been introduced, allowing new features to be added separately from the MCP core. Instead of integrating all features into the core specifications, only the necessary clients and servers can select and support extensions.

'MCP Tasks,' which handles long-running processes, has moved from an experimental feature to a formal extension. The server returns a task identifier while processing, and the client can use that identifier to retrieve progress and results later.

'MCP Apps,' which display interactive screens such as forms, tables, and dashboards within the chat, are also provided through this extension mechanism. MCP is expanding not only to simply calling external tools from AI, but also to serve as the foundation for AI applications that include user-interactive screens.

◆Enhancing the security of OAuth authentication
Authentication has been enhanced to align with the use of OAuth 2.0 and OpenID Connect in enterprise systems. Verification of the 'iss' information, which indicates the authentication server, is now mandatory, and client authentication information is clearly linked to the issuing authentication server.

This makes it easier to prevent information issued for one authentication server from being mistakenly used on another authentication server. Dynamic Client Registration, which registers clients on the fly, is being deprecated, and a transition to Client ID Metadata Documents, which publishes client information as documentation, is being promoted.

◆A 12-month transition period will be provided for the features that will be discontinued.
To prevent existing implementations from suddenly becoming unusable due to specification changes, a formal deprecation policy has also been established. A minimum 12-month transition period will be provided between the time a feature is deprecated and its removal.

This update deprecates Roots, Sampling, Logging, and the traditional HTTP-to-Server-Sent Events communication method. However, these features will not be removed immediately and will remain available for at least the next 12 months.

◆Claude and GitHub also support the new specifications.
The major SDKs for TypeScript, Python, Go, and C# have completed support for the '2026-07-28' specification simultaneously with its release, and the Rust SDK is also compatible in beta. Since the major SDKs maintain backward compatibility with the old specification, there is no need to migrate immediately if you are simply continuing to use existing MCP connections.

GitHub MCP Server has been updated to support the new specifications ahead of its official release, removing the read/write operations to Redis that stored session information, as well as the mechanism that determined the processing content from the request body. GitHub explains that this stateless approach simplifies the server configuration, making it easier to operate on typical cloud infrastructure.

Anthropic has also announced that it will be gradually introducing support for the new specifications to each of its Claude products. The Claude connector directory has more than 950 MCP servers registered, and the new specifications will allow for large-scale deployment of MCP servers while reducing the operational burden.

This update includes compatibility-breaking changes such as the deprecation of sessions, so MCP servers and clients that rely on session IDs will need to migrate. On the other hand, it provides a mechanism for securely operating MCP at scale on a common HTTP infrastructure, making it easy to deploy in enterprise production environments.