What MCP's 2026 roadmap means for context delivery

The Model Context Protocol 2026 roadmap reads, on first pass, like infrastructure housekeeping. Stateless transport. Working Groups. Authentication extensions. A governance ladder. None of it especially glamorous, none of it framed as a product story. That framing undersells what the roadmap is actually doing.

Read as a context-delivery story, the four priorities line up. Context engineering is the discipline of getting the right information, in the right shape, into a model at the right time. MCP is the transport for that delivery. The 2026 roadmap is the maintainers’ plan for letting that transport operate reliably at the scale enterprises are pushing it to, without breaking the parts that already work.

This post walks through the four priorities, explains what each one changes for how context reaches an agent, and points to where the gaps still are.

The four roadmap priorities at a glance

Lead maintainer David Soria Parra published the 2026 roadmap in March, organized around four priority areas. Working Groups drive timelines, not calendar milestones, so individual items will land asynchronously. Here is what each priority is actually about, in context-delivery terms.

The deliberate choice that runs through all four: most enterprise-shaped work will land as extensions, not as changes to the core spec. The core stays small. The ecosystem fills in the rest.

Streamable HTTP goes stateless

Streamable HTTP, introduced in the November 2025 spec, is the transport that lets MCP servers run as remote services rather than as local subprocesses. It replaced the legacy SSE transport and, in production, has surfaced a consistent set of gaps. Stateful sessions fight load balancers. Horizontal scaling requires sticky-session workarounds. There is no standard way for a registry or crawler to learn what a server does without connecting to it and listing tools.

The roadmap calls these out directly. The goal is for Streamable HTTP to run statelessly across multiple server instances and behave correctly behind load balancers and proxies. Session creation, resumption, and migration get standardized so that server restarts and scale-out events are transparent to connected clients.

In Wire’s deployment, each container runs as a remote Streamable HTTP MCP server on a per-organization subdomain, with isolated state held per container. The transport itself is stateless from the client’s perspective; the routing layer pins each session to the right backing instance. That split, stateless transport plus container-level state, is the pattern the roadmap’s transport evolution has to support cleanly, because the alternative, stickiness on the transport itself, is exactly what fights horizontal scaling.

The practical consequence for context delivery: when this lands, the cost of operating a fleet of MCP servers drops, and the surface area for “the server I was talking to went away mid-conversation” failures shrinks. Both matter for agents that hold conversations across long tool sequences.

MCP Apps and the new shape of context

The first official MCP extension, SEP-1865 (MCP Apps, formerly mcp-ui), was released on January 26, 2026, after collaboration between MCP core maintainers at Anthropic and OpenAI and the MCP-UI Community Working Group. It is a meaningful expansion of what context can be.

Until SEP-1865, MCP context was text and structured data: tool calls, tool responses, prompts, resources. MCP Apps adds a third surface. Servers can declare interactive UI resources via a ui:// URI scheme, associate them with tools through metadata, and exchange bi-directional messages with the host using MCP’s existing JSON-RPC base protocol. The host renders the UI inside a sandboxed iframe; the user interacts directly; the agent stays in the loop.

The security model is built in, not bolted on: iframe sandboxing, predeclared templates, auditable messages, and explicit user-consent mechanisms. That matters because UI-as-context is a new attack surface. A malicious server returning a hostile UI is the visual analogue of a poisoned tool description, and SEP-1865 takes the threat seriously enough to treat sandboxing as a foundational constraint.

For context engineering, MCP Apps changes what a “tool response” can be. A weather tool no longer has to flatten its output into a paragraph the model parses. A pricing tool can return an interactive table the user manipulates and the agent observes. A long-running job can stream a live status panel. The agent’s context is now a mix of structured data, prose, and ongoing UI state. Designing what the agent sees, versus what the user sees, becomes a real context-engineering decision.

Enterprise readiness as context infrastructure

