MCP 2026-07-28: Sessions Gone, Auth Rewritten, Migrate Now

The Model Context Protocol’s MCP 2026-07-28 spec lands July 28, and it is not an incremental point release — it is the largest rewrite since MCP shipped in late 2024. The Mcp-Session-Id header is gone, the initialize handshake is gone, three core features are deprecated, and the authorization spec has been rebuilt from the ground up. All of this arrives under new stewardship: MCP now sits inside the Linux Foundation via the Agentic AI Foundation, alongside the other agent-interop standards. With more than 10,000 public MCP servers in production and roughly 97 million monthly SDK downloads, operators of remote MCP servers have a live migration this week, not next quarter.

What’s new in the MCP 2026-07-28 spec

The headline change: remote MCP servers are now stateless by default. Previous revisions required a client to open with an initialize request, receive a server-assigned Mcp-Session-Id, and echo that header on every subsequent call. That design forced sticky sessions, made horizontal scaling awkward, and created a whole class of bugs when a load balancer routed request two to a pod that had never seen request one. The 2026-07-28 revision deletes both the session header and the initialize round-trip. Capability and version negotiation move into the transport layer and per-request metadata, so any replica can serve any request. This is the change described in the wild as “MCP session ID removed,” and it will break the most deployments.

The second major piece is the MCP authorization rewrite. The prior spec leaned on a bespoke OAuth profile that server authors routinely implemented incorrectly — confused-deputy exposure, token audience checks that were optional in practice, and discovery flows that varied between SDKs. The new authorization model tightens this. Resource servers and authorization servers are cleanly separated, token audience binding is mandatory rather than advisory, and protected-resource metadata discovery is the required path rather than one of several. If you hand-rolled OAuth against the old text, assume it does not comply.

Third, three core features are deprecated. Deprecated does not mean deleted on day one — the working group’s pattern is a deprecation window across at least one revision — but new work should stop targeting them immediately, and your telemetry should start tracking whether any live client still depends on them. Combined with the governance move to the Linux Foundation, the signal is clear: MCP is consolidating for long-term stability, and the price of that stability is one hard cut now. Treat the full list of MCP breaking changes in the changelog as your authoritative checklist; the summary here is orientation, not a substitute.

Why it matters

• Your scaling model just got simpler — after it breaks. Stateless servers mean no sticky sessions, no session store in Redis, no session-affinity rules at the ingress. Once you migrate, you can run MCP behind an ordinary round-robin load balancer and autoscale like any other HTTP service.
• Every remote server needs a code change this week. Clients on the new revision will not send Mcp-Session-Id and will not call initialize. If your handler requires either, those clients get a 400 or a hang. Backward compatibility is on you, not on the spec.
• Auth non-compliance is now a security finding, not a style note. Mandatory audience binding closes a real token-replay path. A server that accepts a token minted for a different resource is exploitable, and reviewers will flag it.
• Deprecations create a dependency audit you cannot skip. Anything you built on the three deprecated features has a shelf life. Find those call sites now, while the window is open, instead of during the revision that removes them.
• Governance changes the risk calculus in your favor. Linux Foundation stewardship under the Agentic AI Foundation means neutral IP handling and a published change process — the thing enterprise procurement asks about before it approves an agent integration.
• Scale means the ecosystem lags you. With 10,000+ public servers, expect months of mixed-version traffic. Your client code must tolerate old servers and your server code must tolerate old clients, simultaneously.

How to use it today: migrate your MCP server in 2026

1. Pin the exact revision and read the changelog first. Do not migrate from a blog post — including this one. The spec site publishes a per-revision changelog that enumerates every breaking change.

   https://modelcontextprotocol.io/specification/2026-07-28/
   https://modelcontextprotocol.io/specification/2026-07-28/changelog

2. Upgrade the SDK before you touch your own code. Most of the transport-level work happens inside the SDK. Get onto the release that declares support for the new revision, then run your test suite and read the failures — they are your migration plan.

   # Python
   pip install --upgrade "mcp>=2026.7"
   
   # TypeScript
   npm install @modelcontextprotocol/sdk@latest
   
   # Check what protocol revision your build actually speaks
   py -c "import mcp; print(mcp.__version__)"

