MCP Gets Stateless, and Jiu-Jitsu's Guard Pass Finally Makes Sense

When the Protocol Lets Go of the Grip

There's a moment in jiu-jitsu when you realize that holding onto the gi isn't the same as controlling the position. You grip, you pull, you hang on—and then someone shrugs you off because you were too busy gripping to actually move. The Model Context Protocol just went through that exact lesson.

On July 28, 2026, the MCP spec dropped its session handshake, its session IDs, and the whole idea that a conversation needs to be tied to a specific server instance. Now every request stands on its own. No baggage. No memory of the last move. It's like switching from a guard that requires constant grips to a guard that just floats there, waiting for you to do something smart.

The change is getting a lot of attention for making MCP stateless. But the quieter part—the addition of two mandatory HTTP headers—might matter even more for how people actually run this stuff in production.

The Old Guard: Why Sessions Were a Pain

Before this update, MCP worked like a long, slow roll with a white belt who won't let go of your lapel. You'd open with initialize and initialized, establish a session, and then every single request had to carry a Mcp-Session-Id header. The server had to remember what happened earlier, which meant the whole infrastructure had to keep that state alive.

If you were scaling out, you had to keep sessions sticky. If you were deploying, you had to drain or migrate those sessions. Load balancing? Forget it—the client was glued to the instance that held its session. It was like trying to roll with a partner who refuses to reset when you switch mats.

Developers knew this was awkward. They just didn't know how awkward until they tried to put MCP behind a real gateway.

The Transition: Every Request Stands Alone

The new spec strips the handshake and the session header out of the core request path. Each request now carries its own protocol version, client identity, and capabilities. Any request can land on any instance, and the server doesn't need to remember a thing.

That's a big deal for scaling. But here's what most people missed: the request body used to be the only place where you could tell what the request was doing. The gateway had to open the JSON-RPC payload, read it, and figure out whether you were listing tools, calling a tool, or reading a resource. That's like trying to read your opponent's intentions by watching his toes—possible, but slow.

Now the streamable HTTP requests include two required headers: Mcp-Method and Mcp-Name. A tool call shows up as Mcp-Method: tools/call and Mcp-Name: search, followed by the JSON-RPC payload. The gateway can read those headers and route, rate-limit, or meter traffic without ever opening the body. It's the same mechanism you already use for every other API.

Cloudflare's Matt Carey spelled out the benefits in detail. Gateways, rate limiters, and WAFs can now act on the method or the tool directly. One Hacker News commenter, evalstate, pointed out that you could even copy tool parameters into headers for custom routing. That's like seeing your opponent's grip before he even pulls guard—you can start your pass early.

Jiu-Jitsu's Guard Pass, Minus the Grips

Think about how you pass the guard in jiu-jitsu. If you grip the pants and pull, you're committed to that grip. If the guy shakes it off, you're back to square one. The smarter pass is to use your hips, your weight, and your pressure—not your grips. You don't need to hold onto anything to control the position.

MCP just made that same transition. It stopped holding onto the session and started using headers as a lightweight way to communicate intent. The result is a protocol that behaves more like a REST API—and that's not a bad thing.

But there's a deeper parallel. In jiu-jitsu, the guard pass only works if you understand the whole position, not just the grip. MCP's move to statelessness only works because the headers give you just enough information to act without the full context. It's a trade-off: you lose the memory of previous moves, but you gain the ability to act quickly and independently.

Community Reactions: Same Move, Different Camps

The Hacker News thread was split, but not over whether stateless is better. Everyone agreed it's an improvement. The real fight was over what this says about MCP's origins.

One camp says MCP was never meant to be stateful. drdexebtjl put it bluntly: "In hindsight, stateful MCP was obviously wrong. This effectively turns MCP into another REST API endpoint and lets you use the same infrastructure you already have for REST APIs—load balancers, API gateways, progressive rollouts, and so on."

pjmlp saw it as the same lesson the industry keeps learning, going back to Sun RPC: stateless servers are always better. Use state only when you absolutely can't avoid it. luciana1u was even more direct: "We invented a stateful protocol, discovered state is hard to scale, stripped it out, and ended up with 'just send a POST.' The REST crowd has been waiting 20 years for this moment."

bloppe took a structural view, describing MCP as a REST-like API with a spec that OpenAPI already provides, plus authorization at the framework level. Only the last part, he argued, is genuinely new.

The other camp doesn't deny the similarity. They just don't think it matters. lexicality pointed out that MCP is really just JSON-RPC with a set of conventions that models have been trained on. vidarh nailed the counterargument: "The core advantage of MCP is that it's a standard that AI providers endorse, so people have a strong incentive to actually implement it."

Even the implementers are on board. Sentry's co-founder and CPO, David Cramer, who previously wrote that MCP wasn't good enough, told Cloudflare the update finally cleans up authentication and tool handling. His line: "Agents only become useful when the underlying plumbing stops being the whole story."

Authorization Tightens: No More Free Rides

The spec also tightened up how servers and clients prove who they are. Dynamic client registration is deprecated and will be removed after summer 2027. They've adopted RFC 9207 for issuer identification, and clients now send the canonical server URI as an RFC 8707 resource, so tokens are only accepted by the intended audience.

That's like making sure the guy you're rolling with actually knows your gym's rules before you let him near your guard. It's not flashy, but it prevents a lot of problems down the line.

CLI vs. Protocol: The Other Debate

There was a parallel thread asking whether agents even need a protocol at all—maybe they should just access plain CLI tools through a shell. firasd pushed back, noting that the CLI stance assumes the user is a developer on a laptop with a shell open in their coding environment. But most real uses come from mobile apps, web chats, and embedded components. You can't expect a phone app to spawn a shell.

It's like saying jiu-jitsu only matters if you're training in a gi with a belt. Sure, that's one version. But no-gi, MMA, and self-defense all have their place too.

Adoption Is Real, But Where's the Money?

The adoption numbers are undeniable. Anthropic says MCP SDK downloads have passed 400 million per month, tripling this year. But whether that adoption actually translates into useful server usage is another question.

One consulting firm on r/AI_Agents shared an audit of a client's server that recorded 61 tool calls over three months—58 of which came from the client's own engineers. The post's takeaway: teams confuse "agents can access this" with "agents will access this." The author, who disclosed that MCP work makes up a big chunk of their consulting revenue, concluded that the money is flowing to gateways, registries, and authentication layers, not to the servers themselves.

That's a sobering thought. But it also echoes jiu-jitsu: you can have all the techniques in the world, but if you never actually use them in a roll, they're just flashcards.

What This Means for Your Roll

If you're running MCP in production, the migration isn't trivial. Servers that rely on protocol sessions, server-to-client requests, or independent streams will need to run a stateless route alongside the old stateful path, migrate features over, drain active sessions, and then remove the old path before the deprecation window closes. The spec and the updated TypeScript, Python, Go, and C# SDKs are already available.

But the bigger lesson is about letting go. MCP gave up its session state to become faster, more scalable, and more compatible with the infrastructure you already have. It's a trade that any jiu-jitsu player would recognize: sometimes you have to give up the grip to get the pass.

And just like in jiu-jitsu, the real improvement isn't in the technique itself. It's in how it lets you move.