MCP's Biggest Overhaul Kills Sessions and Handshakes—Here's What Breaks in Java
MCP servers can now be deployed like ordinary HTTP microservices—no sticky sessions, no shared state stores, no gateway deep-packet inspection. For Java teams, the immediate risk is assuming Spring AI's STATELESS mode equals the new spec; it doesn't, and that confusion will produce hard-to-diagnose interop failures when clients and servers mix protocol generations.
The 2026-07-28 MCP specification is the protocol's largest upgrade, eliminating the initialize handshake, Mcp-Session-Id, ping, and all server-initiated requests. Every request now carries its own identity and capabilities in _meta fields, and stateful workflows move to explicit server-minted handles passed as ordinary tool parameters. Multi Round-Trip Requests (MRTR) replace the old server-to-client calls, and a new server/discover RPC lets clients probe protocol versions without a handshake.
In the Java ecosystem, LangChain4j 1.19 already supports the new spec on the client side, but its default 30-second auto-detection timeout causes stealthy startup delays. The MCP Java SDK and Spring AI remain on the 2025-11-25 spec, and Spring AI's STATELESS mode is a different, older form of statelessness—not the new protocol. Literal error-code matching against -32002 will silently break when servers upgrade, and the old Tasks API requires a mandatory migration.
Remote MCP servers gain the biggest operational win: they can now sit behind round-robin load balancers without sticky sessions, shared session storage, or deep packet inspection. The protocol is converging on HTTP's request/response model, and the Java server-side tooling is roughly one version cycle behind the client libraries.
The protocol is deliberately converging on HTTP's request/response model—MCP wants to be the HTTP of AI tool calling, and this spec makes that architectural bet explicit.
Spring AI's STATELESS mode solves multi-replica deployment but is a 2025-11-25 variant, not the new spec; calling it 'stateless' creates a naming collision that will confuse teams during the migration cycle.
The 30-second auto-detection default in LangChain4j is a pragmatic choice for subprocess-based servers but a performance trap for remote-server setups, and the silent-warning fallback makes it hard to notice.
Explicit handles are arguably more capable than sessions because the model can reason about them, combine them across tools, and pass them around—state becomes a first-class concept the LLM can manipulate.
Error-code literal matching is the kind of silent failure that survives code review because it looks correct; the -32002 to -32602 change will break conditionals without any exception or log line.
The Java server-side SDK lagging behind the client libraries is a recurring pattern in protocol adoption, but the annotation-based tool model means most user code won't need changes when the SDK eventually upgrades.