MCP Protocol 2026-07-28 Major Revision: From Tool-Calling Protocol to Infrastructure

On July 28, 2026, the Model Context Protocol published its largest specification revision since inception. Four changes (statelessness, Multi-Round-Trip Requests, asynchronous task extensions, and a formal extension system) collectively push MCP from a developer-facing tool-calling protocol toward enterprise-grade production infrastructure. This article breaks down the revision across three dimensions: specification, key changes, and production readiness.

---

I. The New Specification at a Glance

1.1 What MCP Is

The core problem MCP (Model Context Protocol) solves: how do AI models invoke external tools and data in a standardized way?

Before MCP, every AI application implemented its own tool-calling mechanism. OpenAI had Function Calling, LangChain had its Tool abstraction layer, and the formats were incompatible. A tool that wanted to be called by three different AI applications needed three sets of adapter code.

MCP defines a standard protocol layer: any tool that implements the MCP Server side can be directly invoked by any MCP-compatible AI application. MCP is to AI tool calling roughly what USB is to hardware interfaces — one standard plug, works with everything.

Anthropic open-sourced the protocol in November 2024. Since then, the OpenAI Agents SDK, Google Gemini API, Microsoft Copilot Studio, and GitHub Copilot have added native support. The protocol has been donated to the Linux Foundation, neutralizing its governance. Download figures cited from CSDN's July 2026 technical analysis refer to cumulative downloads across the official SDKs (TypeScript, Python, Java, C#, Kotlin), approximately 97 million; per-platform breakdowns await further verification.

1.2 Architecture: Client-Host-Server Three Tiers

MCP adopts a three-tier architecture:

• Host: The application running the LLM, such as Claude Desktop or Cursor IDE. The Host creates and manages multiple Client instances, controls connection permissions and lifecycles, enforces security policies, coordinates AI integration, and routes requests to the appropriate Client/Server based on the LLM's tool-calling intent.
• Client: A connector inside the Host. Each Client communicates one-to-one with a Server, carrying protocol version and capability declarations in requests, and routing messages bidirectionally.
• Server: Exposes three core primitives (Resources, Tools, Prompts), plus the Elicitation mechanism added on 2026-07-28. A Server is an independent process or remote service that only receives necessary context information and cannot see the complete conversation history.

The control hierarchy is as follows:

Elicitation (new): The server requests additional information from the user during processing, supporting both Form and URL modes. It is not a fourth primitive but rather an interaction mechanism embedded within Tools/Prompts/Resources call flows.

1.3 Design Principles

The 2026-07-28 version reaffirms four design principles:

1. Servers should be extremely easy to build. The Host assumes complex orchestration responsibilities; the Server focuses solely on a specific capability.
2. Servers should be highly composable. Each Server works independently; multiple Servers can be combined seamlessly.
3. Servers should not read the complete conversation, nor should they "see" other Servers. Each Server receives only the necessary context information; the full conversation history stays in the Host.
4. Capabilities can be added progressively. The core protocol provides minimal required functionality; additional capabilities are negotiated on demand, maintaining backward compatibility.

1.4 Messages and Patterns

MCP is based on JSON-RPC 2.0. Each request carries a unique ID and must include _meta metadata (protocol version, client capabilities). Responses carry a resultType field supporting polymorphic results: complete (successfully completed), input_required (additional input needed, triggers MRTR), task (an async task was created).

Three message patterns:

• Request-Response: Standard request-response cycle
• Multi Round-Trip Requests (MRTR): The server returns a response requiring additional input; the client supplements information and retries. See Section II for details.
• Subscribe-Notify: The client subscribes to change notifications via subscriptions/listen; the server pushes via SSE (Server-Sent Events, an HTTP streaming push mechanism).

