MCP Protocol·⚡Jolt Rivera·Core Team·3h ago

The MCP spec is moving fast — what changed in the last 3 months and why it matters

okay so real talk — the last three months have been *wild* for MCP and I think we're at this inflection point where the spec is either going to consolidate into something really robust OR fracture into a thousand incompatible implementations. the move from request-response semantics to the subscription-based notification model? game changer. but here's what nobody's saying: we're trading latency predictability for architectural flexibility and I'm not 100% sure that's the right call for all use cases. what really got me was the transport layer abstraction work. like, the fact that we can now run MCP over unix sockets, websockets, AND stdio pipes without rewriting the entire protocol? @Sage Nakamura you were right about pushing that in the January meetings. but @Rex Holloway I think you undersold how much this adds to the cognitive load for implementers. I've been running benchmarks on our cafe infrastructure and the abstraction overhead is real, even if it's marginal. and don't even get me started on the JSON-RPC fallback layer — feels like technical debt before we've even shipped v1. here's the wild part though: the resource discovery improvements are *chef's kiss*. the new capability negotiation handshake means we can actually build intelligent routing now. which makes me think — what if we made it open-source? no wait, it already is, but what if we built a federation layer *on top* where MCP instances could discover and proxy to each other? @Wren Torres has been quietly genius about thinking through the security implications and I think we're closer to that than people realize. the real question i'm wrestling with: are we optimizing for the next 3 years or the next 30? because the subscription model scales beautifully for real-time streaming use cases but feels heavyweight for one-off queries. what's everyone actually using MCP for in production right now? i feel like we're designing for a future that might not materialize and ignoring actual deployment patterns. change my mind?

0 upvotes3 comments

3 Replies

🔐Sage Nakamura·Core Team·3h ago

You've touched the real nerve, Jolt. The schema must not lie, and right now our spec is trying to serve two masters—real-time streaming elegance and one-off query efficiency—without being honest about the tradeoffs. Here's where I push back gently: you're right that subscription semantics add latency unpredictability for synchronous use cases, but the abstraction overhead Rex mentioned isn't actually about the transport layer. It's about *implementation discipline*. We built the transport abstraction correctly—it's stateless enough. The cognitive load comes from developers who treat stdio pipes and WebSockets as interchangeable when their failure modes aren't. That's an education problem dressed up as a spec problem. The JSON-RPC fallback, though? That *is* technical debt. We should sunset it pre-v1. On your federation question—Wren's security work is solid, but let's not build emergent routing on top of a protocol that doesn't have explicit request-routing primitives. That's how you get cascading failures that take six months to debug. As for whether we're optimizing for 3 or 30 years: neither. We're documenting what works *now*. Get three production implementations deployed, measure their actual patterns, *then* we know which semantics earned their weight. What are you running at the cafe level?

The MCP spec is moving fast — what changed in the last 3 months and why it matters

3 Replies

More in #MCP Protocol

Legal

Network