MCP 2026-07-28: Stateless Transport, MCP Apps, and What Enterprises Must Migrate

On July 28, 2026, the Model Context Protocol publishes its largest revision since launch. The MCP 2026 stateless enterprise agents specification is not a marginal update — it is a foundation change for every MCP deployment in production.

In April 2026, MCP stabilization and the arrival of the A2A protocol reshaped AI agent interoperability (we come back to A2A below). Three months later, release candidate 2026-07-28 — locked on May 21, 2026 per the official MCP blog — goes further. It delivers the 2026 roadmap announced on March 9, 2026: a stateless core that scales on ordinary HTTP infrastructure, first-class extensions (MCP Apps, Tasks), OAuth/OIDC hardening, and a formal deprecation policy.

If your company already connects Claude, Cursor, n8n, or a custom agent to remote MCP servers, this article answers one precise question: what breaks, what improves, and how do you migrate without interrupting workflows? We rely exclusively on official documentation (MCP blog, draft changelog, AAIF announcements) and our production agent deployment experience at BOVO Digital.

---

What changes compared with the stable April 2026 version

The April version established the conceptual frame: MCP for tools, A2A for agent communication, growing ecosystem, hundreds of pre-built servers. Spec 2026-07-28 enters operational territory.

The April frame explained why to adopt MCP; the July spec forces you to know how to migrate when MCP becomes critical infrastructure behind a load balancer, API Gateway, and enterprise IdP.

From the locked RC (May 2026) to the final spec on July 28, 2026, then production migration from August

---

The foundational change: MCP becomes stateless at the protocol layer

The AAIF headline is clear: MCP becomes stateless at the protocol layer. Six Specification Enhancement Proposals (SEPs) converge on this goal, completing the plan laid out in "The Future of MCP Transports" published in December 2025.

Before / after: a tool call over Streamable HTTP

Under 2025-11-25, invoking a tool required establishing a session first:

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

The server responded with an Mcp-Session-Id that every subsequent request had to carry, pinning the client to the instance that issued the session:

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

Under 2026-07-28, the same call becomes a single request any instance can handle:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Immediate operational consequence, per the MCP blog: a remote server that previously needed sticky sessions, a shared session store, and deep JSON-RPC body inspection at the gateway can now run behind a round-robin load balancer, route on the Mcp-Method header, and let clients cache tools/list responses as long as the server's ttlMs permits.

SEP-2575: end of the initialize handshake

The initialize / notifications/initialized pair is gone. Protocol version, client identity, and negotiated capabilities — previously exchanged once at connection time — now travel in _meta on every request, under keys like io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo, and io.modelcontextprotocol/clientCapabilities.

A version mismatch returns UnsupportedProtocolVersionError. For upfront discovery, a new server/discover RPC — which servers must implement — advertises supported versions, capabilities, and server identity. Clients may call it before any interaction, or use it as a STDIO compatibility probe.

SEP-2567: Mcp-Session-Id removal

The Mcp-Session-Id header and protocol-level session are removed. List endpoints (tools/list, resources/list, prompts/list) no longer vary per connection. Two major enterprise consequences:

1. Simplified horizontal scaling: no sticky routing imposed by the protocol.
2. CDN-friendly cache: tool lists become cacheable resources with explicit metadata.

Five pillars: stateless core, operability, extensions, OAuth/OIDC auth, governance

---

Stateless protocol, stateful applications: the explicit handle pattern

Removing the protocol session does not mean your CRM connector, browser automation, or document pipeline must become amnesiac. MCP maintainers state explicitly: servers that carry state across calls emit an explicit handle — basket_id, browser_id, workflow_run_id — returned by a tool, which the model passes back as an ordinary argument.

In practice, this pattern is often more powerful than state hidden in transport metadata:

• The model sees the identifier and can reason about it.
• It can compose handles across tools ("use the browser_id from step 1 for step 3").
• It can transfer context between steps in an agent chain.

At BOVO Digital, we already apply this pattern on n8n + MCP integrations: an "init_session" node returns an identifier that subsequent nodes consume. Spec 2026-07-28 finally aligns the protocol with what HTTP has done for twenty years — tokens, cookies, opaque IDs — rather than simulating continuity via a proprietary transport layer.

---

Server→client requests without persistent connections

A stateless protocol must still let the server request input mid-call (delete confirmation, option selection). Two SEPs rebuild this flow:

SEP-2260: server-initiated requests may only be issued while actively processing a client request. No more "out of nowhere" elicitation: every user prompt traces back to an action they — or their agent — started.

SEP-2322 (Multi Round-Trip Requests): instead of holding an SSE stream open, the server returns an InputRequiredResult:

