The Model Context Protocol has received its largest redesign since its launch.

On July 28, the MCP project published specification version 2026-07-28. Its headline change is a stateless protocol core. Remote MCP servers no longer need to establish a protocol session before handling tool calls, and they no longer issue the Mcp-Session-Id value that clients previously returned with later requests.

The release also redesigns requests that require additional user input, adds routing information for gateways, makes several discovery responses cacheable, hardens authorization, and formalizes an extension system for features such as interactive MCP Apps and long-running Tasks. The TypeScript, Python, Go, and C# Tier 1 SDKs all support the new protocol version, according to the official release announcement.

For teams already running MCP, this is a meaningful infrastructure change. It also redraws part of the protocol's security boundary.

Earlier versions of remote MCP began with an initialize exchange. The server returned a session identifier, and the client included it with subsequent calls. At scale, that could require sticky routing so the same client's traffic reached the same server instance, or shared storage so multiple instances could access the same session.

The new specification removes that handshake and session identifier. Each request carries its protocol version, client capabilities, and optional client identity in its _meta field. A server must provide a server/discover method so clients can inspect its supported versions and capabilities when needed.

As a result, any available server instance can process an incoming request. A remote MCP service can sit behind an ordinary round-robin load balancer without maintaining a shared protocol session store.

GitHub provided an early example of the operational effect. After updating its MCP server, GitHub said it removed Redis-backed session writes during initialization and session reads on every later call. It also stopped inspecting request bodies for some routing and security functions because the new protocol exposes method and tool names in required HTTP headers.

Stateless does not mean an MCP application cannot remember anything. A shopping workflow, browser session, or long-running job may still need persistent state. The new pattern is for a server to create an explicit handle, such as a cart ID or workflow ID, and require the model to pass that handle as a normal tool argument on later calls.

That difference is central to the release. MCP no longer manages continuity implicitly at the transport layer. Applications must represent and protect it explicitly.

Removing Mcp-Session-Id eliminates the specific risk of stealing and replaying an MCP protocol session identifier. It also removes infrastructure that developers previously had to secure, synchronize, and expire.

The replacement can still fail if it is implemented carelessly. The MCP project's updated security guidance identifies "state handle hijacking" as a distinct attack vector. If a server treats possession of a workflow ID as proof of authorization, an attacker who obtains or guesses that value could access another user's state.

The guidance says servers should generate unpredictable handles, bind them to the authenticated user on the server, reject handles presented by another principal, and expire them when appropriate. In ordinary application-security terms, this resembles preventing an insecure direct object reference. A random identifier helps, but authorization must still be checked on every request.

The release also replaces unsolicited server-to-client requests with Multi Round-Trip Requests, or MRTR. When a tool needs confirmation, missing information, or another client capability, it returns an input_required result. The client gathers the requested input and retries the original operation. This keeps the interaction tied to a request the client initiated instead of allowing a server to prompt the user at an arbitrary time.

MRTR improves traceability, but it does not make every prompt trustworthy. Clients still need clear approval interfaces, and users still need to understand the action or data request being presented.

The specification includes several changes intended to align MCP more closely with established OAuth and OpenID Connect deployments.

Clients now validate the authorization server's iss value before sending an authorization code to a token endpoint. This is designed to prevent authorization-server mix-up attacks. Client credentials must also remain bound to the issuer that created them, rather than being reused across authorization servers.

Dynamic Client Registration remains available for compatibility but is now deprecated in favor of Client ID Metadata Documents. The authorization specification also reinforces audience validation: an MCP server must accept only tokens issued for that server and must not pass a client’s token through to an unrelated downstream service.

The specification assigns different responsibilities to each component. The model may propose an action. The host or client provides the user-facing consent and approval interface. The authorization server issues delegated authority. The MCP server validates the token, audience, scope, requested resource, and tool input before acting. A sentence generated by the model claiming that the user approved an operation is not an authorization event.

The status codes also carry useful meaning. An absent, invalid, or expired token receives 401 Unauthorized. A valid token that lacks the required permission receives 403 Forbidden and can include an insufficient_scope challenge. The client may then request increased authority through a step-up authorization flow. An agent can begin with repository-read access, for example, and ask for write access only if it later needs to create a pull request.

The inbound MCP token must terminate at the MCP server. If the server calls GitHub, a cloud provider, or another downstream API, it must use a separate credential issued for that service. Forwarding the client’s token would defeat its audience restriction and blur the audit boundary between the client, MCP server, and downstream system.

These are meaningful improvements, especially for remote servers connecting agents to enterprise systems. They do not solve the broader problem of excessive agent authority. Implementers still need narrow scopes, incremental authorization, short-lived credentials where possible, and reliable audit records.

The release formalizes an extensions framework, allowing capabilities to develop outside the core protocol. Tasks, which support long-running operations, move from the experimental core into an official extension. MCP Apps can deliver interactive forms, dashboards, and other interfaces inside a compatible AI host.

These capabilities expand what an MCP-connected agent can do, but they also import familiar application-security concerns. In a pre-release analysis, Akamai researchers warned that application-managed state could be hijacked, long-running tasks could be abused to consume server resources, and interactive MCP Apps could expose users to deceptive content or web vulnerabilities if output is handled poorly.

Those are threat-model findings, not reports of attacks against the final specification. They are still useful design warnings. Task endpoints need authentication, quotas, cancellation controls, and limits on concurrent or expensive work. Interactive content needs sandboxing, output encoding, restrictive content policies, and careful handling of any data exposed inside the interface.

The protocol's own documentation remains explicit that tools may execute arbitrary code and that tool descriptions should be treated as untrusted unless they come from a trusted server. The new release improves MCP's transport and authorization foundations, but it cannot determine whether a tool is safe, whether a model was manipulated, or whether a requested action matches the user's intent.

Existing MCP clients and servers will not suddenly stop working. Protocol versions are negotiated, and the previous specification remains usable. Major SDK upgrades and adoption of the new wire protocol may still contain breaking changes, particularly for applications that depend on session identifiers or the previous server-to-client request flow.

Teams operating MCP should take several concrete steps:

MCP's new architecture makes the protocol fit more naturally into ordinary cloud infrastructure. Load balancers, gateways, caches, distributed tracing, and identity systems can now handle MCP traffic using patterns that engineering and security teams already understand.

That familiarity is valuable. It also means MCP security increasingly looks like application and API security. The protocol can supply safer defaults and clearer boundaries. The systems built on top of it still have to enforce them.