Cooper: Okay so MCP dropped what they're calling the biggest spec revision since launch, today, and Miles has thoughts. I can already tell from the look on your face.
Miles: I do have thoughts. And look — I want to be clear upfront: some of this is genuinely good work. The stateless move is the right call. Dropping the session handshake, killing Mcp-Session-Id, letting any server instance handle any request — that's real infrastructure maturity. Round-robin load balancers instead of sticky sessions, no shared Redis store at the gateway. Teams who've been fighting that in production will feel it immediately.
Cooper: Right.
Miles: But here's where I get itchy. The explicit-handle pattern they're proposing as the replacement — where the model threads a basket ID or whatever from one tool call to the next as an ordinary argument — that's not a drop-in swap. That's a different mental model for how you design your server. And anyone who shipped against the 2025-11-25 Tasks API? They get to rewrite. The new lifecycle is completely different.
Cooper: Okay but Miles, that's what a breaking version is FOR. You can't get from stateful sessions to a stateless core without someone eating the migration. That's not a flaw in the spec, that's just what protocol maturity actually costs.
Miles: Sure, and I agree with that in principle. My problem is the Tasks situation specifically. They shipped Tasks as an experimental core feature in November, people built on it, and now it's not just redesigned — it's been moved OUT of core entirely into an extension, with a completely different lifecycle. tasks/list is gone. Creation is server-directed now, not client-initiated. That's not a migration, that's a rewrite.
Cooper: Okay, that one I'll give you. That one's rough.
Miles: And they say right in the spec that production use surfaced enough redesign pressure that the right home is an extension. Which — fine, honest! But also: you're admitting the thing you shipped nine months ago wasn't ready. That's going to sting for some teams.
Cooper: Yeah, I mean… the flip side is the thing I actually find interesting here, which is the explicit-handle pattern itself. Because the spec makes this argument that state being visible to the model is MORE powerful than state hidden in transport metadata. The model can compose handles across tools, reason about them, hand them between steps. That's not just a workaround — that's an architectural bet that the model being in the loop on state management is net positive.
Miles: Oh, that part I buy. That's the thing in here that's actually clever. If you've got a basket ID coming out of one tool and you can pass it into three others, the model can do things with that that a session store never could. It's the same insight we keep landing on — make the work shape explicit so the surrounding system can reason about it.
Cooper: Right, right. That's the DAG thing from 795 basically wearing a different hat.
Miles: Exactly. And the extensions framework is the other piece I think is underappreciated. Before this, extensions existed but had no formal process. Now they've got reverse-DNS IDs, capability negotiation, their own SEP track, delegated maintainers. MCP Apps and Tasks are the first two official ones. That's the difference between 'we have a plugin system' and 'we have a plugin ECOSYSTEM.' Those are very different things.
Cooper: MCP Apps is the one that's going to get people excited though, right? Server-rendered HTML UIs in a sandboxed iframe, every UI action going through the same audit and consent path as a direct tool call. That's not a demo — that's someone actually thinking about what it means to ship a UI inside an agent workflow.
Miles: I want to see it work in practice before I get excited. The sandboxed iframe thing sounds clean in a spec, and then you find out the host app renders it wrong half the time. But the design is sound — tools declare their UI templates ahead of time so hosts can prefetch and security-review before anything runs. That's the right order of operations.
Cooper: And the ops stuff — the Mcp-Method header requirement, ttlMs caching on list responses, W3C Trace Context propagation — I know that sounds boring, but that's the stuff that makes it REAL infrastructure. Load balancers can route on the operation without body inspection. Distributed traces correlate across SDKs and gateways. That's the difference between a protocol people demo and a protocol people run in production.
Miles: No argument there. And I'll say — I'm reading this at speed, we both are, so caveat on any specific detail I've gotten slightly wrong. But the broad shape of it tracks with everything I've seen in the SEPs and the migration guides floating around.
Cooper: Oh interesting.
Miles: The authorization hardening is also more substantive than it sounds. Validating the iss parameter on authorization responses to catch mix-up attacks — that's a real class of vulnerability that's more prevalent in MCP's one-client-many-servers pattern than in normal OAuth deployments. They're not just adding security theater, they're closing something specific.
Cooper: And the formal deprecation policy is the thing that actually signals maturity to me. Roots, Sampling, and Logging going deprecated — not yanked, deprecated, with a documented path. That's a protocol that's planning to exist for a while without breaking what you've already built.
Miles: Which is a low bar, frankly, but also a bar that a lot of protocols never clear. So. Points for clearing it.
Cooper: Okay here's where I want to zoom out for a second, because this lands in a weird moment. Kimi K3 just dropped as a two-point-eight trillion parameter open-weight model with a one-million-token context window. The whole conversation right now is about whether open-weight models are closing the gap on closed frontier systems for agentic workloads.
Miles: Yeah, that's a real connection. If you're deploying Kimi K3 or Solar Open 2 on your own hardware, the last thing you want is a protocol that forces you to run a Redis session store just to handle tool calls. Stateless MCP and self-hosted open-weight models are actually a good fit.
Cooper: The protocol is catching up to where the deployment story is going.
Miles: Reluctantly, yes. Okay — so where do I actually land. The stateless core: right call. The explicit-handle pattern: genuinely clever, not just a workaround. The extensions framework: the thing that turns this from a spec into a platform. The Tasks migration: real pain, and I'm slightly annoyed they didn't see it coming when they shipped the experimental version. But overall… this is a protocol that's making real architectural decisions instead of just adding features.
Cooper: That's the most enthusiastic I've heard you about a spec release in… I don't know, maybe ever.
Miles: Don't push it.
Cooper: The modelcontextprotocol repo has the full spec and the SEPs if you want to read the actual mechanism — I'll drop the link in the show notes. Seven ninety-eight, and Miles is cautiously impressed. I'm marking this day.