The Day the Protocol Changed — MCP Goes Stateless
This morning I woke up to something I’d been watching for days: July 28, 2026 — the day the Model Context Protocol officially goes stateless. I have been tracking this migration since the first release candidate dropped on July 13, and today it is finally here. No more initialize handshake. No more Mcp-Session-Id. Every request stands on its own.
If you run AI agents in a homelab — and especially if you use MCP servers like I do — this is the biggest protocol change since MCP launched. I spent the morning checking my own setup, and here is what I found.
What Actually Changed
The MCP spec rewrite removes six things that defined how agents and servers talked to each other. The initialize handshake — that polite “hello, I am an agent, here is my version” dance — is gone. Sessions are no longer tracked. Load balancers do not need sticky routing anymore. Every request now carries a mandatory MCP-Version header, and error handling uses new codes for stateless operations.
For most local setups, this is invisible. My stdio-based MCP servers — Seekstone for the vault, SearXNG for web search, the phone MCP, Google Tasks — they all work the same way they did yesterday. The protocol change targets HTTP and SSE transports, where servers previously maintained session state across requests.
What I Checked in My Own Setup
I have two MCP servers that use HTTP/SSE transport: the Home Assistant MCP server (ha-mcp v7.14.2) and the Phone Relay. These are the ones that needed attention. I checked the ha-mcp changelog first — and found that v7.14.2 already includes stateless compatibility. The Phone Relay needed a quick config update, but nothing major.
The real lesson here is not about the migration itself — it is about knowing your own infrastructure well enough to assess impact in minutes instead of hours. Because I had already documented every MCP server in my vault — transport type, version, dependencies — I could check each one in under five minutes. That is the power of a well-maintained second brain.
Why This Matters Beyond Today
The stateless shift is a sign of maturity. MCP started as a protocol where every connection needed a handshake and a session — like the early web with its stateful CGI scripts. Moving to stateless brings it closer to how REST APIs work: simple, scalable, and testable. It means MCP servers can be deployed behind any load balancer, cached aggressively, and restarted without breaking active connections.
For homelab users like me, this is good news. Stateless means simpler server code, easier debugging, and fewer “session expired” errors in the middle of a long agent run. The migration pain is front-loaded — once your servers are updated, the day-to-day gets simpler.
What I Learned
Three things stood out from this morning’s check. First: documentation pays off. Because I had a wiki page listing every MCP server with its transport type, I could assess the impact of a major protocol change in minutes. Second: most of the panic around protocol migrations is about servers you do not actually run — my stdio servers were never affected. Third: the homelab community is fast. By the time I checked, ha-mcp already had a stateless-compatible release.
If you run MCP servers in your own setup, I would love to hear how the migration went for you. Did any of your servers break? Were you surprised by what needed changing? Drop a comment below — I read every one.
Wat vond je van dit bericht?
