MCP 2026-07: OAuth, stateless core, team migration

MCP 2026-07-28: what changes (spec facts)

The MCP 2026-07-28 specification was published on July 28, 2026. The official announcement describes a stateless protocol core, multi round-trip requests, header-based routing and stronger authorization. Check each client and SDK for compatibility before migrating.

Four blocks stand out:

• A stateless core at the protocol level
• First-class extensions (MCP Apps, Tasks)
• Authorization aligned with OAuth and OpenID Connect
• A formal deprecation policy, with at least 12 months between deprecation and earliest removal

If your team wires remote MCP in production, treat this release as an infra and security runbook, not as a "nice to have" note.

Stateless core: protocol sticky sessions are gone

Before, on 2025-11-25 for instance, you had an initialize handshake, an Mcp-Session-Id header, sticky instances and often a shared session store. After 2026-07-28, requests become self-contained, the protocol version travels per request, and the Mcp-Method and Mcp-Name headers let you route without opening the body.

The protocol no longer manages the session for you. Application state goes through explicit handles, such as a basket_id, that the model passes back as a tool argument. That is more visible for the agent and simpler for a round-robin load balancer.

Multi Round-Trip follows the same logic: the server can return an InputRequiredResult (elicitation), then the client replays the call with the answers. Any instance can resume, because the useful state lives in the payload.

MCP OAuth: what auth requires now

Several SEPs harden authorization. On the team-practice side, clients must now validate the iss parameter on auth responses (RFC 9207), to limit mix-up attacks, common when one client talks to many MCP servers.

Remote servers increasingly behave as OAuth 2.x resource servers, with protected resource metadata, resource indicators and credentials bound to the issuer. Implementation write-ups, at WorkOS for instance, also stress the evolution of client registration: CIMD is recommended and DCR steps back.

The minimum policy fits in four lines:

• No blind token passthrough
• Minimal scopes
• Auth logs
• A re-register if a server changes issuer

Human approval on high-impact tools stays outside the protocol: that is business HITL.

Extensions: Apps, Tasks, deprecations

MCP Apps bring a server-rendered HTML UI in a sandboxed iframe, and their actions go through the same audit path as tools. Tasks leaves the experimental core to become an extension with a stateless-aligned lifecycle, with a task handle and the get, update and cancel operations.

Roots, Sampling and Logging are deprecated by annotation and remain for a time under the lifecycle policy. The stated replacements are tool parameters and URIs, direct LLM APIs, then stderr or OpenTelemetry for logs.

Do not confuse "we have MCP" with "we have the right spec version and the right SDK tier". Pin the protocolVersion and test conformance.

SME migration checklist (1 page)

The migration fits on one page:

1. Inventory your MCP servers, separating local stdio from remote
2. Note who exposes what (scopes, data)
3. Set the target SDKs and protocolVersion
4. Frame auth: issuer, registration, refresh, logs
5. Check load balancing without protocol sticky sessions
6. Adjust the TTL and cache for tools lists
7. Wire OpenTelemetry traces
8. Name an owner, a cutover date and a rollback plan

The evergreen MCP guide (model-context-protocol-mcp) explains why to wire tools; this news post dates the July 2026 delta.

The main sources are the official MCP blog for the 2026-07-28 RC and the OAuth implementation notes, at WorkOS in particular. Re-read the draft changelog before cutover.

If you want to audit your remote MCP and OAuth policy on a real process, we can scope in 20-40 minutes.

Frequently asked questions