MCP 2026-07-28 Deleted the Transport Session. Your Agent Still Needs One.
MCP 2026-07-28 Deleted the Transport Session. Your Agent Still Needs One.
GitHub’s first production result makes the new Model Context Protocol easier to understand than the phrase “stateless protocol.”
After adopting the 2026-07-28 design, GitHub says its MCP server no longer needs a Redis write during initialization, a Redis read on every call, or deep inspection of JSON-RPC payloads to identify operations for logging and secret scanning. Those are not documentation wins. They are pieces of infrastructure that can leave the request path.
The final MCP specification arrived after a ten-week locked-candidate period and removes the initialize handshake and Mcp-Session-Id from the modern core. Version, capabilities, method, and tool name now travel with each request. Any compatible replica can answer it. Ordinary gateways can see enough of the call to route, meter, trace, and apply policy without pretending an agent connection is a special kind of tunnel.
That is the clean half of the story.
The hard half is that agent state did not disappear. Approvals, partial work, browser sessions, task IDs, subscriptions, retry budgets, and external effects still have to live somewhere. MCP now makes builders name that state, move it through explicit handles, or keep it in a runtime above the protocol. The wire gets simpler; ownership of durable work gets more demanding.
The useful way to read this release is as a two-plane architecture change: a stateless capability plane underneath a stateful work plane. Treating it as an SDK upgrade will hide the exact migration risks the redesign exposes.
A tool call becomes a policy object
The old MCP lifecycle made the connection important. A client initialized a session, negotiated capabilities, received an identifier, and sent later calls inside that protocol context. Horizontal scaling often meant sticky routing or shared session storage. A gateway could see an HTTP request, but operation-level controls often required parsing the JSON-RPC body.
The 2026-07-28 changelog changes the unit of infrastructure. A modern request carries its protocol version and client capabilities in _meta. Servers must implement server/discover so clients can learn supported versions, capabilities, extensions, and server metadata before making normal calls. Clients may use discovery, but do not have to.
For Streamable HTTP, MCP-Protocol-Version and Mcp-Method become required request headers. Calls to named primitives such as tools/call, resources/read, and prompts/get also carry Mcp-Name. The response can still be JSON or a request-scoped SSE stream. Stateless does not mean connectionless; it means the transport no longer depends on a hidden protocol session surviving between requests.
| Concern | 2025-era default | 2026-07-28 core | Builder consequence |
|---|---|---|---|
| Protocol context | Established during initialize | Version and capabilities ride on each request | Observe the negotiated wire era, not the package version |
| Routing | Session affinity or shared session state may be required | Any compatible replica can answer an independent request | Round-robin scaling becomes the normal path |
| Operation visibility | Often requires JSON-RPC body inspection | Mcp-Method and Mcp-Name are explicit headers | Gateway policy can become method- and tool-aware |
| Continuation | Server-to-client work can depend on a held-open stream | MRTR retries the operation with explicit responses and state | Continuation integrity becomes an application contract |
| Stream recovery | SSE event IDs can support resumption | A broken response is reissued with a new JSON-RPC ID | Side-effecting tools need idempotency |
| Catalogue freshness | Lists are commonly fetched again | Selected complete results carry TTL and cache-scope hints | Cache partitioning joins the authorization design |
Header visibility is a contract, not a suggestion. The Streamable HTTP specification requires servers to compare the routing headers with the body and return HeaderMismatch error -32020 when they disagree. A gateway that authorizes tools/list from the header while the backend executes tools/call from the body has created a split-brain policy path.
GitHub’s early implementation report is the strongest disclosed before-and-after example. It removed protocol-session Redis traffic and deep payload inspection from several controls. GitHub did not publish a latency or cost benchmark, so the measured claim should stop there. The architectural direction is still clear: MCP traffic can look much more like an ordinary governed API.
The two planes of a production agent
Stateless at the protocol-session layer; explicitly stateful wherever work lasts.
The bottom plane is the capability plane. It discovers servers, lists primitives, reads resources, calls tools, carries authorization context, emits traces, and advertises cache behavior. Each exchange can be independently routed and evaluated.
The top plane is the work plane. It owns the conversation, files, terminals, browser sessions, approvals, task progress, spend limits, retry budgets, effect receipts, pause, termination, and revocation. Those responsibilities remain stateful because the work itself lasts longer than one capability call.
MCP’s Multi Round-Trip Request pattern bridges the two. When a tool needs confirmation or missing input, the server returns resultType: "input_required" with inputRequests and optional requestState. The client gathers the input and retries the original operation as a fresh request with a new JSON-RPC ID. The accepted MRTR proposal explicitly says the retry can land on a different replica.
For longer work, the optional Tasks extension supplies durable task IDs, polling, input-required states, cooperative cancellation, and optional notifications. That is application state above a stateless core, not an exception that weakens the design.
This also resolves an apparent contradiction in agent infrastructure. RohitAI’s earlier analysis of the VS Code Agent Host Protocol argued that live agent sessions are becoming addressable infrastructure. MCP says capability calls should not depend on a transport session. Both can be true. One protocol governs independent capability invocation; the other runtime layer owns continuing work.
The durable market architecture is likely to be:
stateful agent session, task, and governance plane
↓
signed continuation and task handles
↓
stateless MCP capability plane
↓
tools, resources, data systems, and external effects
State becomes portable authority
Removing hidden server-side session state improves scaling, but it changes the security question. A continuation handle crossing the client boundary is not merely serialized progress. It can be a portable slice of authority.
The MRTR specification treats requestState as untrusted when it comes back. If it contains user-specific state, the server must bind it cryptographically to the authenticated user and verify that binding. The practical version should go further: seal or sign the state and bind it to the principal, tenant, original method, important arguments, purpose, expiry, and a nonce or replay ledger.
Consider an approval flow for deploy_production. A state token that says only approved: true is dangerously detachable. A safer continuation says, in effect:
principal = user-184
tenant = acme
method = tools/call
tool = deploy_production
target = payments-api@sha256:...
environment = production
purpose = release-approval
expires = 2026-07-29T14:15:00Z
nonce = ...
The transport can be stateless because the authority is explicit. The server still has to prove that the returned authority belongs to this caller and this action.
That last distinction matters. The basic protocol specification describes clientInfo and serverInfo as self-reported, unverified metadata for display, logging, and debugging. They are telemetry, not identity. Routing a tenant or granting a privilege from clientInfo.name would turn an observability field into an escalation path.
Required headers create their own data boundary. Tool parameters marked x-mcp-header can be copied into HTTP headers under constrained types and encoding rules. That helps gateways make decisions without parsing arbitrary bodies. It can also spread sensitive values into CDN, WAF, proxy, load-balancer, trace, and APM logs. Keep secrets and personal data out of mapped headers, and test redaction across every intermediary.
Authorization also needs precise language. MCP authorization remains optional. When a protected HTTP deployment implements it, the final authorization rules require bearer authorization on every request, token audience binding to the MCP resource, issuer validation, protected-resource discovery, and PKCE behavior. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.
The protocol can verify a request. The work plane still has to govern the trajectory. A valid token for ten independent calls does not answer whether the combined sequence exceeded a spend budget, crossed an approval boundary, or produced an external effect the user can revoke. That is why long-horizon agent monitoring stays relevant after the transport session is gone.
A cached tool list is yesterday’s authorization decision
The release makes complete results from discovery and selected list/read methods cacheable with ttlMs and cacheScope. Public entries may be reused across authorization contexts. Private entries must remain inside the relevant access-token or authorization context. The normative caching guidance warns that cache scope is not access control by itself.
The non-obvious consequence is that a cached tools/list can be an old policy view. It may encode which tools a role could see before a permission change, token revocation, server rollout, or emergency tool disablement. TTL is therefore not only a performance setting. It is the maximum time an earlier capability view may survive unless an invalidation arrives.
Cache safety triangle
If one side is wrong, a fast cache can preserve a stale or unauthorized view with impressive efficiency.
Discovery caching adds a fleet constraint. During a rolling deployment, replicas behind one origin may support different protocol versions or extensions. A cached server/discover response can describe one replica while the next request lands on another. Either keep capability-consistent pools or route from the discovered version and extension set to a compatible pool.
This is state again—just in a place infrastructure teams already know how to operate.
One protocol, several readiness clocks
The release formalizes an extensions framework around a smaller core. Tasks, MCP Apps, and Enterprise-Managed Authorization are optional. The SDK tier rules require applicable core conformance and maintenance commitments, but explicitly do not require extensions.
That makes “supports MCP 2026-07-28” too coarse for procurement or product promises.
The TypeScript story proves why. Stable v2 uses split packages, while the old @modelcontextprotocol/sdk package remains on the v1 line. More importantly, the TypeScript migration guide says a hand-constructed v2 client or server still uses 2025-era behavior by default. Modern traffic requires auto or pinned negotiation and modern serving entry points. Installing v2 changes the code surface; it does not put a 2026 byte on the wire.
Python makes a different choice. Python SDK 2.0.0 defaults its client to modern discovery with legacy fallback and serves both eras from its new server surface. Its release notes also list Tasks as unimplemented. TypeScript v2 similarly lacks a typed Tasks implementation in the modern path.
Package version, core conformance, negotiated wire era, and extension support are four different facts.
Use independent discover, list, read, and call operations when work can complete inside one request. Own per-request auth, tracing, timeout, idempotency, and cache behavior.
Use input_required when a call needs confirmation or missing data. Own signed state, principal and action binding, expiry, replay controls, and safe retries.
Use Tasks or a higher runtime for minutes-to-hours work, resumability, approvals, progress, and cancellation. Verify the exact client and SDK extension matrix.
Measure the wire, not the package manifest
A safe rollout is dual-era and evidence-driven. Run modern and legacy traffic through the real gateway, identity provider, cache, tracing, and server pool. Test four pairings: modern client to modern server, modern client with legacy fallback, legacy client to a compatible modern server, and the failure path when discovery is unavailable or unauthorized.
Log the negotiated protocol version and extension identifiers at both ends. Do not infer the era from the absence of Mcp-Session-Id; an intermediary can remove headers, and a new SDK can intentionally speak the old protocol.
Stream failure deserves its own test. The modern core removes SSE event-ID resumability. When a response stream breaks, the client issues a new request with a new JSON-RPC ID. A tool that charges a card, sends a message, creates a repository, or changes infrastructure must be idempotent or accept an application idempotency key. JSON-RPC identity no longer supplies continuity.
Cross-replica features also expose the limits of the word stateless. Python’s deployment guidance says the default MRTR signing key is process-local, so multi-worker deployments need a shared RequestStateSecurity key. Change notifications across replicas need a shared subscription bus. Removing protocol-session storage does not distribute keys or create pub/sub.
RohitAI’s read: MCP is commoditizing the capability plane
The sourced facts above describe a simpler, more visible wire protocol. The interpretation is what happens to the agent stack around it.
First, method- and tool-aware MCP governance will become normal gateway functionality. GitHub has already removed deep inspection from several controls, while Cloudflare’s earlier enterprise MCP design shows how much policy plumbing existed before the new header contract. Bespoke proxies whose main advantage is parsing JSON-RPC bodies will lose value. Products will differentiate on authorization models, trajectory policy, evaluation, effect receipts, and evidence.
Second, agent platforms will converge on the two-plane design. MCP will standardize independent capability invocation. Agent runtimes will own durable sessions, files, budgets, tasks, approvals, and revocation. This is complementary to the managed-session pattern RohitAI examined in AWS Bedrock AgentCore, not a competing claim about whether state exists.
Third, extension support will become a buyer-visible scoreboard. “MCP-compatible” will give way to matrices for core era, discovery behavior, MRTR, Tasks verbs, Apps, enterprise authorization, notifications, and fallback semantics. Tier labels remain useful, but production compatibility will be tested at the verb and event level.
Fourth, the first serious failures after this release are more likely to appear around explicit continuation, task, cache, or mapped-header boundaries than around the removed session ID. That is a prediction, not evidence of a current exploit. It follows from where the design has moved authority and persistence.
Frequently asked questions
Is MCP now connectionless?
No. Streamable HTTP can return a request-scoped SSE stream, and subscriptions/listen can hold a stream for opted-in change notifications. The 2026 core removes dependency on a protocol session between calls; it does not ban long-lived HTTP responses.
Is OAuth mandatory in MCP 2026-07-28?
No. Authorization is optional. Protected HTTP deployments that implement it face stricter requirements, including per-request bearer tokens, issuer checks, resource and audience binding, discovery, and PKCE.
Does upgrading to TypeScript or Python SDK v2 activate the new protocol?
Not uniformly. TypeScript v2 requires explicit modern negotiation and serving paths. Python v2 defaults to discovery and fallback behavior. Log the negotiated wire era instead of assuming the package made the choice.
Does Tier 1 support guarantee Tasks or MCP Apps?
No. Extensions are outside the Tier 1 core requirement. Test the specific extension identifiers, methods, result shapes, notifications, cancellation behavior, and fallback paths your product needs.
Can the old HTTP+SSE transport be removed in July 2027?
Do not use that date as a universal switch. The deprecated-features registry gives Roots, Sampling, Logging, and Dynamic Client Registration an earliest removal revision on or after July 28, 2027. Legacy HTTP+SSE follows a special transition tied to SEP-2596 and its subsequent grace period.
The migration is done when state has an owner
GitHub’s deleted Redis read is the best symbol for what MCP gained: less hidden transport machinery on every call. Required routing headers, independent requests, discovery, caching hints, and tracing also make the protocol legible to infrastructure teams.
The bill did not disappear. It moved upward.
A production migration is complete when every durable handle has an integrity boundary, every cached view has an isolation and invalidation rule, every retryable effect is idempotent, every task has resource and cancellation limits, and every agent session can still be paused or revoked across many individually valid calls.
MCP 2026-07-28 makes the capability plane look more like the web.
The teams that benefit most will be the ones disciplined enough to decide exactly where the agent’s state—and its authority—now lives.