The clearest signal in the roadmap is the deliberate choice to treat enterprise readiness as an extensions problem, not a core-spec problem. The recurring pain points are familiar to anyone who has tried to deploy MCP at scale: audit trails, SSO-integrated authentication, gateway behavior, configuration portability. Each of these is, fundamentally, about context delivery.

Audit trails are about asking, after the fact, “what context did this agent see, and where did it come from?” SSO is about scoping which context any given agent is allowed to reach. Gateways are the policy enforcement point that decides which context flows and which does not. Configuration portability is about whether an agent’s working set of MCP servers travels cleanly between environments.

OAuth 2.1, adopted in the June 2025 spec, established the auth foundation. MCP servers are classified as OAuth Resource Servers, with RFC 8707 resource indicators scoping tokens to specific servers. That gives gateways and identity providers a stable hook to integrate against. The roadmap signals that the rest of the enterprise stack, audit-log formats, gateway-to-server contracts, configuration export and import, will land as extension SEPs led by an Enterprise Working Group that has not yet formed. The maintainers are explicit that they want practitioners running MCP in production to lead this work.

In the meantime, the gateway ecosystem (Cloudflare’s reference architecture, MintMCP, MCP Manager, and others) is filling the gap. Expect consolidation around extension SEPs once the Working Group is in place. Until then, treat your gateway choice as a load-bearing dependency and isolate it behind your own abstractions.

Agent-to-agent communication: where context crosses boundaries

The agent communication priority is the least specified in the roadmap and, arguably, the most consequential. Once agents start handing context to each other, every problem in single-agent context engineering compounds.

Wire’s published research on multi-agent context handoffs and why multi-agent systems fail at context describes the specific failure modes: provenance gets stripped at the boundary, summaries replace evidence, and downstream agents inherit confidence without inheriting the underlying ground. The roadmap signals that registry, discovery, and inter-agent messaging patterns are coming. The shape they take will determine whether context survives the handoff or whether each crossing degrades it further. This is the priority area worth watching most closely if your architecture involves more than one agent in a loop.

Governance: how context-delivery standards get made

The governance priority is process work, not protocol work, and it matters because the rest of the roadmap depends on it. The Governance Working Group is expected to deliver a Contributor Ladder SEP defining the progression from community participant through Working Group contributor and facilitator up to lead maintainer and core maintainer, with explicit nomination and review criteria at each step.

That sounds bureaucratic. The reason it matters: the surface area of MCP is now large enough that no small core team can shepherd every extension. Treating governance as a first-class deliverable is the maintainers admitting that and putting structure around it. For the people building on MCP, the practical effect is a clearer answer to “where does my proposed extension actually go?” Today the answer is informal. By the end of 2026, it should be a published path.

What this means if you’re building agents now

A few practical takeaways while the roadmap rolls out:

Build against stable surfaces. OAuth 2.1, Streamable HTTP, and the November 2025 spec are stable enough to deploy on. Treat them as the contract.

Isolate the moving parts. Stateful session behavior, audit-log formats, gateway interfaces, and inter-agent communication patterns are all in motion. Wrap them in your own abstractions so you can swap implementations without rewriting agent logic.

Treat extensions as the default. The maintainers’ deliberate choice to keep the core small means most of the new capability you care about will arrive as extension SEPs. Watch the Working Group output, not just the spec versions.

Design context for the surfaces that exist today. MCP Apps adds UI as a context surface. Tools still return structured data. Resources still serve documents. The job, as ever, is to put the right shape of information in front of the model at the right moment. The transport is getting better. The job stays the same.

If you want to see what a remote Streamable HTTP MCP server looks like in practice, Wire gives you one as soon as you create a container.

Sources: The 2026 MCP Roadmap · MCP specification 2025-11-25 · SEP-1865: MCP Apps · MCP Apps extension repo · WorkOS: MCP’s 2026 roadmap makes enterprise readiness a top priority · The New Stack: MCP’s biggest growing pains will soon be solved · Cloudflare: Scaling MCP adoption