MCP 2026-07-28 is a substantial protocol revision. It changes how remote servers scale, how a server asks a client for input, how optional capabilities evolve, and how implementers approach authentication and tool contracts. The official release candidate announcement calls out a stateless core, extensions, authorization hardening, and a formal deprecation policy; the beta SDK announcement explains how SDKs are preparing to support it.
For someone familiar with the earlier Model Context Protocol, the headline is simple: MCP still connects hosts, clients, and servers over JSON-RPC, but remote communication is no longer built around a protocol session.
A stateless core for remote MCP servers
Previous Streamable HTTP flows started with initialize, returned an Mcp-Session-Id, and carried that session identifier on later requests. The new revision removes the initialize/initialized handshake and the protocol-level session. Each request carries the protocol version and relevant client metadata, while server/discover lets a client obtain server capabilities when it needs them.
flowchart LR
Host[Host application] --> Client[MCP client]
Client -->|server/discover| Gateway[Gateway or load balancer]
Client -->|self-contained request| Gateway
Gateway --> ServerA[MCP server A]
Gateway --> ServerB[MCP server B]
ServerA --> Services[Tools, resources, and application services]
ServerB --> Services
This makes remote MCP fit more naturally behind ordinary HTTP infrastructure. Requests can be distributed without sticky sessions, and gateways can route or rate-limit using Mcp-Method and Mcp-Name headers instead of inspecting a JSON-RPC body. Cache hints and standard W3C trace context also give clients, servers, and gateways clearer rules for caching list and resource responses and correlating a tool call with downstream work.
Stateless protocol traffic does not make every application stateless. A workflow that creates a basket, opens a browser, or starts a long-running operation still needs state. The difference is that the state becomes explicit: a tool returns a handle, and later calls send that handle back as an argument. That is easier to reason about, authorise, log, and test than connection-local state.
Multi-round-trip requests replace server push
Servers sometimes need more input while handling a request: approval before a destructive action, a missing form value, or a model-generated intermediate result. In earlier protocol versions, a server could send a request back through an active client connection. The new revision models this as a request-and-retry flow.
sequenceDiagram
participant Client as MCP client
participant Server as MCP server
Client->>Server: tools/call
Server-->>Client: inputRequired + requestState
Client->>Client: Collect user or model input
Client->>Server: Retry tools/call + inputResponses + requestState
Server-->>Client: Completed tool result
The server returns an inputRequired result containing the information it needs. The client collects the answer and retries the original operation with inputResponses and the echoed requestState. This preserves the interaction without requiring a server to retain an open connection or rely on the next request reaching the same instance.
requestState is deliberately opaque, not trusted. A server should protect its integrity, bind it to the principal and operation that created it, and set an expiry. The TypeScript SDK migration guide provides helpers and examples for this pattern.
Extensions make new capabilities opt-in
The specification now gives extensions a formal home. Extensions are identified and negotiated explicitly, so clients and servers only use a capability when both support it. This allows MCP to evolve without placing every new idea in the core protocol.
Two extensions are particularly visible in this revision:
- MCP Apps let servers provide interactive HTML interfaces that a host renders in a sandboxed iframe. A host can inspect and cache the declared UI template before it runs, while actions still use the normal MCP consent and audit path.
- Tasks provide a lifecycle for long-running work. A server can return a task handle from a tool call, and a client can retrieve updates or cancel the work without treating a persistent protocol session as the task store.
Extensions are useful beyond these two examples. They make room for specialised capabilities to mature independently, while the base protocol stays focused on interoperable context, tools, resources, and prompts.
Tool contracts get more expressive
Tool input and output schemas now use the full JSON Schema 2020-12 vocabulary. Tool inputs still require an object at the root, but they can use composition such as oneOf, anyOf, and allOf, along with $defs and $ref. Outputs are no longer restricted to objects, so structuredContent can represent any JSON value.
This matters most to framework and generator authors. An OpenAPI-based server generator, for example, can preserve shared definitions and composition rather than flattening every contract into an approximation. It also means schema validation needs the same operational care as any other untrusted input: implementations should bound schema depth and validation time, and must not automatically dereference external references.
Authorization and safety move closer to real deployments
The authorization updates align MCP more closely with deployed OAuth 2.0 and OpenID Connect systems. Clients validate the iss parameter on authorization responses, registered credentials are tied to their issuing authorization server, and Dynamic Client Registration records the application’s type. The revision also clarifies incremental scope requests and discovery behaviour.
These protocol rules complement, rather than replace, host safety. Tools can execute arbitrary code and access sensitive data. Hosts still need to show users what will happen, obtain consent before sharing data or invoking tools, and treat tool descriptions and annotations as untrusted unless the server is trusted. The specification’s security guidance remains the right baseline for that responsibility.
Deprecation and adoption are deliberate
Roots, sampling, and logging are deprecated rather than immediately removed. The new lifecycle policy defines active, deprecated, and removed states, with at least a year between deprecation and the earliest possible removal. That gives SDK maintainers and application teams a visible migration path instead of a surprise wire break.
Adopting 2026-07-28 is still an explicit decision. The TypeScript v2 SDK preserves legacy behaviour by default; clients opt into version negotiation and servers use the modern HTTP or stdio entry points. A practical rollout should:
- Identify whether a client or server needs legacy compatibility.
- Test
server/discover, request retries, cancellation, and authorization with real transports. - Make application state explicit before removing any dependency on sessions.
- Add cache, trace, and extension support only where the deployed client and server both support it.
The value of 2026-07-28 is not a single feature. It is a clearer foundation for building MCP servers that can run on common web infrastructure, support richer interactions, and evolve without making every capability a permanent part of the core protocol.