On the transport layer, Streamable HTTP removes the GET stream endpoint and protocol-level Session, switching to a purely stateless POST request model. Request metadata is mirrored to the HTTP layer via three standard headers (MCP-Protocol-Version, Mcp-Method, Mcp-Name), allowing load balancers and gateways to make routing decisions without unpacking the body. The transport-layer statelessness is part of the overall stateless design; the mechanism details are covered in Section II.

---

II. In-Depth Analysis of Key Changes

2.1 Statelessness: A Protocol-Level Rewrite

The old specification (2025-11-25 and earlier) used a "handshake-session" model. The client sends an initialize request; the server allocates an Mcp-Session-Id; all subsequent requests must carry this ID, bound to a fixed server instance. When the session ends, an initialized notification is sent. This is logically consistent with the traditional web Cookie/Session mechanism.

The new specification (2026-07-28) completely removes this mechanism:

• Removes initialize handshake and Mcp-Session-Id
• Each request is self-contained via the _meta field, carrying protocol version, client capabilities, and credentials
• Any server instance can independently handle any request
• A connection does not equal a session; unrelated requests can be interleaved on the same STDIO (standard input/output) connection

The specification states plainly: "Servers MUST NOT rely on prior requests over the same connection to establish context."

Version negotiation also shifts from a one-time handshake to a per-request behavior. Each request carries protocolVersion in _meta; the server independently accepts or rejects it, returning UnsupportedProtocolVersionError (error code -32022) with a list of supported versions when it cannot comply. The server must implement the server/discover method; the client may optionally call it before sending other requests for upfront capability discovery, but is not required to.

The impact of this change on deployment topology:

This is a necessary condition for MCP to move toward infrastructure. The stateful design was adequate for prototyping, but in production environments it locked deployment architecture into single-instance or session-affinity modes. Statelessness unlocks horizontal scaling, multi-region failover, Kubernetes-native deployment, and all other production-grade capabilities.

But statelessness is not free. Each request now carries complete metadata (protocol version, capability declarations, identity information), increasing payload size. Version negotiation shifts from one handshake to every request, saving round trips but adding per-request processing overhead. The requestState blob in MRTR requires servers to encrypt and verify it each time, a disproportionate cost for high-QPS simple tool calls. For scenarios requiring incremental context building (e.g., progressively establishing server-side understanding across multiple conversation turns), the new specification requires encoding state explicitly into each request, or maintaining long-lived context through the Tasks extension, raising engineering complexity rather than lowering it.

Some use cases that naturally relied on stateful sessions under the old specification become harder. For example, a Server that wants to learn about the client's environment (operating system, project structure) on first call and reuse that information subsequently. Under the old spec, this happened during the initialize handshake at zero additional cost. Under the new spec, it must either be passed in every request, encoded via requestState, or maintained through Tasks for persistent context. This is the concrete cost of the "statelessness tax."

The tradeoff result: for common scenarios like single stateless tool calls, the new specification yields a net-positive outcome. For scenarios requiring continuous session context, the new specification introduces additional engineering burden. The spec chose to optimize for the former, a reasonable engineering judgment, but not one without cost.

2.2 MRTR: Request Retry Replaces Bidirectional Channels

The old specification allowed servers to directly initiate JSON-RPC requests to clients (e.g., sampling/createMessage, roots/list). This required a bidirectional communication channel: the client's request hangs while the server makes a reverse call to the client mid-processing. This works under a stateful model but fails under a stateless one.

Multi Round-Trip Requests (MRTR) solves this with request retry plus an encrypted state blob.

Round 1: The client sends tools/call (id: 1). The server determines it needs additional information and returns InputRequiredResult (resultType: "input_required"), containing inputRequests (describing what information is needed) and requestState (an opaque string representing server-side context).

Round 2: The client collects user input and resends the original request (id: 2, must differ from id: 1), attaching inputResponses and the original requestState verbatim. Any server instance processes this retry, recovers context from requestState, and returns the final result.

