On July 28, the Model Context Protocol project shipped a new spec revision, 2026-07-28. I run backend engineering at GoodBarber, and our public MCP server is a live production surface: real apps, real content, real push notifications. So for us a new revision is not a changelog to skim on a Friday. It is a migration with our name on it.
We have just brought the server up to the new revision. This post is three things: the operator's cut of what changed, what upgrading a public server actually involves, and the thing we found in our logs while checking the work. The last one is the reason I'm writing.
The operator's cut of 2026-07-28
The headline is the stateless core. MCP grew up as a stateful, bidirectional protocol: an initialize handshake, a negotiated session, an Mcp-Session-Id header to carry it all. The new revision retires that entirely. Every request now self-describes in _meta: protocol version, client identity, capabilities. The practical consequence is the one server operators have wanted since day one: you can put an MCP server behind a plain round-robin load balancer with no shared session storage. If you have ever kept session affinity alive with duct tape, you know exactly which muscle just relaxed.
The rest, fast:
- Method and tool names now also travel in
Mcp-MethodandMcp-NameHTTP headers, so gateways can route and meter without parsing JSON bodies. - Multi Round-Trip Requests: a call can come back with
resultType: "input_required"and continue over stateless connections. Mid-call questions no longer need a held-open stream. - List results (tools, prompts, resources) carry
ttlMsandcacheScope, so clients can finally cache your inventory honestly instead of guessing. - Authorization hardening: RFC 9207 issuer validation, and Client ID Metadata Documents replacing Dynamic Client Registration.
- Tasks, MCP Apps, and Enterprise Managed Authorization become formal extensions instead of core features.
- Roots, Sampling, and Logging are deprecated, with a minimum twelve months of support before removal.
All four Tier 1 SDKs spoke the revision on launch day, which for a protocol this young is genuinely good release engineering.
Upgrading without breaking anyone
Here is the constraint that shapes everything when your server is public: you do not get to move your clients. Every agent that connects brings its own dialect, and you serve all of them or you break someone's production workflow.
So "upgrading" really means "adding a dialect". The old initialize path stays up for clients that expect it. The stateless path answers clients that self-describe. And one rule keeps the whole thing sane: the declared protocol version selects the behavior, never the client name. You would be surprised how tempting user-agent sniffing becomes during a migration. Resist it. The version declaration is the contract; the client name is trivia.
The other rule is older than MCP: nothing gets removed the day the spec says "deprecated". The spec gives Roots, Sampling, and Logging at least twelve months. The real clock is not the spec calendar. It is in your own logs, which brings me to the fun part.
Then we read the logs
We still verify upgrades the old-school way at GoodBarber: a human reads the code, and a human reads the logs. No dashboard, no pipeline, just grep and eyes. Last week that habit produced a whole article about llms.txt. It keeps paying for itself.
The protocol version a client speaks sits in plain text: in the initialize params for old-style clients, in the version declaration on each request for new-style ones. So during the development phase of the upgrade, we looked at who declares what on our traffic.
What we saw surprised us. Requests from OpenAI's Codex were already declaring 2026-07-28. The revision was barely two weeks old. Meanwhile, Claude clients were still opening with initialize on an earlier revision, exactly as they always had.
Let me be precise about what this is not. It is not a scoreboard. Pinning a revision and upgrading deliberately is what a well-behaved client does. Serving several revisions at once is what a well-behaved server does. Both populations got exactly what they asked for, which is the entire point of version negotiation.
But it is a data point you can only see from the server side, and it killed a lazy assumption I was carrying: that adoption of a brand-new revision would sit near zero for months, so supporting it "eventually" would be fine. In reality, part of your traffic may speak the newest revision before your migration branch is merged. And the split does not fall where intuition puts it: I would not have bet on which client family moved first.
If you run an MCP server
Four suggestions, all cheap:
- Log the declared protocol version. One field per request. It is the cheapest telemetry you will ever add, and it is the only ground truth you have for deprecation decisions.
- Test against real clients, plural. If you validate against a single vendor's client, you will quietly extrapolate that client's dialect to the whole world. Our logs contradicted our intuition within days.
- Plan removals from your version distribution, not from the spec calendar. Twelve months is a floor, not a schedule. If a revision still carries real traffic, it stays.
- Key behavior on the declared version, never on the client name. Negotiation is the contract you both signed. Honor it in both directions.
The upgrade itself was the unglamorous kind of work that never makes a launch post. But the logs made it worth a story: protocol adoption is happening faster, and more unevenly, than the discourse suggests, and every server operator is sitting on the evidence.
If you operate an MCP server: what does your version distribution look like? I am genuinely curious whether "Codex first" is universal or just our traffic.
One line on where I'm writing from: I run engineering at GoodBarber, an app platform. We run a production MCP server and publish open-source Claude Skills — so the 2026-07-28 migration is a live problem for us, not a thought experiment.
