MCP 2026 Spec Update: What Product Teams Building AI Integrations Need to Know
TL;DR
The MCP 2026-07-28 release candidate introduces three changes that will affect every team building on the protocol. Sessions are gone from Streamable HTTP transport, making horizontal scaling trivially simple on standard load balancers. MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces into AI host applications. A formal 12-month deprecation policy now governs the spec, giving integration teams a real planning horizon. If your team built on MCP in 2025, audit for session dependency before the release drops. If you are evaluating MCP now, the infrastructure story just got dramatically simpler.
The AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.
What MCP Is and Why This Release Matters
The Model Context Protocol (MCP) is the open standard for connecting AI models to external tools and data sources. Anthropic published the first spec in late 2025, and adoption moved faster than anyone expected: by mid-2026, MCP had become the default integration layer for agentic products across all major model providers. Rather than building a custom API integration for every tool, teams expose capabilities as MCP servers and any MCP-compatible client, such as Claude, Cursor, or a custom agent, can consume them without additional plumbing.
For AI PMs, understanding MCP is less about protocol mechanics and more about the product surface it creates. When your data source, internal tool, or SaaS product becomes an MCP server, it becomes accessible to AI agents across the entire ecosystem without custom per-client integrations. The 2026-07-28 release candidate makes that surface meaningfully larger and the underlying infrastructure dramatically simpler.
What changed
Streamable HTTP transport is now stateless: sessions and the Mcp-Session-Id header are removed. MCP Apps (SEP-1865) adds interactive HTML interfaces. The Tasks extension moves out of core into a governed extension. A 12-month deprecation policy is introduced.
When it lands
The July 28 release candidate is available for public feedback now. The formal release follows community review. Teams should act on the audit before the release date, not after.
Who is affected
Teams that built MCP servers using the 2025-11-25 spec or any prior revision may have session-dependent logic that needs updating. Teams building new MCP integrations after this release get a simpler infrastructure story from day one.
The Stateless Shift: Horizontal Scaling Without Sticky Sessions
The most significant infrastructure change in the 2026 spec is the removal of sessions from Streamable HTTP transport. In the original spec, each MCP client-server interaction was session-aware: the server maintained state between requests using an Mcp-Session-Id header. This worked fine for single-instance deployments but created a real scaling problem. Any load balancer had to be "sticky," pinning each client to the same server instance, which ruled out standard round-robin load balancing and made horizontal scaling complex and expensive.
Before: session-aware
Sessions required sticky load balancing. Each client was pinned to a server instance. Horizontal scaling required either Redis-backed session sharing or sticky routing. High operational complexity at any real scale.
After: stateless HTTP
Standard round-robin load balancers work out of the box. Add server instances freely as traffic grows. No session synchronization layer needed. The same infrastructure model that powers the rest of the web.
What this means for product decisions
MCP servers can now deploy on commodity infrastructure, including AWS ECS, Cloud Run, and Vercel Functions, without custom session management overhead. If infrastructure cost or complexity was blocking your MCP investment, that blocker is gone.
What teams need to audit
Any server that stores per-session state, such as conversation context, user preferences, or accumulated tool results, needs rearchitecting. State that lived in session memory must move to an external store or be passed explicitly per-request.
MCP Apps: When Your MCP Server Can Ship a UI
SEP-1865 introduces MCP Apps: a capability for MCP servers to ship interactive HTML interfaces that host applications render in a sandboxed iframe. This is a significant expansion of what MCP can be. Until now, MCP was purely a data and tool pipe. Servers exposed structured capabilities and hosts rendered whatever UI they chose. MCP Apps lets servers declare UI templates alongside tool definitions, which hosts can prefetch, cache, and security-review before rendering.
What servers can ship
What it does: Interactive HTML interfaces: forms, dashboards, configuration panels, approval flows. The host renders it in a controlled iframe so the server cannot access host application state directly. The interface is scoped and sandboxed by design.
Why it matters: Tools that previously required a full external application can now surface lightweight UI inline. An MCP server for your internal data warehouse could ship a query-builder directly in Claude or Cursor, removing the tab-switch friction that breaks agentic workflows.
Prefetch and security review requirements
What it does: Templates must be declared ahead of time rather than generated dynamically at runtime. This lets hosts prefetch and cache templates and run a security review before any user interaction. Dynamic UI generation at runtime is explicitly not supported.
Why it matters: The prefetch requirement is a deliberate safety choice. It prevents servers from injecting arbitrary code at runtime based on user actions. For enterprise teams with strict security requirements, this is the right trade-off: less flexibility, more trust.
The product opportunity
What it does: Any SaaS tool that already exposes an MCP server now has a path to ship a lightweight UI surface into AI clients. Configuration tools, query builders, approval flows, and data-entry forms are the obvious candidates.
Why it matters: This is early signal that AI clients are becoming application runtimes, not just conversation interfaces. The PM question is: what UI surface would make your MCP server dramatically more useful if it lived inside the AI client instead of requiring a tab switch?
Build AI Products on Solid Technical Foundations
The AI PM Masterclass covers integration architecture, protocol decisions, and how to evaluate technical choices that affect your roadmap for years — taught live by a Salesforce Sr. Director PM.
The 12-Month Deprecation Policy: A Real Planning Horizon at Last
One practical complaint from teams building on MCP in 2025 was the absence of a formal stability commitment. The spec could change, and there was no guaranteed runway between deprecation and removal. The 2026 release candidate addresses this directly with a formal 12-month deprecation policy: any feature flagged as deprecated in one release is guaranteed to remain functional for at least 12 months before removal.
What this enables for product planning
Integration teams can now plan MCP adoption and migrations with a known minimum runway. A 12-month window is long enough to make a board-level investment in MCP and be confident the spec will not shift underneath you before you recoup the cost.
Deprecated vs. removed: what they actually mean
Deprecated means still functional, officially on the way out, and documented as such. Removed means gone. The 12-month clock starts when a feature enters deprecated status, not when your team becomes aware of it. Watch the spec changelog closely.
Tasks extension: what moved out of core
The Tasks extension, which defined structured support for long-running agent tasks with status polling and cancellation, moved from the experimental core spec into a governed extension. Teams that built on experimental Tasks features need to audit against the extension spec.
Implication for vendor and procurement conversations
SaaS vendors building MCP server integrations now have a clearer story for enterprise buyers: your integration has a formal stability guarantee. That changes the procurement conversation from 'this spec might change' to 'here is the deprecation runway we commit to.'
Four Things to Do Before the Release Drops
The release candidate is public now. The final release follows community review. If your team has MCP integrations in production or in active development, there are concrete actions to take immediately.
Audit for session dependency
Search your MCP server code for references to Mcp-Session-Id or per-session state storage. Any server that stores state between requests tied to a session identifier needs rearchitecting. Move that state to an external store or pass it explicitly per-request.
Review Tasks extension usage
If your server or client implements the experimental Tasks feature from the 2025-11-25 spec, compare your implementation against the new governed extension spec. The API surface may have changed in the transition from core to extension.
Evaluate MCP Apps for your product
Walk through your MCP server and ask: is there a UI surface (a form, dashboard, or configuration panel) that would meaningfully improve the user experience if it ran inside the AI client rather than a separate tab? MCP Apps may unlock that without a full application build.
Update your roadmap's infrastructure assumptions
If your AI integration roadmap assumed sticky session infrastructure or custom session management overhead, those assumptions are now wrong. The simplified infrastructure may unlock integrations you had deprioritized on cost or complexity grounds.
The bigger picture
MCP started as an integration protocol. With stateless scaling and MCP Apps, it is becoming an application runtime. The teams that understand this shift early, and build their integration strategy around it, will have a structural advantage as AI clients become the primary interface for enterprise work. The 12-month deprecation policy means you can make that bet with some confidence the ground will not move under you.
Stay Ahead of the AI Infrastructure Shifts That Matter
The AI PM Masterclass covers the technical decisions that affect your product for years: protocol choices, integration architecture, and how to evaluate the options your engineering team brings to you.
Related Articles
Before you go: get the AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.