The draft Model Context Protocol revision dated 2026-07-28 removes protocol-level sessions and the initialize/notifications/initialized handshake. On July 23, GitHub announced that GitHub MCP Server already supports the upcoming specification. The specification is still a draft as of July 24, with final publication scheduled for July 28.
For remote MCP deployments, the new lifecycle can remove session-store traffic and let any replica handle a request. It also makes application state, retry safety, routing metadata, authentication, and traces more clearly the implementer’s responsibility. This article explains the old and proposed wire behavior, the work that remains above the protocol, and a small migration sequence to run before enabling the new path in production.
These positions have different scopes. GitHub says users need do nothing to maintain support because Tier 1 SDKs preserve backward compatibility and have shipped beta support. The official release-candidate post still calls this a breaking revision for implementers adopting the new lifecycle. Existing versions can continue negotiating while teams test the draft path.
The existing lifecycle establishes connection context before tool calls
Under the 2025-11-25 lifecycle, a Streamable HTTP client sends initialize with its protocol version, identity, and capabilities. The server can return an Mcp-Session-Id; the client then sends notifications/initialized and includes the ID on later requests. Negotiated information remains associated with that protocol session.
A remote server must recover the correct session context on every call. A load balancer can keep the client on the replica that issued the ID, or all replicas can read shared state. Affinity limits distribution across replicas; a shared store adds reads, writes, expiry rules, and another request-path dependency.
GitHub’s MCP Server shows what can disappear: it removed Redis writes during initialization and reads on later calls for the new path. That does not mean every remote server can delete its state store. Application data that outlives one request still needs durable storage.
The draft makes protocol context part of each request
In the draft lifecycle, the client does not create a protocol session. Each request carries the protocol version and client capabilities in _meta, the metadata object attached to an MCP message. A mandatory server/discover method lets a client ask which versions, capabilities, and server identity are available before proceeding.
The Mcp-Session-Id header and initialization exchange are gone. The information needed to interpret a request travels with it, so any healthy replica can respond. This permits round-robin distribution at the protocol layer and removes one reason for sticky routing or shared session storage.
Only protocol context becomes self-contained. A tool may need additional facts, and application data still needs a durable owner. Authentication establishes the caller on each request, while authorization decides what that caller may do.
Application state becomes explicit and must work across replicas
A multi-step tool may need state from an earlier call. The server can create an explicit handle such as basket_id or browser_id, return it in one result, and require the client to send it as an argument on the next call. The state is visible instead of hidden behind Mcp-Session-Id.
Visibility does not make a handle trustworthy. The application must define whether it belongs to one user, tenant, workflow, or tool; protect it against guessing or alteration; set an expiry; and check authorization whenever it returns. Every replica must verify encoded state consistently or load the same server-side record with the same scope and expiry rules.
Akamai’s security analysis identifies cross-tenant handle misuse and state tampering as implementation risks. These are threat-model concerns, not reported GitHub MCP Server defects. Test whether replica B accepts a handle minted on replica A for the correct identity, rejects another identity, and rejects it after expiry. Decide whether replay should be harmless, bounded, or blocked.
A stateless protocol can support a stateful application because state crosses calls through explicit arguments or application storage. A related boundary appears when evaluating whether an MCP result is complete enough for a decision: transport validity proves less than the surrounding workflow may require.
Retries need an identity separate from the request ID
Server-Sent Events response streams are no longer resumable through Last-Event-ID and event redelivery. If a stream breaks, the client must reissue the request with a new JSON-RPC request ID. The downstream application still does not know whether the first attempt changed something.
If a tool changes a record before the stream fails, the client cannot infer whether the action completed. A retry needs an application-level idempotency key, which identifies the intended logical operation across attempts, or another durable duplicate check. The JSON-RPC request ID identifies only one protocol attempt.
Multi-round-trip requests expose the same responsibility during expected pauses. A server returns an InputRequiredResult with requestState; the client gathers input and retries the operation with that state and inputResponses. The server must validate the state, recheck authorization, and avoid repeating work completed before the pause.
Trace continuity can help an operator reconstruct both attempts, but it cannot prevent a duplicate side effect. Runtime approval is separate too, as the AgentCore gateway analysis explains. Permission to call a tool does not make its retry safe.
Routable headers simplify intermediaries and increase exposure
Every Streamable HTTP JSON-RPC request requires an Mcp-Method header. tools/call, resources/read, and prompts/get requests also require Mcp-Name, populated from params.name or params.uri. Intermediaries can therefore route a named tools/call without parsing the body. GitHub says its server now reads values needed for logging and secret scanning from guaranteed headers instead of inspecting each payload first.
The server must reject a request when the headers and body disagree. This keeps an intermediary and the MCP server from making different routing or policy decisions. Rejection should occur before the request reaches a tool or receives different authorization treatment.
Selected tool parameters can also be mapped into custom headers. Headers commonly pass through proxies, access logs, tracing systems, and error reports, so sensitive values may reach more systems than the JSON body. Allow only reviewed fields and inspect every log destination on the actual path.
Cacheable list and read results carry ttlMs, a freshness duration in milliseconds, and cacheScope, which says whether shared caching is allowed. W3C Trace Context fields in _meta standardize trace propagation across the client, MCP server, and downstream service. Verify that private results remain private and that retried operations connect across request IDs.
A short migration run exposes the work above the protocol
Run the new path beside the version you support and reproduce one dependent workflow without session affinity. Use the same identities, data, and side effects that matter in production.
- Verify old-version negotiation, then run the official conformance suite against the draft path.
- Put two replicas behind round-robin balancing with affinity disabled. Complete a two-call workflow in which the second call uses a handle created by the first, and force the calls onto different replicas.
- Repeat the handle use with the wrong identity and after expiry. Confirm both requests fail before application data or side effects are exposed.
- Interrupt a request after its downstream action begins. Confirm that the client retries with a new request ID while the server’s idempotency mechanism returns or resumes the original logical result without repeating the action.
- Send
Mcp-MethodandMcp-Namevalues that disagree with the body. Confirm rejection, then inspect proxy, gateway, application, and trace logs for sensitive mapped values. - Check
ttlMs,cacheScope, authentication, and trace propagation on the same workflow. Keep the older protocol path until the clients and workloads you actually run pass.
This sequence tests what a single-replica demo can hide: whether state, identity, retries, and evidence remain coherent without transport-level continuity. A pass supports adoption for this workload; other MCP features need their own tests.
Adopt the new path when the application survives without affinity
Adopt the draft path in testing now if you operate a remote MCP deployment and can keep backward-compatible negotiation available. Use it as a production default only after dependent calls cross replicas safely, retries prevent duplicate actions, header mismatch is rejected, authentication is reconstructed, and traces connect the attempts. Recheck the final specification because the July 28 revision is not yet final.
Wait if your implementation still treats initialize, Mcp-Session-Id, sticky routing, or a JSON-RPC request ID as the owner of application continuity. Wait as well when your SDK has not passed your workload. GitHub’s early support shows that the lifecycle can preserve older clients; it does not replace local validation.
BaristaLabs tests these boundaries inside the workflow that will carry real side effects, then implements the state, retry, authentication, and recovery behavior left local. Our process automation work fits when transport support is ready but the surrounding application path is not.
Sources
MCP migration testing
Test the workflow above the protocol
Bring one remote MCP workflow with a dependent second call or a real side effect. We will trace state, retry identity, authorization, routing, and recovery across replicas.
Best fit for teams operating a remote MCP client or server with multi-step tools, write actions, or custom infrastructure.
Turn this idea into a pilot
Which workflow should go first?
Use the readiness check to compare impact, effort, risk, owner, and next step before booking a call.
- 3-5 minutes
- Deterministic score
- No sensitive data
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.