{
  "resultType": "inputRequired",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

The client collects answers and re-issues the original call with inputResponses and the echoed requestState. Any server instance can pick up the retry: all context is in the payload.

For SRE teams, this is a win: no more long-lived SSE connections to monitor like ghost websockets. For MCP server developers, elicitation handling needs refactoring before August 2026.

---

Operability layer: headers, cache, distributed tracing

Three "unglamorous but critical" changes make MCP traffic indistinguishable, from a routing and observability standpoint, from a classic HTTP API.

SEP-2243: mandatory Mcp-Method and Mcp-Name headers

Every Streamable HTTP POST request must include Mcp-Method (e.g. tools/call) and Mcp-Name (tool or resource name). Load balancers, API Gateways, and rate-limiters route without parsing the JSON-RPC body. Servers reject requests where headers and body disagree.

At the April 2026 AAIF MCP Dev Summit, several vendors — Kong, Docker, Solo.io, internal platforms like Uber's — were reverse-engineering tool names from the body. That hack disappears on July 28.

The same SEP introduces support for custom headers from tool parameters via x-mcp-header, useful for propagating a tenant ID or correlation ID without changing the business schema.

SEP-2549: ttlMs and cacheScope

Results from tools/list, resources/list, and resources/read carry ttlMs and cacheScope, modeled on HTTP Cache-Control. Clients know how long a tool list stays fresh and whether cache can be shared across users. A long-lived SSE stream is no longer the only way to detect a list change.

SEP-414: W3C Trace Context

Propagation of traceparent, tracestate, and baggage in _meta is documented with fixed key names. An OpenTelemetry trace starting in the host application traverses the client SDK, MCP server, and downstream calls in a single span tree.

AI agent → round-robin load balancer → stateless MCP instances → business tools, with OAuth/OIDC upstream

---

First-class extensions: MCP Apps and Tasks

SEP-2133 makes extensions first-class citizens. Identified by reverse-DNS IDs, negotiated via an extensions map on client/server capabilities, hosted in ext-* repositories with delegated maintainers, they version independently of the core spec. A formal Extensions Track exists in the SEP process.

MCP Apps (SEP-1865): sandboxed HTML interfaces

Servers can declare interactive HTML interfaces that the host renders in a sandboxed iframe. Tools declare their UI templates upfront to enable prefetch, cache, and security review before execution. The UI communicates via the same JSON-RPC as tool calls — every UI action goes through the same audit and consent path.

Concrete use cases for an SMB:

• Order validation form before executing a "process_refund" tool.
• Visual file selector before a "bulk_export".
• Lightweight task tracking dashboard (coupled with the Tasks extension).

This is not equivalent to a full Next.js application. For a broader agent-native web stack — Next.js MCP server, Prisma, data contracts — our AI-driven web development analysis details where MCP fits in front/back architecture.

Tasks: graduation to extension with new lifecycle

Tasks was an experimental core feature in 2025-11-25. Production use surfaced enough friction to justify a redesign as an extension.

New model:

• The server can answer tools/call with a task handle.
• The client drives via tasks/get, tasks/update, tasks/cancel.
• Task creation is server-directed: the client advertises the extension, the server decides when an invocation becomes a task.
• tasks/list is removed: without sessions, listing tasks across clients has no well-defined scope.

Explicit breaking change: anyone who shipped against the experimental 2025-11-25 Tasks API must migrate to the new extension lifecycle. Audit your internal servers before July 28.

---

OAuth/OIDC hardening: six SEPs for the enterprise

The MCP deployment pattern — one client, many protected servers — amplifies certain classic OAuth attacks. Six SEPs align the spec with OAuth 2.0 / OpenID Connect production practices.

Priority action August 2026: implement SEP-2468 in every custom MCP client. Mix-up attacks against OAuth-protected APIs have been documented since 2016; MCP inherits the same threat model.

For enterprise n8n + MCP deployments, these changes directly impact OAuth2 credential configuration for n8n and self-hosted MCP servers. Our n8n automation agency systematically includes this IdP review during protocol migrations.

---

Deprecations: Roots, Sampling, Logging — no immediate removal

SEP-2577 and SEP-2596 introduce an Active → Deprecated → Removed lifecycle with a minimum twelve months between deprecation and possible removal.

These are annotation-only deprecations: methods, types, and capability flags keep working in this release and in every version published within the following twelve months. Your code calling roots/list on July 29, 2026 will still get a valid response.

Recommended strategy:

1. Inventory Roots/Sampling/Logging calls in your servers and clients.
2. Plan replacement over Q4 2026 – Q2 2027, not as a July emergency.
3. Do not build new features on these APIs — prefer tool parameters and OpenTelemetry.

HTTP+SSE transport (deprecated since 2025-03-26) moves to formal Deprecated status (SEP-2596). Migrate to Streamable HTTP if not already done.

---

JSON Schema 2020-12 and error code change

SEP-2106 elevates tool inputSchema and outputSchema to full JSON Schema draft 2020-12:

• Input schemas: root type: "object" preserved, but composition (oneOf, anyOf, allOf), conditionals, and $ref/$defs allowed.
• Output schemas: unrestricted root type.
• structuredContent can be any JSON value, not just an object.
• Prohibition on auto-dereferencing external $ref; depth and validation time limits imposed (DoS guards).

A subtler but tricky change: SEP-2164 replaces MCP custom code -32002 (missing resource) with standard JSON-RPC -32602 Invalid Params. If your client matches the literal -32002, update before migration.

For teams exposing MCP tools from polymorphic business APIs — invoices, tickets, CRM entities — JSON Schema 2020-12 is a clear expressiveness improvement. Budget schema validation time in your CI.

---

Governance: how MCP will evolve without breaking the core

Three governance SEPs accompany the stateless rework:

• Lifecycle policy (SEP-2577 + SEP-2596): minimum twelve-month window, written rules.
• Extensions framework: new capabilities as opt-in, stabilization outside core spec.
• SEP-2484: a Standards Track SEP cannot reach Final without a corresponding scenario in the conformance suite — the same suite that scores official SDKs via the tier system.

Maintainers are explicit: the stateless rework is the kind of foundational change that required a clean break. With deprecation windows and extensions as standard tools, implementations targeting 2026-07-28 should adopt future revisions without rewriting transport and lifecycle code.

The 2026 spec excels at HTTP scalability, OAuth security, and built-in UI; 2025-11-25 remains more compatible with existing legacy code

---

MCP and A2A: two complementary layers

MCP answers the question "how does an agent reach its tools?". The Agent2Agent (A2A) protocol, open-sourced by Google, answers a different one: "how do several specialized agents work together?". It lets agents running on different platforms, languages and vendors discover each other, communicate and delegate tasks.

Three notions are enough to understand A2A:

• The Agent Card: a JSON file each agent exposes, usually at /.well-known/agent.json. It describes its name, capabilities, the tasks it accepts, its input and output formats and its security constraints. It is the business card that tells an orchestrator what it can delegate.
• The Task: the delegated unit of work, with an identifier, a message describing the request and optional artifacts (files, data). The specialized agent executes it and returns its results, synchronously or asynchronously (streaming or webhook).
• Multi-turn: two agents can exchange several messages to clarify a request or iterate on a result, which a plain function call cannot do.

So there is no choice to make between the two. In a multi-agent architecture, the orchestrator delegates through A2A, and each specialized agent uses MCP to reach its databases, APIs and files. Example: a competitive intelligence system whose orchestrator hands data collection to an analyst agent (querying sources through MCP), writing to a writer agent (reading and writing in Notion through MCP) and distribution to a communication agent (posting to Slack through MCP).

The two-layer architecture: A2A handles communication between agents, MCP handles access to external tools and resources

Neither MCP nor A2A replaces REST APIs: they stack on top of them. An MCP server can wrap an existing REST API, and A2A uses HTTP as its transport. Adoption can therefore be gradual. The stateless rework of July does not change this split of roles: it simply makes the MCP layer easier to run behind ordinary HTTP infrastructure.

---

Enterprise migration plan: checklist before July 28

Here is the plan we apply at BOVO Digital for clients with MCP in production.

Phase 1 — Audit (week 1)

• List all remote MCP servers and their announced protocol version.
• Identify dependencies on Mcp-Session-Id, sticky sessions, Redis session store.
• Spot experimental Tasks, Roots, Sampling, HTTP+SSE usage.
• Map MCP clients (Cursor, Claude Desktop, n8n agents, custom SDK).

Phase 2 — SDK compatibility (weeks 2–6)

• Check roadmap of SDKs in use (TypeScript, Python) for 2026-07-28 support.
• Test server/discover on each internal server.
• Validate Mcp-Method / Mcp-Name headers behind your API Gateway.

Phase 3 — Server refactoring (weeks 4–8)

• Replace protocol session state with explicit handles in affected tools.
• Migrate SSE elicitation to Multi Round-Trip Requests.
• Add ttlMs / cacheScope to list endpoints.
• Instrument W3C Trace Context → OpenTelemetry.

Phase 4 — Auth and security (weeks 6–10)

• Implement iss validation (SEP-2468) on the client side.
• Fix DCR application_type for CLI/desktop clients.
• Test re-registration after IdP issuer change.

Phase 5 — Production validation (weeks 10–12)

• Round-robin load test without sticky sessions.
• Chaos test: kill instance mid-request, verify recovery via requestState.
• Documented rollback plan to 2025-11-25 if host client incompatible.

Evaluate sticky sessions and experimental Tasks usage to decide whether to migrate in August 2026 or stay on 2025-11-25 temporarily

---

MCP 2026-07-28 and your n8n automation stack

n8n was among the first orchestrators to embrace MCP for connecting agents and business tools. The stateless spec changes three things for n8n workflows:

1. Reliability of remote MCP connections. Without a protocol session, a pod restart no longer invalidates all active sessions. Long-running workflows that invoked MCP tools every ten minutes lose an entire class of "session expired" failures.

2. Tool definition cache. With ttlMs, the MCP Agent node can cache tools/list between executions, reducing latency and load on internal servers.

3. Hardened OAuth. n8n OAuth2 credentials connected to MCP servers need review: iss validation, refresh token semantics, issuer binding. It is tedious, but cheaper than an IdP security incident.

If you deploy MCP agents without a dedicated platform team, outsourcing migration to an n8n automation agency experienced with MCP avoids dangerous shortcuts — temporarily disabling auth, ignoring mandatory headers, or shipping unvalidated state handles.

---

What enterprises gain — and what they pay

Measurable gains

• Horizontal scaling without sticky sessions or mandatory shared store at the protocol layer.
• Observability aligned with OpenTelemetry and standard HTTP headers.
• OAuth security aligned with RFC 9207 and enterprise OIDC practices.
• Extensibility via MCP Apps and Tasks without bloating the core spec.
• Predictability via a minimum twelve-month deprecation policy.

Migration costs

• Refactoring MCP servers that stored state in protocol sessions.
• Experimental Tasks → Tasks extension migration.
• Updating clients matching -32002 or ignoring routing headers.
• Load and chaos engineering on the new architecture.
• Team training on explicit handles and Multi Round-Trip Requests.

ROI calculation depends on MCP maturity. An SMB with two internal MCP servers in local stdio has low impact. A group with fifteen HTTP servers behind Kong, ten production agents, and critical Tasks workflows should budget six to twelve weeks of platform engineering.

---

BOVO Digital positioning: from April to the July migration

In April, we recommended adopting MCP as the tool access standard, complementing A2A for inter-agent orchestration. In July, the recommendation evolves:

1. If you don't have MCP yet: start directly on 2026-07-28 if your SDK supports it; otherwise 2025-11-25 in local stdio with a Q3 2026 migration plan.
2. If MCP is already in production over HTTP: plan the stateless migration before end Q3 2026 — scaling gains are immediate once migrated.
3. If you build custom agents: integrate MCP Apps and Tasks extension into your product roadmap, not as an afterthought.

Our AI agent creation offering now includes MCP 2026-07-28 compatibility audit from the scoping phase: protocol version, state pattern, OAuth review, cache strategy. We apply the same standards to our internal agents before offering them to clients.

---

Official timeline and validation window

Key points from the MCP blog:

• Release candidate locked: May 21, 2026.
• Final spec: July 28, 2026.
• Validation window: ten weeks for SDK maintainers and client implementers against real workloads.
• Tier 1 SDKs: support expected within this window.
• Report a problem: issues on the specification repository; implementation questions via Discord Working Groups.

This release contains breaking changes — not the future norm, but a justified foundational break. Governance tools (deprecation, extensions, conformance suite) exist so future revisions can be incremental.

---

Conclusion: MCP enters the production infrastructure age

Specification MCP 2026-07-28 answers a promise David Soria Parra (MCP co-creator) made in April 2026: make the protocol ready to productionize agentic systems. Stateless transport, MCP Apps and Tasks extensions, hardened OAuth, written deprecation policy — this is no longer a lab standard, it is an infrastructure layer comparable to what REST was for web APIs.

Three concrete actions this week:

1. Audit your MCP servers for sessions, experimental Tasks, and HTTP+SSE transport.
2. Test server/discover and routing headers on a staging environment.
3. Plan OAuth migration (SEP-2468 first) with your security team.

If your web stack is moving toward agent-native architecture, cross-read with our Next.js, Prisma, and MCP in 2026 guide.

Need support? Our n8n automation agency deploys MCP agents in production with OAuth review, load testing, and migration documentation. For a custom agent with 2026-07-28 compatibility from the POC, see our AI agent creation offering. We start with an audit of your existing MCP stack — not by selling technology you don't use yet.