3. Find every session dependency. Grep for the header and for session state in your handlers. Anything that reads a session ID, or stores per-session data keyed by one, has to go.

   # Windows PowerShell
   Select-String -Path .\src\**\*.py,.\src\**\*.ts `
     -Pattern "Mcp-Session-Id|session_id|sessionId|initialize" -CaseSensitive:$false

4. Move per-session state to per-request or external state. This is the actual work of MCP stateless servers. Anything you cached on a session object moves to a request-scoped context, or to a store keyed by an authenticated identity from the token rather than by a server-minted session ID.

   # Before — server-minted session, single-replica only
   SESSIONS = {}
   
   def handle(req):
       sid = req.headers["Mcp-Session-Id"]
       ctx = SESSIONS[sid]              # breaks on any other pod
       return do_work(req, ctx)
   
   # After — identity from the verified token, state in a shared store
   def handle(req):
       claims = verify_token(req.headers["Authorization"])
       ctx = store.load(claims["sub"])  # any replica can serve this
       return do_work(req, ctx)

5. Rebuild authorization against the new model. Publish protected-resource metadata, and verify the audience claim on every request. Reject tokens whose audience is not your canonical resource URL — no exceptions, no “temporarily allow” flag.

   # .well-known/oauth-protected-resource
   {
     "resource": "https://mcp.example.com",
     "authorization_servers": ["https://auth.example.com"],
     "bearer_methods_supported": ["header"],
     "scopes_supported": ["mcp:tools", "mcp:resources"]
   }

   def verify_token(header):
       token = header.removeprefix("Bearer ").strip()
       claims = jwt.decode(
           token,
           key=jwks(),
           algorithms=["RS256"],
           audience="https://mcp.example.com",   # mandatory, not optional
           issuer="https://auth.example.com",
       )
       return claims

6. Run a dual-stack compatibility window. Do not hard-cut. Accept requests with and without the legacy header, log which revision each client speaks, and remove the old path only once your logs are clean.

   legacy = "Mcp-Session-Id" in req.headers
   metrics.increment("mcp.request", tags={"revision": "legacy" if legacy else "2026-07-28"})
   if legacy:
       return handle_legacy(req)   # keep until this counter hits zero
   return handle(req)

7. Verify against a real client before you ship. Point the Inspector at your dev server and confirm a cold tool call succeeds with no prior handshake — the single best smoke test for the new revision.

   npx @modelcontextprotocol/inspector https://localhost:8080/mcp
   
   # And the raw version — one request, no session, no initialize
   curl -X POST https://localhost:8080/mcp \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

How it compares

Dimension	MCP (2026-07-28)	MCP (prior revisions)	A2A / agent-to-agent protocols	Plain OpenAPI tool calling
Primary purpose	Model-to-tool/resource context	Model-to-tool/resource context	Agent-to-agent task delegation	Generic HTTP API description
Session model	Stateless; no session header	Server-minted Mcp-Session-Id	Task-scoped, long-running	Stateless by nature
Handshake	None required	initialize round-trip	Agent card discovery	Spec fetch, out of band
Authorization	Rewritten; audience binding mandatory	Looser OAuth profile	Standard OAuth / mTLS	Whatever you implement
Horizontal scaling	Any replica, any request	Sticky sessions in practice	Depends on task store	Trivial
Governance	Linux Foundation / AAF	Vendor-led	Linux Foundation / AAF	OpenAPI Initiative
Ecosystem size	10,000+ public servers, ~97M monthly SDK downloads	Same install base, mid-migration	Smaller, growing	Universal but unspecialized

The honest read: MCP and agent-to-agent protocols are complements, not competitors — one connects a model to tools, the other connects agents to each other, and both now live under the same foundation. The real alternative most teams weigh is “just expose an OpenAPI endpoint and describe it in the prompt.” That still works, and for a single internal tool it is less ceremony. What you give up is discovery, a shared authorization story, and the 10,000-server ecosystem your users’ clients already speak.

What’s next

Watch the deprecation clock first. Three core features are marked in this revision, and the working group’s convention is to carry deprecated surface for at least one full revision before removal. That gives you a window measured in months, not years. Instrument now: log every call to a deprecated feature with the calling client’s identity, so that when the removal revision is announced you have a list of exactly who to notify instead of a guess.

Second, watch how quickly clients adopt. Spec day is not adoption day. Desktop clients, IDE extensions, and hosted agent platforms all ship on their own cadences, and the long tail of self-hosted clients is longer still. Expect a mixed-version internet through the rest of 2026. That is why the dual-stack step above is not optional politeness — keep the legacy path alive until your own telemetry says it is dead, and budget for the possibility that it takes two or three quarters.

Third, watch the governance layer. Linux Foundation stewardship via the Agentic AI Foundation makes the change process itself public and predictable: proposals, review periods, and dated revisions. Subscribe to the spec repository, and put the next revision’s expected window on your roadmap the same way you track a major runtime or framework release. The teams that got burned this week are the ones for whom July 28 was a surprise. It does not have to be a surprise twice.

Frequently Asked Questions

Does the MCP 2026-07-28 spec break my local stdio server?

Far less than it breaks remote ones. The session header and the initialize handshake were the pain points of HTTP transport, where load balancers and multiple replicas made server-held state expensive. A local stdio server has one process and one client by construction. Upgrade the SDK and audit for deprecated features, but the stateless changes are unlikely to require restructuring.

What exactly happens if I do nothing?

Old clients keep working against your old server until they upgrade. Once a client moves to the new revision, it stops sending Mcp-Session-Id and stops calling initialize. A server that requires either will reject those requests or hang waiting for a handshake that never comes. The failure is silent from your side and looks like “the tool stopped working” from the user’s side — the worst kind of outage.

Do I have to migrate this week?

You have to start this week. The SDK upgrade and the compatibility shim are small and can ship in a day. The authorization rewrite and the removal of per-session state are real engineering and will take longer. Sequence it that way: shim first so nothing breaks, then do the structural work behind it.

What are the three deprecated features?

Check the official changelog for the 2026-07-28 revision rather than trusting any secondhand list, including this article’s — deprecation lists are exactly the detail that gets garbled in summaries. The procedure is identical regardless of which three they are: grep your codebase for each, instrument the call sites, and stop building new functionality on them today.

Is the MCP authorization rewrite backward compatible?

Not in the strict sense. Mandatory audience binding means tokens that a permissive server previously accepted will now be rejected, which is the entire point — that leniency was the vulnerability. If your authorization server is not currently minting audience-scoped tokens for your MCP resource, that is a configuration change on the auth side, not just a code change on the server side. Budget for both.

Does Linux Foundation governance change the license or my obligations?

The specification remains openly available and implementations remain yours. What changes is the process: neutral IP stewardship, a published contribution and review path, and dated revisions rather than vendor-timed releases. For most engineering teams this is invisible day to day. For procurement and legal review — the people who ask “who controls this standard?” before signing off on an agent integration — it is the answer they were waiting for.