{"slug": "mcp-grows-up-six-changes-production-teams-need-to-plan-for", "title": "MCP Grows Up: Six Changes Production Teams Need to Plan For", "summary": "On July 28, 2026, the Model Context Protocol published its largest revision since launch, introducing a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable discovery, a formal extensions framework, Tasks, MCP Apps, authorization hardening, and a feature-deprecation policy. The release removes protocol sessions and the initialize/initialized handshake, requiring production teams to treat the upgrade as an architecture migration rather than a simple dependency change. The release candidate had been locked since May 21, giving implementers approximately ten weeks to validate the redesign.", "body_md": "The new Model Context Protocol specification removes protocol sessions, formalizes extensions, introduces durable asynchronous work, hardens authorization and gives implementers a real deprecation policy. Here is where it helps, where it adds complexity and how to migrate safely.\n\nOn July 28, 2026, [the Model Context Protocol published](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#stateless-protocol-stateful-applications) its largest revision since launch.\n\nThe release candidate had been locked since May 21, giving SDK maintainers, client developers, and server operators approximately ten weeks to validate the redesign. The final release delivers a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable discovery and list results, a formal extensions framework, Tasks, MCP Apps, authorization hardening and a predictable feature-deprecation policy.\n\nThe headline is “stateless MCP,” but that description understates the scope of the release. Six major change areas arrive together:\n\nUnder those six themes are additional breaking details: every result now has a resultType; the old HTTP GET stream disappears; subscriptions/listen replaces previous subscription patterns; SSE streams are no longer resumable with Last-Event-ID; list and resource results require cache hints; tool schemas support full JSON Schema 2020-12; and the “resource not found” error moves from -32002 to the standard JSON-RPC -32602.\n\nThis is therefore not an upgrade to approach as “change the dependency version and redeploy.” **It is an architecture migration.**\n\nPrevious MCP revisions established context through the initialize/initialized handshake. For remote HTTP servers, the server could also issue an Mcp-Session-Id, which the client returned on subsequent requests.\n\nThat model created an operational dependency between a client and a particular server session. Production deployments commonly needed sticky load-balancer routing, a shared session store, or both.\n\nIn 2026-07-28, the handshake and protocol session are gone. Every request carries its protocol version, client capabilities, and optional client identity in _meta. Servers must implement server/discover, although clients do not need to call it before every operation. A client can instead send its preferred version and retry if it receives an UnsupportedProtocolVersionError.\n\nFor Streamable HTTP, a modern request includes metadata such as:\n\n```\nMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: search\n```\n\nThe version, method, and name are also represented in the JSON-RPC body. The body remains the source of truth, and servers must reject mismatches between headers and body. This prevents a gateway from authorizing or routing one operation while the server executes another.\n\nThe new specification does not remove application state. It makes that state explicit.\n\nA server that needs continuity across calls should issue a domain handle such as:\n\nThe client or model passes that handle back as a normal tool argument on later calls.\n\n```\ncreate_workspace()→ { \"workspace_id\": \"ws_7f3...\" }add_file(workspace_id=\"ws_7f3...\", ...)→ ...run_analysis(workspace_id=\"ws_7f3...\")→ ...\n```\n\nThis is operationally cleaner than hidden transport state, but it introduces application responsibilities. Handles need ownership checks, tenant isolation, expiration, retention rules, authorization and protection against guessing or replay. Persistent workflows may still require a database or distributed cache. Long-running Tasks require durable storage by definition.\n\n**The infrastructure can be stateless even while the product remains stateful.**\n\nA server whose request context is fully contained in the request can run behind a standard round-robin load balancer. Kubernetes operators can generally use a normal Deployment and Service without session-affinity annotations or a StatefulSet solely for MCP session ownership.\n\nThis is especially valuable for autoscaling. A new pod does not need to restore protocol sessions before receiving traffic. A pod can be replaced during a rolling deployment without stranding clients on a dead session.\n\nThe caveat is important: an MCP server that creates application handles or Tasks still needs an external durable store when those objects must survive process or pod failure.\n\nMcp-Method and Mcp-Name let gateways route, meter, and apply policy without parsing JSON request bodies. A multi-tenant MCP service can define different quotas for tools/list, expensive search tools, deployment tools, or destructive operations.\n\nFor example:\n\n```\ntools/list                  → high request allowancetools/call + search         → standard allowancetools/call + deploy_prod    → lower rate limit and stronger policyresources/read              → data-volume quota\n```\n\nThe gateway should never treat clientInfo as authenticated identity. It is self-reported and intended for display, debugging, and logging not security decisions. Tenant identity must come from a validated token or another trusted authentication mechanism.\n\nserver/discover, tools/list, prompts/list, resources/list, resources/templates/list, and resources/read now return ttlMs and cacheScope.\n\nttlMs is a freshness hint rather than a background polling interval. cacheScope determines whether a result is public or private. A result that varies by user, tenant, scopes, or authorization must not be treated as shared public data. Change notifications can invalidate an otherwise fresh cached result.\n\nCaching can reduce repeated tool-catalog requests and keep model prompt inputs more stable. It also creates a new class of correctness and privacy bugs when scope is chosen incorrectly.\n\nThe specification documents W3C Trace Context propagation using the _meta keys traceparent, tracestate and baggage. That gives a host, MCP client, gateway, MCP server and downstream service a common mechanism for correlating one tool call across the full execution path.\n\nTrace context improves correlation. It is not an authorization mechanism or an integrity guarantee. Sensitive data, tokens, raw prompts and personally identifiable information should not be placed in trace baggage.\n\nExtensions now have identifiers, negotiation rules, delegated maintainers, separate repositories and independent lifecycles. Clients declare supported extensions in their per-request capabilities and servers advertise theirs through server/discover.\n\nAn extension is active only when both parties support it. When the other side does not support an extension, the implementation must either fall back to core behavior or return an appropriate error.\n\nThis is a major improvement for protocol evolution. **Features no longer need to wait for a full core-specification release.**\n\nIt also creates a compatibility matrix.\n\nA server cannot assume that every MCP host supports Tasks, MCP Apps, Enterprise-Managed Authorization or any future extension. Production implementations need explicit fallback behavior.\n\nExamples include:\n\nExtensions reduce coupling to the core specification but increase ecosystem fragmentation risk.\n\nTasks move out of the experimental core protocol and into the official io.modelcontextprotocol/tasks extension.\n\nWhen a client advertises Tasks support, a server may respond to an ordinary operation with a task handle rather than a final result. The client then uses:\n\nA task moves through working, input_required, completed, failed, or cancelled. The server must durably create the task before returning its handle. Cancellation is cooperative: acknowledgement of a cancellation request does not guarantee the underlying operation stops immediately.\n\nThis is ideal for:\n\nThe benefit is not simply “asynchronous execution.” It is recoverability. A client can disconnect, restart, and resume polling with the same task ID.\n\nTasks require more than a background thread.\n\nA production implementation needs:\n\nA task ID should be treated like a resource identifier, not a secret. **Possession of the ID must not be sufficient authorization**.\n\nA stateless server can no longer depend on a persistent bidirectional connection to ask the client a question at an arbitrary time.\n\nMulti Round-Trip Requests, or MRTR, replace that pattern. When the server needs confirmation, elicitation, sampling, or another client-provided input, it returns an InputRequiredResult. The client collects the requested inputs and retries the original operation with inputResponses and, when supplied, requestState.\n\nConsider a destructive tool:\n\n```\ndelete_resources(resource_ids=[...])\n```\n\nInstead of opening a reverse request over an existing stream, the server returns:\n\n```\ninput_required:  \"Confirm deletion of 53 resources\"\n```\n\nThe client obtains confirmation and retries the original call.\n\nThis works across instances because the retry is self-contained. It also means the server must design for retries.\n\nFor sensitive workflows, requestState should be an opaque random handle backed by server-side state, or a tamper-evident value protected with a message authentication code.\n\nMCP Apps let a server associate a tool with an interactive HTML interface. Compatible hosts render that interface in a sandboxed iframe. The app communicates with the host using JSON-RPC over postMessage, while the host controls the capabilities and tools the app can access.\n\nThis enables forms, interactive dashboards, confirmation dialogs, media viewers, deployment configurators, issue triage interfaces, and other experiences that are awkward to express through text turns.\n\nFor a startup, that can change MVP economics. A team can deliver an interactive conversational workflow without immediately building a completely separate application shell and integration layer.\n\nHowever, MCP Apps do not eliminate frontend engineering. Teams still need:\n\nHost support varies, because MCP Apps is an optional extension. A server should return meaningful structured content even when the interactive view is unavailable.\n\nThe HTTP authorization specification treats a protected MCP server as an **OAuth resource server** and the MCP client as an **OAuth client**.\n\nThe new specification aligns with selected parts of OAuth 2.1 and related standards. It requires Protected Resource Metadata for server discovery, supports OAuth and OpenID Connect authorization-server metadata, requires PKCE, requires Resource Indicators in authorization and token requests and defines stronger issuer-validation behavior.\n\nImportant requirements include:\n\nResource Indicators provide **token audience restriction**. They should not be described as cryptographic token binding.\n\nCore MCP authorization covers the standard user-delegated OAuth flow.\n\nCentralized corporate access policy is provided by the optional **Enterprise-Managed Authorization extension**. That extension lets an organization’s IdP control access to MCP servers, supporting centralized onboarding, offboarding, conditional access, and policy enforcement. It must be supported by the client, server authorization system, and enterprise identity environment.\n\nFor a security review, the practical architecture is therefore:\n\n```\nCore authorization  OAuth flow  issuer validation  resource/audience validation  scopes and step-up  Protected Resource MetadataOptional enterprise extension  corporate IdP policy  SSO  centralized approval and revocation  identity-assertion exchange\n```\n\nThe specification makes this architecture clearer. It does not make OAuth operationally simple.\n\nClient metadata fetching also introduces SSRF and trust-policy concerns. Tokens and refresh credentials require secure storage. Multi-issuer deployments require separate registration and token state. Authorization metadata, redirect URIs, scopes, and canonical resource identifiers all need careful consistency.\n\nMCP now has three feature states: Active, Deprecated, and Removed.\n\nA core feature generally remains Deprecated for at least twelve months before it becomes eligible for removal. Deprecation requires a documented migration path and an entry in the central deprecated-feature registry. Removal may happen later than the earliest date. An expedited path exists for active security risks, but even that normally requires at least 90 days.\n\nThe older HTTP+SSE transport follows a special transition rule and may become removable sooner than the newly deprecated features. Teams still operating it should prioritize migration to Streamable HTTP.\n\nThe twelve-month rule applies to protocol features. SDK APIs have their own support policies and may follow different timelines.\n\nImagine a company exposing internal knowledge, Jira, Confluence, service catalogs, and operational runbooks through MCP.\n\nUnder the old model, a remote deployment might have used session affinity so one employee’s sequence of requests continued to reach the same server instance. Under 2026-07-28, the MCP layer can run as stateless containers behind an ordinary Kubernetes Service and load balancer.\n\nThe practical design becomes:\n\n```\nMCP host  ↓API gateway / authorization  ↓Stateless MCP Deployment  ├─ Knowledge connector  ├─ Jira connector  ├─ Confluence connector  └─ Service catalog connector  ↓OpenTelemetry backend\n```\n\nThe organization can use core OAuth requirements for normal authorization and the Enterprise-Managed Authorization extension when centralized IdP policy is required. *The main limitation is client support for that extension.*\n\nA developer tooling company may expose MCP as a paid API across hundreds or thousands of tenants.\n\nThe stateless request model allows ordinary multi-zone routing. The gateway can meter traffic by Mcp-Method and Mcp-Name, while tenant identity comes from validated authorization not from client-provided names or headers.\n\nThe production implementation should:\n\nThe protocol removes session-aware routing. It does not remove tenant-isolation work.\n\nA coding server can turn run_tests, build_project, generate_patch, or deploy_preview into Tasks.\n\nThe server returns a task ID immediately, queues the work, and lets the agent continue reading code or reviewing another issue. The client polls at the interval suggested by the server. When a destructive action requires approval, the task enters input_required and the client responds with tasks/update.\n\nThe practical benefit is resilience across editor restarts and network interruptions.\n\nThe limitation is that the coding server now needs a real job system: durable queueing, worker leases, result storage, cancellation, workspace isolation and retention.\n\nResource Indicators and audience validation reduce the risk of a token intended for one MCP server being replayed against another. Issuer validation reduces OAuth mix-up risk. W3C Trace Context can correlate a request across the MCP path and its downstream services.\n\n**These features give security and compliance teams a clearer technical control model**, but they are not a complete compliance solution.\n\nTeams still need:\n\nDistributed tracing improves diagnosis and correlation. It should not be the sole audit ledger.\n\nA small team building an infrastructure assistant could expose:\n\nthrough MCP Apps.\n\nThe conversational host supplies context, the server supplies tools and UI resources and the app calls those tools through the host-controlled bridge.\n\nThis may remove the immediate need for a separate dashboard product. It does not remove the need for API design, authorization, UI testing, accessibility, CSP controls, or compatibility fallbacks.\n\nConnection state becomes explicit domain state. This is an architectural improvement, but teams must now design handles, storage, expiry, ownership, and idempotency deliberately.\n\nDuring the release-candidate window, SDK maintainers advised teams to distinguish upgrading an SDK major version from enabling the new wire protocol. That remains the correct migration model.\n\nTypeScript v2, for example:\n\nPython v2 is also a major rework, including the change from FastMCP to MCPServer. TypeScript v1 continues receiving fixes and security updates for at least six months after v2’s release, while Python v1 continues receiving critical fixes and security patches.\n\nThe safest sequence is:\n\nA tool cannot assume that Tasks or MCP Apps exist everywhere. Product teams need compatibility matrices and fallback UX.\n\nMRTR, protocol-version retries, broken HTTP response streams, authorization step-up, Tasks polling, and subscription reconnection all produce retry paths.\n\nAny operation that performs a side effect needs an idempotency design.\n\nOAuth 2.1 and Client ID Metadata Documents are referenced as drafts in the specification. Implementers need to watch both MCP changes and evolution in the underlying standards.\n\nIncorrectly marking an authorization-dependent response as public can expose one user’s or tenant’s catalog to another. Conservative defaults are appropriate: use private scope unless the result is genuinely identical for every caller.\n\nMCP 2026-07-28 moves the protocol closer to the operational model of the **modern web**: self-contained requests, explicit versioning, ordinary HTTP routing, meaningful cache semantics, distributed tracing, standardized authorization and optional capabilities that can evolve independently.\n\nIts greatest benefit is not that it removes state. It removes **hidden protocol state**.\n\nThat makes horizontal scaling, multi-zone routing, failure recovery, gateway policy, and observability considerably easier. At the same time, it exposes work that session state previously concealed: application handles, idempotency, durable Tasks, extension fallbacks, authorization metadata, cache privacy, and retry correctness.\n\nFor an existing production server, the right migration is dual-era and incremental. Upgrade the SDK separately from the wire protocol, remove connection assumptions, move durable work into explicit stores, validate authorization and retries, and retire legacy behavior only after measuring real client adoption.\n\nFor a new server, the decision is simpler: build around stateless request handlers, explicit state, Streamable HTTP, modern authorization, OpenTelemetry, deterministic caching, and extension negotiation from day one.\n\nThe specification has become easier to operate but only for teams willing to make application state, security boundaries and failure behavior explicit.\n\n*Disclaimer**: The Views expressed here are strictly my own.*\n\n[MCP Grows Up: Six Changes Production Teams Need to Plan For](https://pub.towardsai.net/mcp-grows-up-six-changes-production-teams-need-to-plan-for-cffb8a9e50c2) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/mcp-grows-up-six-changes-production-teams-need-to-plan-for", "canonical_source": "https://pub.towardsai.net/mcp-grows-up-six-changes-production-teams-need-to-plan-for-cffb8a9e50c2?source=rss----98111c9905da---4", "published_at": "2026-08-19 00:01:03+00:00", "updated_at": "2026-08-19 00:41:06.225373+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools", "ai-policy"], "entities": ["Model Context Protocol"], "alternates": {"html": "https://wpnews.pro/news/mcp-grows-up-six-changes-production-teams-need-to-plan-for", "markdown": "https://wpnews.pro/news/mcp-grows-up-six-changes-production-teams-need-to-plan-for.md", "text": "https://wpnews.pro/news/mcp-grows-up-six-changes-production-teams-need-to-plan-for.txt", "jsonld": "https://wpnews.pro/news/mcp-grows-up-six-changes-production-teams-need-to-plan-for.jsonld"}}