The MCP 2026 specification is the biggest change to the Model Context Protocol since launch — and the production migration window is this month. If you’re running MCP servers against the 2025-11-25 spec, August is when the work of updating them begins in earnest.
The 2026-07-28 Model Context Protocol specification brings a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs. Half a billion downloads per month across Tier 1 SDKs, with TypeScript and Python each crossing 1 billion total downloads. MCP is now foundational infrastructure — and the 2026-07-28 spec tightens the contract between clients and servers so those connections are easier to operate, observe, and evolve.
This post breaks down what changed, what broke, and the exact migration steps for builders running the MCP Server Python pattern from this series against the previous spec.
The MCP 2026 Specification’s Biggest Change: Stateless Core
The headline change is that MCP no longer manages sessions at the protocol layer. Six Specification Enhancement Proposals work together to remove the session model that the 2025-11-25 spec was built on.
In the old spec, MCP servers maintained sessions: a client sent an initialize request, received a session ID via Mcp-Session-Id, and subsequent requests were pinned to that server instance. This created an immediate infrastructure problem at scale: load balancers required sticky routing or shared session stores, making horizontal scaling unnecessarily complex.
The 2026-07-28 spec removes this entirely. Every Streamable HTTP POST request must now include Mcp-Method (e.g. tools/call) and Mcp-Name (tool or resource name) headers. Load balancers, API Gateways, and rate-limiters route without parsing the JSON-RPC body. Standard round-robin load balancing works out of the box. Long-lived SSE connections that behaved like “ghost websockets” are gone.
The practical effect for builders: for teams running MCP servers behind enterprise identity providers — Okta, Azure AD, Google Workspace — the path from “unauthenticated MCP server” to “properly secured MCP server” is now defined at the spec level rather than left as an exercise. Microsoft Foundry’s endorsement in the official release captures the production value: “With stateless operations, Tasks for long-running work, and enterprise-managed identity, the next generation of MCP makes it easier than ever to build secure, scalable, production-ready agent systems.”
What the MCP 2026 Specification Adds: Tasks, MCP Apps, Extensions
Tasks Extension: Long-Running Async Work
The Tasks extension is the MCP 2026 specification’s answer to the blocking problem: tool calls that take more than a few seconds were forced to either block the client or rely on custom polling patterns. Tasks introduces a first-class primitive for long-running, async operations with structured progress tracking.
A task-enabled MCP tool returns immediately with a task ID. The client polls for progress updates using the task ID, and the server pushes structured progress messages as the operation proceeds. For the agent orchestration patterns in the Sub-Agent Orchestration post — where a sub-agent might run a complex analysis that takes minutes — Tasks replaces the custom async workarounds most builders have cobbled together with a spec-standardized pattern.
MCP Apps: Server-Rendered UIs in Clients
MCP Apps let servers render interactive HTML UIs directly in the MCP client. The rendered UI communicates back with the server through the standard MCP protocol. For the Micro-SaaS AI Agent retainer model, this means an MCP server can expose a configuration dashboard, a results viewer, or an approval workflow UI that lives inside Claude Cowork or any MCP-native client — without requiring a separate web app.
Extensions Framework: Stable Independent Evolution
Extensions get reverse-DNS identifiers, their own repositories, delegated maintainers, and versions that move independently from the main spec. Clients and servers negotiate extension support through an extensions map in their capabilities. This means Tasks and MCP Apps can ship updates without waiting for a full spec revision — the same model that makes browser APIs stable while still evolving.
What the MCP 2026 Specification Deprecated: The Breaking Changes
Three features from the 2025-11-25 spec are deprecated in 2026-07-28. They remain in the spec during the deprecation window (minimum 12 months), but new implementations should not use them:
- Roots: deprecated in favour of passing filesystem context through tool parameters directly. If your MCP server exposes roots for file system navigation, migrate to explicit path parameters in tool schemas.
- Sampling: deprecated in favour of calling the model provider’s API directly. The indirect sampling pattern was always awkward — the deprecation formalises what most production builders were doing anyway.
- Logging: deprecated in favour of using your existing observability stack (OpenTelemetry, Datadog, CloudWatch) rather than routing logs through the MCP protocol layer. For the AI Agent Gateway audit trail pattern, this means MCP is no longer the log transport — your gateway’s existing logging infrastructure handles this directly.
The Migration Checklist for August
# MCP 2026-07-28 Migration Checklist
# Run against every MCP server you operate this month
# Step 1: Update your SDK to the 2026-07-28 Tier 1 release
pip install --upgrade mcp # Python SDK
npm install @modelcontextprotocol/sdk@latest # TypeScript SDK
# Step 2: Find and remove session dependencies
# Search your codebase for these patterns — they break under stateless routing:
# - Mcp-Session-Id header storage or forwarding
# - initialize handshake result caching
# - Per-session state stored in server memory
# Step 3: Add required headers to all Streamable HTTP POST requests
# OLD (2025-11-25): POST /mcp with JSON-RPC body only
# NEW (2026-07-28): POST /mcp with headers + JSON-RPC body
# Python server example — FastAPI
from fastapi import FastAPI, Request, HTTPException
app = FastAPI()
VALID_MCP_METHODS = {"tools/call", "tools/list", "resources/read"}
@app.post("/mcp")
async def mcp_endpoint(request: Request):
mcp_method = request.headers.get("Mcp-Method")
mcp_name = request.headers.get("Mcp-Name")
if not mcp_method:
raise HTTPException(
status_code=400,
detail="Mcp-Method header required in 2026-07-28 spec"
)
if mcp_method not in VALID_MCP_METHODS:
raise HTTPException(
status_code=400,
detail=f"Unknown Mcp-Method: {mcp_method}"
)
# Route by Mcp-Method header — no session state required
body = await request.json()
return await dispatch(mcp_method, mcp_name, body)
async def dispatch(method: str, name: str | None, body: dict) -> dict:
"""
Stateless dispatch — each request is self-contained.
No Mcp-Session-Id, no initialize handshake state.
"""
if method == "tools/call":
return await handle_tool_call(name, body.get("params", {}))
elif method == "tools/list":
return {"tools": get_tool_list()} # Cacheable list result
elif method == "resources/read":
return await handle_resource_read(name, body.get("params", {}))
return {"error": {"code": -32601, "message": "Method not found"}}
# Step 4: Migrate deprecated features
# Roots → explicit path parameters in tool schemas
# Sampling → call model provider API directly
# Logging → route to your existing observability stack (OpenTelemetry etc.)
# Step 5: Add Tasks extension support for long-running tools
# Replace blocking tool calls > 5 seconds with Task-returning tools
# Client polls /mcp with Mcp-Method: tasks/get for progressThe Open Governance Story: MCP Under the Linux Foundation
One structural change in the MCP 2026 specification release is worth noting separately: MCP is now hosted by the Agentic AI Foundation under the Linux Foundation. This open governance model ensures neutral stewardship while retaining a focused specification enhancement process led by active maintainers.
For builders making infrastructure decisions, this matters. A protocol governed by a single company can be deprecated, forked, or strategically redirected to serve that company’s competitive interests. A protocol under Linux Foundation governance has an independent Standards Body behind it — the same structure that has kept HTTP, DNS, and TCP/IP stable infrastructure for decades. The MCP 2026 specification formalises the deprecation policy (12-month minimum window, written rules) and the conformance suite that validates official SDKs. This is infrastructure-grade protocol governance, not a startup’s open-source project.
For the complete MCP 2026-07-28 specification and migration guide, see the official MCP specification blog post.
The Builder’s Takeaway
The MCP 2026 specification is the upgrade that makes MCP a first-class HTTP workload — no sessions, no sticky routing, no protocol-layer logging, no sampling indirection. For builders running MCP servers in production against the 2025-11-25 spec, the migration work is straightforward but not optional: deprecated features will be removed in a future spec revision, and session-dependent servers will break under stateless load balancers. August is the migration window. The checklist above covers the four concrete steps: SDK update, session dependency removal, header addition, and deprecated feature migration. Start Monday. The migration is mechanical, the benefit — horizontal scale on standard HTTP infrastructure — is structural.
Continue in This Series
- MCP Server Python — the 2025-11-25 spec implementation this migration post updates: stateless explicit-handle pattern now aligned with the new spec
- AI Agent Framework 2026 — LangGraph 1.0 treats MCP tools as first-class nodes: the framework integration built on the new spec
- AI Agent Gateway — authorization hardening in the 2026 spec aligns with OAuth and OIDC: the gateway’s auth layer benefits directly
- Sub-Agent Orchestration — Tasks extension replaces custom async workarounds in long-running sub-agent pipelines
- How to Deploy AI Agents — Layer 2 (Orchestration) update: MCP 2026-07-28 is the new production baseline for the framework selection checklist
This post is part of The Agentic Protocol’s Work series — the connective infrastructure layer beneath every autonomous pipeline. See also: MCP Server Python.