The Model Context Protocol spec dated 2026-07-28 lands its biggest change since launch: the protocol core is now stateless. If your MCP server runs as a DenkOps connector, there is nothing for you to do. The SDK behind every connector already targets protocol version 2026-07-28, and it was built stateless from the start, so your server already behaves the way the new spec expects.
What actually changed in the spec?
The headline is the removal of protocol-level session management. The old initialize / initialized handshake and the Mcp-Session-Id header are gone. In the spec's own words, any MCP request can now land on any server instance. That unlocks plain round-robin load balancing instead of sticky sessions pinned to one process.
There is more in the release, but most of it is layered on top rather than baked into a basic server: an extensions framework with formal governance, two official extensions (server-rendered UIs, and long-running Tasks), tighter OAuth alignment, and client-side caching hints on list responses. Roots, sampling, and logging enter a twelve-month deprecation window.
Why DenkOps connectors already fit
A DenkOps connector is a stateless streamable-HTTP server: it answers POST /mcp, holds no session, and keeps no per-connection state between calls. That is exactly the model the 2026-07-28 spec moves the whole protocol toward. Concretely:
- No session to lose. There was never an
Mcp-Session-Idto honor, so a request landing on any instance was always fine. This is the same reason MCP needs a process, not a per-request function, except now the spec agrees that the process should not hoard session state either. - A tolerant handshake. The server still answers
initialize, and it echoes back whichever protocol version the client asked for. So a client on the previous stable spec and a client on 2026-07-28 both complete the handshake against the same deployed server. No flag day. - Cache hints on lists.
tools/list,resources/list, andprompts/listalready return the spec's client-side caching metadata, so a client does not need a long-lived stream just to stay current.
None of that required a migration. New deploys advertise 2026-07-28 today.
What you do not get from us (yet), and that is fine
Being honest about scope matters more than a compatibility checkbox. The spec's optional extensions, server-rendered iframe UIs and the Tasks extension for long-running operations, are separate opt-in specifications that sit on top of a core tools / resources / prompts server. A DenkOps connector gives you that solid stateless core and the hosted OAuth flow; it does not turn those extensions on for you. The routing headers the spec mentions are a load-balancer concern, not something your handler code touches.
For the vast majority of connectors, tools an assistant calls, resources it reads, prompts it reuses, the core is the whole job, and it is already on the new spec.
What should you do?
Nothing urgent. If you want your server to explicitly advertise the new version in its handshake, redeploy and it will. Everything else keeps working. If you have not shipped a connector yet, the starter is a stateless server on 2026-07-28 out of the box, and it works with every MCP client the same way. Deploy it on DenkOps and the OAuth, access control, and now the current spec version come with it.