The standard already won. Now comes the hard part
Back in April we wrote that MCP was the USB of enterprise AI: the standard that separates "what the agent can do" from "who the agent is". Three months on, that battle is settled. MCP won adoption: clients support it, vendors ship official servers, and the question inside companies is no longer "MCP or a custom integration?" but "when?".
The official 2026 roadmap — published in March by David Soria Parra, the protocol's lead maintainer — is about the next phase: turning a standard that works in demos and small deployments into a protocol that holds up in the enterprise. Four fronts: scalable transport, server discovery, task semantics, and enterprise readiness.
Read with an architect's eye, the roadmap says two things at once: where the protocol is going and — just as important — which gaps it admits to having today. Both matter if you're deciding how much to invest in MCP this year.
Stateless sessions: MCP versus the load balancer
The most cited problem with MCP's HTTP transport is textbook: stateful sessions fight load balancers. If your MCP server holds session state, scaling it horizontally demands sticky sessions, shared session layers, or workarounds no platform team wants to maintain. It's the same problem web backends solved fifteen years ago, resurfacing in the agent layer.
The roadmap tackles it head-on: a stateless session model so an MCP server scales like any HTTP API. No new transports this cycle — an explicit decision — just doing the existing one properly.
The practical read: if you're building an MCP server today, design your handlers stateless from the start. It isn't only about aligning with the roadmap; it's that everything the protocol is about to add assumes that discipline. Business state lives in your systems; the MCP session is transport, not memory.
Discovery without connecting: the .well-known that was missing
Today, finding out what an MCP server exposes means connecting and asking for the tool list. Sounds like a detail. In production it's a problem with a measurable cost.
A data point from our own operation: the official MCP server for Plane — the project manager — exposes 139 tools, roughly 453 KB of definitions. That's on the order of 113,000 tokens of catalogue before the first call. In our case it meant a client with a finite context budget would discard the whole server on connect: it didn't fit. No warning, no partial degradation. The server read as "connected" and none of its tools existed for the agent. We diagnosed it by measuring the handshake by hand; neither side tells you.
Clients are already papering over it themselves. Claude Code now loads only the tool names and defers the schemas until the agent asks for a specific one, so the same server that used to vanish works today. The catalogue hasn't slimmed down — we measured it again: 452,817 bytes, the same 139 tools. What changed is who pays the context, and when.
Every client having to invent its own strategy for that is the definition of a gap in the protocol.
The roadmap proposes a metadata format served from a .well-known endpoint: the client will be able to know what a server exposes — and how much it weighs — before establishing a connection. For internal server catalogues, corporate gateways, and clients with a context budget, it's the missing piece.
While we wait, the design lesson already holds: a tool catalogue has a cost, and the agent's context pays it. An enterprise MCP server isn't the one exposing the most operations; it's the one exposing exactly the right ones, well described. Our criterion since the first server we built: a handful of coarse-grained tools aligned with use cases, rather than a 1:1 mirror of the internal API.
Tasks: retries and expiry, or distributed systems reach the protocol
The Tasks primitive — long-running work an agent hands off and checks on later — landed in the protocol as experimental, and the roadmap refines it with experience from real deployments: retry semantics for transient failures and expiration policies for how long results are retained after completion.
If that sounds familiar, it's because it's the same conversation distributed systems have always had: retries, idempotency, retention. The agent layer doesn't invent new problems; it inherits the old ones under new names. The protocol starting to standardise them is a good sign — it means there's enough MCP in production for them to hurt.
The implication for anyone building today: don't wait for the protocol. Your server needs its own retry semantics and idempotency now, because the agents consuming it fail, retry, and duplicate calls now. When the standard formalises its own, adapting a disciplined implementation will be trivial; rescuing one that assumed every call arrives exactly once will not.
Enterprise readiness: what the protocol admits it lacks
The fourth front is the most revealing, precisely because of what it concedes: audit trails, SSO, gateway behaviour, and configuration portability are gaps in the ecosystem today. The roadmap sets out to form a Working Group and anticipates that most of it will be resolved through extensions rather than in the protocol core.
Translated for a CTO: enterprise adoption of MCP is running ahead of its enterprise guarantees. Who called which tool with which arguments, under which identity and with what result — the question compliance will ask sooner or later — is answered today in your layer, not in the protocol. Your own gateway, structured logging per tool, permissions per operation and per identity. That's how we build it, and it will remain the integrator's responsibility for a while yet, Working Group or no Working Group.
This isn't an argument against MCP. It's the normal state of a young standard that has grown faster than its periphery. But it pays to go in with your eyes open: adopting MCP doesn't hand you auditing or access control for free. It hands you the integration contract; governance is still yours.
Governance: the signal a decision-maker should read
The least technical front of the roadmap is the one that says most about the protocol's longevity: a documented contributor ladder and a delegation model so Working Groups can approve changes in their domain without routing every proposal through the core maintainers.
Standards die in two ways: abandonment or bottleneck. MCP is institutionalising its governance at exactly the phase where serious protocols do. For a company weighing whether building on MCP means betting on something that will still exist in five years, this is the signal — more than any feature.
Invest now or wait?
The question that makes anyone read a roadmap. Our answer, after building both sides of the protocol — servers that expose business systems and clients that consume them:
Invest now in what the roadmap won't change. The design of your tools — few, coarse-grained, well described —, input and output validation, permissions per operation, your auditing and your retry semantics. All of that is yours, survives any version of the protocol, and is 80% of the work of a serious MCP server.
Don't couple yourself to what will change. The details of session handling, the discovery mechanisms, the concrete implementation of Tasks. Treat them as what they are: the evolving surface of the protocol. A thin adaptation layer between your logic and the MCP transport lets you absorb the entire roadmap without rewriting anything.
The 2026 roadmap confirms April's thesis: MCP is serious, and it's heading for the enterprise. Teams that arrive with disciplined servers — stateless, audited, with tool catalogues that were designed rather than dumped — will absorb every protocol improvement for free. Those that arrived with a mirror of their internal API and 139 tools will find the standard matures faster than their shortcuts.
If you're evaluating MCP to connect agents to your systems — or you already have servers deployed and want to know whether they'll hold up — we audit your integration architecture against this roadmap and hand you the concrete plan: what to expose, how to secure and audit each tool, and where to put the adaptation layer so the protocol can evolve without dragging you along.
