By Greg Nowak. Updated 28 September 2026.
MCP 2026-07-28 may arrive in your backlog as an SDK update. Treating it that way understates the work. The release removes protocol-level sessions, changes how clients and servers establish capabilities, and strengthens several OAuth requirements. Those changes cross application code, identity configuration, gateways, testing and operational ownership.
The business benefit is worthwhile: simpler horizontal scaling, clearer trust boundaries and less infrastructure tied to sticky sessions. But the upgrade is safe only when each request still carries enough verified information to answer three questions: who is calling, which MCP server is the token intended for, and what may the caller do?
Why this is more than a package upgrade
The final 2026-07-28 release removes the initialize/initialized exchange and the Mcp-Session-Id header. Client information and capabilities now travel with individual requests, while optional server/discover calls let clients inspect a server before proceeding. Streamable HTTP requests also expose method and tool names in headers, making gateway routing, metering and policy enforcement easier.
This removes protocol state, not business state. A tool may still need to retain a draft, continue a long-running job or request approval. That continuity should now be explicit: return an application-level handle and require it on the next call. The handle needs an owner, an expiry and protection against tampering. If it can be replayed by another user or tenant, removing sessions has revealed an authorization flaw rather than solved one.
Ask the engineering team to route consecutive calls to different server instances with session affinity disabled. If the workflow breaks, or authorization depends on identity cached against an old session ID, the service is not ready.
The OAuth changes decide whether you can ship
The current MCP authorization specification makes the expected trust relationships much more explicit. Clients record the authorization server’s validated issuer and check an iss value when the response supplies one. If the server advertises issuer-response support but omits iss, the client must reject the response. Client credentials must also remain bound to the issuer that created them.
Resource binding is equally important. MCP clients must send the OAuth resource parameter in both authorization and token requests, identifying the intended MCP server by its canonical URI. The server must then reject tokens that were not issued for its audience. This applies the protection defined by RFC 8707: a token for server A should not become a convenient pass into server B.
Dynamic Client Registration is now deprecated in favour of Client ID Metadata Documents, although it remains available for compatibility. There is no reason to force every client across in one weekend. Inventory which clients use DCR, which authorization servers support the preferred approach, and which older clients require a temporary compatibility path. Do not leave that path ownerless or open-ended.
An SDK update may not enable the new protocol
Version behaviour needs an explicit test, not an assumption. For example, the TypeScript SDK migration guide explains that installing v2 does not automatically put 2026-07-28 traffic on the wire. Clients must opt into modern version negotiation, while servers use new per-request entry points. The guide also provides compatibility options for serving modern and legacy clients during a staged migration.
Record the client SDK, server SDK, configured protocol mode and authorization behaviour as one tested combination. “Both sides are on v2” is not adequate release evidence.
| Workstream | Evidence required | Release blocker |
|---|---|---|
| Protocol and routing | Calls succeed across different instances; modern and legacy behaviour is documented | Hidden dependence on session affinity or an unknown negotiated version |
| Application state | Handles are scoped to the user and tenant, integrity-protected and time-limited | A modified or cross-user handle is accepted |
| OAuth | Issuer, resource, audience, expiry and scope checks have negative tests | A token works at the wrong MCP server |
| Operations | Logs identify the caller, resource, operation, protocol era and authorization outcome | Support cannot explain why access was allowed or denied |
| Ownership | Every connector has a business owner and a technical owner | No one can approve permissions, rollback or retirement |
Run the migration as a controlled access change
Start with an estate map: MCP clients and servers, SDK versions, transports, authorization servers, redirect URIs, registration methods, credential stores, target resources and business owners. Include any gateway rule or application component that reads Mcp-Session-Id or assumes an initialization exchange has already happened.
Next, build a compatibility environment that can exercise both protocol eras. Test discovery, tool listing, tool calls, multi-step interactions, cancellation and long-running work. Where application state crosses requests, document its lifecycle rather than hiding it inside a generic cache.
Then make the security tests deliberately hostile. Substitute an unexpected issuer, replay credentials against another issuer, send a token to the wrong resource, remove a required scope, expire a token and tamper with a workflow handle. Confirm the request is rejected and that the logs make the reason understandable without exposing secrets.
Finally, roll out by connector or user group, not by switching the whole estate at once. Define success measures, rollback conditions and the date when any legacy compatibility path will be reviewed. Keep the protocol migration separate from optional feature work such as Tasks or application UI changes; combining them makes failures harder to diagnose.
Enterprise-managed access is a separate design decision
The stable Enterprise-Managed Authorization extension lets an organization’s identity provider control MCP access centrally. It can improve onboarding, policy consistency and offboarding, but it is optional and client support varies.
If you adopt it, validate signed identity assertions, issuer, audience and expiration before mapping identity-provider claims to permissions. Use a stable subject identifier rather than email as the primary identity. Pilot with a narrow role and test the effective revocation delay, including what happens to access tokens that have already been issued.
Make the release an architectural checkpoint
The migration is complete when invalid combinations fail reliably—not when the first successful tool call appears in a demo. You should leave with an owned connector inventory, explicit state handling, issuer-specific credentials, resource-bound tokens, understandable logs and a tested rollback route.
If your migration crosses identity, infrastructure, application code and vendor-managed clients, a single technical owner for those joins is valuable. Greg can help turn the specification changes into a scoped migration, evidence-based test plan and rollout your operations team can support.
Related on GrN.dk
- NGINX Can Read JSON Before Routing—Should It Handle Your AI API?
- An AI Voice Agent Needs More Than a Phone Number and a Realtime Model
- Not Every AI Job Needs an Instant Answer: Batch the Backlog
Need help with this kind of work?
Plan your MCP migration with Greg Get in touch with Greg.