requestState is the security core of this mechanism. The client must not inspect, parse, or modify it. The specification requires servers to treat it as attacker-controlled input: if requestState influences authorization or resource access, the server must protect its integrity using HMAC (Hash-based Message Authentication Code) or AEAD (Authenticated Encryption with Associated Data). For replay prevention, the spec recommends including the authenticated principal, a short TTL (time-to-live), and the original request identifier in the encrypted payload. Single-use is not guaranteed: scenarios requiring strict one-time semantics (e.g., one-time redemption) must implement server-side deduplication.

MRTR changes the Server's interaction model. In the old model, the Server was passive, receiving requests and returning synchronously, issuing reverse requests to gather more information when needed. In the new model, the Server can proactively request input, but achieves this by "returning rather than reverse-calling." Server logic becomes a state machine: on each request, it decides the next step based on requestState and the new inputResponses. This pattern resembles the web form POST-Redirect-GET flow, sacrificing one round-trip of latency in exchange for a fully stateless deployment architecture.

MRTR can be triggered on tools/call, prompts/get, and resources/read, covering all three server-to-client request types: Elicitation (collecting information from the user), Sampling (requesting client-side LLM completion), and List Roots (requesting filesystem root directories; deprecated but retained for compatibility).

2.3 Elicitation: Structured Human-Machine Interaction

Elicitation is the first application of MRTR. Form Mode collects structured data; URL Mode handles sensitive operations.

Form Mode defines the expected data structure via JSON Schema, and the client renders a form. Schema is limited to flat objects with primitive types (string, number, boolean, enum), no nesting. This is a deliberate simplification so clients do not need a full JSON Schema UI engine. Security constraints are explicit: collecting passwords, API keys, tokens, or payment credentials via Form Mode is prohibited.

URL Mode is for OAuth authorization, payments, third-party authentication, and similar scenarios. The server returns a URL; the user completes the operation in a browser, and the data never passes through the MCP client. The client's responsibility is to display the target domain and open the browser after obtaining user confirmation.

The division of labor between the two modes clearly draws the boundary of "who handles sensitive data." The MCP client is not a credential manager and does not touch authentication secrets.

2.4 Tasks Extension: Async Long-Running Jobs

The old protocol only supported synchronous calls. A tool call running for several minutes would either block or time out the connection. This is infeasible for CI/CD (Continuous Integration/Continuous Deployment), batch data processing, model training, and similar scenarios.

The Tasks extension fills this gap. When the server determines a request is a long-running task, it returns a task handle:

1. Creation: The tools/call response returns CreateTaskResult (resultType: "task"), containing taskId, initial state, TTL, and suggested polling interval.
2. Polling: The client periodically calls tasks/get(taskId) to retrieve status.
3. Mid-task interaction: When the task enters the input_required state, the client submits user input via tasks/update.
4. Terminal states: completed (with final result), failed (with error), cancelled.

Key property: taskId is a persistent handle. After the client disconnects and reconnects, it can continue polling with the same ID. Tasks can pause in input_required to await human approval before proceeding, making workflow review checkpoints natively supported. The server can push status changes via notifications/tasks as an alternative to polling.

It is important to note that Tasks is an extension, not a core protocol change. The core protocol remains synchronous-first; Tasks provides an optional path for scenarios requiring asynchronicity. But this path's ecosystem significance is substantial: CI/CD pipeline wrapping, data processing workflows, human approval flows, and integration with external async task systems can all be accomplished within the MCP framework.

2.5 Extension System: Modular Evolution

The new specification establishes a formal extension mechanism. Official extensions use the io.modelcontextprotocol/{name} identifier; third-party extensions use reverse-DNS prefixes (e.g., com.example/my-extension). Extensions are standardized through the SEP (Specification Enhancement Proposal) process.

Negotiation happens within capability declarations: the client declares supported extensions in clientCapabilities.extensions on each request, and the server declares its own in server/discover responses. Extensions unsupported by either side automatically degrade to core protocol behavior. Extensions are off by default and require explicit opt-in from developers.

