Two weeks ago I opened the config of the MCP server I run behind one of my Spring Boot services to add a second instance behind the load balancer, and remembered, with the specific annoyance of a developer who has been here before, that the thing held session state. Protocol sessions, initialization handshakes, sticky routing. A protocol for agents, the most stateless-feeling workloads imaginable, and horizontal scaling meant session replication or pinned connections.
That complaint is now officially obsolete, and four other things I have grumbled about are on the chopping block too. The MCP maintainers published a new roadmap this week (241 points on Hacker News and climbing), and unlike most protocol roadmaps, this one reads like a list of the exact papercuts you hit if you actually run MCP servers in production. It covers what landed in the 2026-07-28 spec release and five priority areas for what comes next.
Full disclosure: this is an analysis of the maintainers' roadmap, not a review of shipped final features. The 2026-07-28 changes are real and live in current SDKs. The five priority areas are direction, with SEPs at various stages. My production servers still largely speak the older shape, so where I tell you what I would do, that is a plan, not a war story.
Here are the five shifts that matter if you build agents in Java, and the decision each one forces.
Shift 1: Sessions Are Gone, and Your Architecture Should Notice
The single biggest change already shipped. In the 2026-07-28 spec release, protocol-level sessions and the initialization handshake were removed (SEP-2575, SEP-2567). A remote MCP server is now, in the maintainers' words, "no different from any other HTTP workload." Clients can also call server/discover to learn supported versions and capabilities before doing anything else, and list results became cacheable (SEP-2549).
For a Spring Boot shop this is the most Java-friendly thing MCP has ever done. An MCP server is now just another stateless HTTP service, which means everything you already know applies: plain @RestController semantics, no sticky sessions in your ingress, scale-to-zero on serverless if you want it, and normal readiness probes instead of protocol-aware health checks.
What I would do: if you run MCP servers with sticky routing or in-memory session maps, budget a sprint to strip that out against the current SDKs. The interim hack I used, externalizing session state to Redis so any instance could serve any client, was tolerable but it added a network hop and a failure mode to every tool call. The protocol removing the need for it entirely is the kind of rare good news you should act on while the migration is small.
Shift 2: Server-Initiated Requests Are Out, Multi Round-Trip Is In
The pattern Java teams should relearn. The old spec's server-initiated requests (server calling back into the client) never sat well with stateless deployments and corporate firewalls. The roadmap confirms Tasks were reworked into an official extension (SEP-2663), and a new Multi Round-Trip Requests pattern (SEP-2322) replaces server-initiated requests so elicitation and similar flows work on stateless servers.
In practice: the client polls, or subscribes, rather than the server pushing requests down a channel it opened. Feels archaic until you remember this is exactly how REST APIs won. The roadmap's next step here is server-initiated events through webhooks and channels, "so clients aren't left polling for results."
What I would do: stop designing tools that assume a persistent bidirectional pipe. If you have long-running tools (my log-analysis tools can run for minutes), model them as Tasks: kick off the work, return a task handle, let the client check back. That shape survives every transport change on the roadmap, because it assumes nothing about connections.
Shift 3: Agent Identity Is Coming, and Java Is Weirdly Ready for It
This is the one I care about most. Today, MCP authorization is built around a person approving access in a browser. The roadmap's point is that more and more callers are agents: cloud workloads with their own identity, acting on behalf of a user who is not present, or delegating narrower authority to sub-agents. The plan is a standardized way for servers to recognize and trust those identities, "built on existing standards rather than pasted API keys and long-lived tokens."
Anyone who has wired an agent to a third-party API knows the current reality: a SECRET_AGENT_API_KEY in an environment variable, no expiry, no scoping, no proof the caller is who it says it is. When that agent spawns three sub-agents, they all share the god-key.
The concrete mechanisms named are Demonstrating Proof of Possession (DPoP, RFC 9449) and Workload Identity Federation, plus engagement with the IETF OAuth and WIMSE working groups. Enterprise-Managed Authorization, the enterprise extension built on this machinery, is already stable.
Here is the part that should make a Java developer smile: the Spring ecosystem already speaks DPoP. Spring Authorization Server 1.5 (GA May 2025) issues DPoP-bound tokens, and Spring Security 6.5 validates DPoP proofs on resource servers. DPoP binds an access token to a key the client holds, so a stolen token is useless without the private key. For an agent identity story, that is the difference between "someone leaked the token" and "the token is only usable from the workload that owns the key."
What I would do: if you are building an MCP server today that will ever face another team's agents, do not build your own API-key layer. Stand up Spring Authorization Server, require DPoP-bound tokens, and treat MCP's future agent-identity work as an adoption of patterns you already run. You will migrate by configuration, not by rewrite.
Shift 4: Progressive Tool Discovery Fixes a Problem You Have Already Hit
The quietest item with the biggest model-quality impact. The roadmap is blunt about scale: "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows." The fix is progressive discovery: a small entry point, with more of the catalog revealed as the conversation narrows.
This matches what I have seen with my own agent wiring. Past a few dozen tools, the model starts picking plausible-sounding wrong tools, and your prompt budget bleeds into tool schemas on every single call. When I wrote about exposing Spring Boot services as MCP servers earlier this month, my advice was to label tools honestly and keep the surface small. The protocol is now formalizing that advice.
There is also a contracts cleanup: a tools/call response can currently carry the same output in multiple forms, and a server developer has no way to know which form a client will put in front of the model. The roadmap aims to standardize on one clear contract.
What I would do: design your tool catalog as a tree now, even before the mechanism lands. Group tools by domain, expose a summarizing "list capabilities" tool as the entry point, and have detail tools reference their group. When progressive discovery arrives in SDKs, your shape maps onto it directly instead of demanding a redesign.
Shift 5: One Transport To Rule All of Them
The unglamorous cleanup that shrinks your codebase. With 2026-07-28, remote MCP servers became ordinary HTTP workloads. The roadmap wants to stretch that to local servers too: local servers speaking Streamable HTTP over stdio, "unifying on one transport" to simplify both server and client development.
If you have maintained dual transport paths, one for local stdio servers and one for remote HTTP, you know the cost: two config surfaces, two failure modes, two sets of bugs. One transport means one.
What I would do: nothing urgent, but stop investing in stdio-specific handling. Any abstraction you own that branches on transport type is technical debt with a known payoff date.
The Checklist I Am Handing My Own Team
- Strip session stickiness from MCP server deployments; target the stateless 2026-07-28 shape (spec changelog)
- Model long-running tools as Tasks, never as tools that assume a live connection
- Replace homegrown API keys with Spring Authorization Server + DPoP (1.5+ / Spring Security 6.5+) so agent identity arrives as config, not rewrite
- Tree-shape your tool catalog now, before progressive discovery lands
-
Adopt
server/discoverand cached list results to cut redundant round trips per session -
Watch the Server Card Working Group:
.well-knownmetadata will let clients reason about your server before connecting, so keep that file accurate from day one
What I Would Do Differently
I spent too long treating MCP as a chat-app protocol I had to accommodate, and my first server design showed it: stateful, session-pinned, one transport, key-based auth I invented myself. Every one of those choices is now deprecated by direction of travel. The lesson I would hand my past self: when a protocol backed by every major lab publishes a roadmap, read it as a preview of your next refactor, and align early while alignment is cheap.
The roadmap is also unusually open to contribution. SEPs in priority areas get expedited review, Working Groups triage their own areas, and there is room for more contributors everywhere. Java is underrepresented in MCP client and server implementations relative to its enterprise footprint, which means a Java perspective in the Agents or Transports working groups has outsized leverage right now.
The Bottom Line
MCP is consolidating around the boring, proven patterns of the web: stateless HTTP, federation-backed identity, progressive disclosure of capability. If you run Spring Boot services, that consolidation plays directly to your stack's strengths. The teams that treat this roadmap as a to-do list will migrate by configuration. The teams that ignore it will migrate by rewrite, later, under pressure.
Have you run an MCP server in production yet, or is your agent stack still on direct SDK calls? What broke first? I read every comment, and the war stories are how the rest of us learn.
I write about Java, Spring Boot, and AI every week. Subscribe — it's free.
Top comments (0)