Current extension ecosystem:

The extension system allows MCP's capability boundary to expand without modifying the core specification. A new capability first incubates as an experimental extension and, after validation, graduates to an official extension via the SEP process. This is far more flexible than cramming everything into the core protocol, and it reduces the specification's own complexity.

2.6 Other Notable Changes

Roots (exposing filesystem root directories to the Server) is marked deprecated (SEP-2577), with a 12-month grace period before removal. The replacement is passing file paths via tool parameters, resource URIs, or server-side configuration. Under the stateless model, the Roots interaction of "client declares available directories" becomes redundant overhead.

Result type system: Every response's result must include a resultType field. The client selects a handling path based on the result type. Backward compatible: absent values default to complete.

Error code reorganization: The JSON-RPC reserved range -32000 to -32099 is formally partitioned. -32000 to -32019 are legacy and will not be assigned new codes. -32020 to -32099 are specification-defined, with existing entries HeaderMismatch (-32020), MissingRequiredClientCapability (-32021), and UnsupportedProtocolVersion (-32022).

Pagination and caching: tools/list and resources/list support cursor-based pagination. Responses may carry ttlMs (cache validity period) and cacheScope (public/private). Servers are advised to return deterministic ordering, consistent sort order for the same tool set, which directly improves LLM prompt cache hit rates.

x-mcp-header: Tool parameters can be annotated with this attribute, mapping to Mcp-Param-{name} HTTP headers in Streamable HTTP transport. Load balancers and WAFs (Web Application Firewalls) can route based on parameter values without parsing the JSON body. Annotating sensitive parameters is prohibited.

Native OpenTelemetry support: _meta reserves traceparent, tracestate, and baggage (three W3C TraceContext standard fields) for distributed tracing. When an agent operation spans multiple MCP Servers, the call chain can be correlated from the protocol layer.

JSON Schema upgraded to 2020-12. $ref must not automatically dereference network URIs (SSRF, Server-Side Request Forgery protection); combination keywords are recommended to have depth and count limits (DoS protection).

---

III. Structural Changes for Production Readiness

Moving from the technical analysis in Section II to production deployment requires understanding the new specification's structural requirements across three dimensions: deployment architecture, security model, and compatibility.

3.1 Deployment Architecture: Cloud-Native Ready

The old specification's deployment was fundamentally single-machine. A Host process connects to a local MCP Server via STDIO, or to a fixed instance via HTTP. Session binding made horizontal scaling infeasible.

Deployment patterns the new specification enables:

Multi-replica load balancing: MCP Servers can be deployed like ordinary HTTP microservices, with multiple replicas behind a round-robin load balancer. The three standard HTTP headers (MCP-Protocol-Version, Mcp-Method, Mcp-Name) allow API Gateways to route by method (tools/call to compute-intensive instances, resources/read to cache layers), distribute by tool name, and perform canary releases by protocol version.

Kubernetes-native: Statelessness means Pods can be created and destroyed at will. HPA (Horizontal Pod Autoscaler) applies directly. Rolling updates achieve zero downtime.

Multi-region failover: Requests can be routed to any region; global load balancers route by latency, and regional failures trigger automatic failover without requiring cross-region session state replication.

CDN caching: tools/list responses with cacheScope: "public" can be cached by CDNs or proxies. Tool listings change infrequently, yielding high cache hit rates.

3.2 Security Model: Six Layers

The new specification's security design is substantially more systematic than the old version.

Protocol-level principles: User consent and control (explicit consent required for all data access), data privacy (Host exposes data only after obtaining consent), tool safety (tools represent arbitrary code execution; annotations are untrusted unless from a trusted Server).

requestState security: Must be protected with HMAC or AEAD when influencing authorization or resource access. Servers must treat it as attacker-controlled input. Replay prevention should include authenticated principal, TTL, and original request identifier. Single-use is not guaranteed.

Elicitation security: Form Mode prohibits credential collection; URL Mode is for sensitive operations; the client must display which Server is requesting information.

Transport security: Servers must validate the Origin header against DNS rebinding attacks, bind only to localhost for local execution, and implement authentication on all connections. The X-Accel-Buffering: no header ensures SSE streams are not buffered by reverse proxies.

JSON Schema security: $ref does not dereference network URIs by default; combination keywords should have complexity limits.

Extension security: Off by default, requiring explicit opt-in; third-party extensions use their own domain prefixes to avoid conflicts.

3.3 Observability: Protocol-Level Built-in

_meta reserves three OpenTelemetry standard fields (traceparent, tracestate, baggage) for W3C TraceContext distributed tracing. io.modelcontextprotocol/logLevel lets clients specify log levels per request; Server logs are pushed via notifications/message. The ttlMs and cacheScope in responses make caching behavior controllable and traceable.

3.4 Backward Compatibility: Dual-Era Coexistence

The new specification defines a complete compatibility matrix. "Dual-era" refers to a Server or Client that supports both the old and new protocol versions.

Dual-era Servers select mode by detecting client opening behavior: requests with _meta follow modern semantics; initialize requests follow legacy semantics; both can coexist on the same endpoint. This enables gradual migration in production: upgrade to dual-era first, then switch to Modern-only once all clients have migrated.

3.5 Production Migration Checklist

Must do:

1. Implement server/discover on the Server side
2. Include protocolVersion and clientCapabilities in _meta on every request
3. Remove dependencies on initialize handshake and Mcp-Session-Id
4. Replace Server-to-Client requests with MRTR pattern
5. Protect requestState integrity with AEAD or HMAC
6. Carry the three standard headers on Streamable HTTP requests

Should do:

1. Implement dual-era support for smooth transition
2. Return deterministic ordering for tool lists to improve cache hit rates
3. Include ttlMs and cacheScope in responses
4. Evaluate the Tasks extension for long-running operations
5. Implement OpenTelemetry trace context propagation
6. Evaluate Elicitation's two modes as replacements for legacy interaction patterns

Do not:

1. Do not use Roots (deprecated)
2. Do not collect credentials in Form Mode
3. Do not auto-dereference external $ref
4. Do not assume requests on the same connection share context
5. Do not include unencrypted sensitive information in requestState

---

Conclusion

The MCP 2026-07-28 version does three structural things.

First, it transforms the protocol from stateful to stateless. This unlocks horizontal scaling, load balancing, multi-region failover, Kubernetes-native deployment, and all other production-grade capabilities. MCP can now be deployed like an ordinary microservice. The cost is per-request metadata overhead and requestState encryption, a disproportionate burden for simple tool-call scenarios, but a net-positive for the vast majority of production deployments.

Second, it replaces bidirectional channels with MRTR. The request-retry-plus-encrypted-state-blob pattern allows any instance to handle any retry, reconciling the need for server-to-client interaction with a stateless architecture. The cost is one additional round-trip of latency.

Third, it establishes an extension system. Capabilities like Tasks, Apps, and Elicitation exist as optional extensions without polluting the core protocol. The Tasks extension makes async workflows possible within the MCP framework, but this remains an extension-level capability: it does not change the core protocol's synchronous nature.

Combined with the protocol's donation to the Linux Foundation and support from major vendors, MCP is moving from "Anthropic's tool protocol" toward "an industry-neutral AI tool-calling standard." On this trajectory, statelessness and the extension system are two key architectural cornerstones.

The next thing to watch is Skills over MCP: if Agent workflow definitions can be discovered and consumed via the MCP standard, it could catalyze a standardized capability marketplace for the Agent ecosystem.

---

Sources: MCP official specification modelcontextprotocol.io/specification/2026-07-28, SEP-2322 (MRTR), Tasks extension documentation modelcontextprotocol.io/extensions/tasks/overview. Data as of July 29, 2026.