← Blog

MCP 2026: The Standard Grows Up

August 11, 2026

The Model Context Protocol began with a simple promise: give AI applications one consistent way to connect to tools and data. The new 2026-07-28 specification keeps that promise, but rebuilds the protocol for a much bigger world.

The headline is simple: MCP is now stateless at its core.

That sounds like an implementation detail. It is actually the change that makes MCP feel less like a clever integration layer and more like durable internet infrastructure.

Why MCP needed to change

Earlier versions of MCP were connection-oriented. A client and server performed an initialize handshake, negotiated capabilities, and maintained a session. That model worked well for local tools and long-lived connections, but remote production deployments paid for it with sticky routing, shared session stores, and persistent streams.

The new standard removes the initialize / initialized exchange and the Mcp-Session-Id header. Each request carries the protocol version and the context needed to process it. A client can optionally call server/discover first, but it no longer has to establish a session before doing useful work.

A tool call can now stand on its own:

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": { "query": "Melbourne coffee" },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "portfolio-assistant",
        "version": "1.0.0"
      }
    }
  }
}

Any healthy server instance can handle that request. Ordinary load balancers work. Instances can scale horizontally without coordinating protocol sessions. Retries and failure recovery also become easier to reason about.

Stateless does not mean applications cannot have state. It means state becomes explicit. A tool can return a signed handle and accept it on the next call instead of hiding state inside a transport session. That boundary is clearer for developers—and visible to the model orchestrating the workflow.

The rest of the release matters too

Statelessness is the architectural centrepiece, but several supporting changes make the protocol more production-friendly.

Multi-round-trip requests

Some operations cannot finish in one pass. A tool might need the user to confirm a purchase, provide a missing field, or let a model generate an intermediate result.

Multi Round-Trip Requests (MRTR) handle this without keeping a bidirectional stream open. The server returns an input_required result, the client gathers the requested input, and then retries the original operation with those responses attached. Interactive flows become explicit state machines rather than transport tricks.

Infrastructure can understand MCP traffic

Streamable HTTP requests now expose the method and target name through Mcp-Method and Mcp-Name headers. A gateway can route, meter, authorize, and observe traffic without parsing JSON bodies.

This is a small protocol change with a large operational payoff. Existing API infrastructure can distinguish tools/list from tools/call, apply policy to a sensitive tool, and attach meaningful telemetry at the edge.

Discovery results can be cached

Responses from list and read operations can include ttlMs and cacheScope hints. Clients no longer need to repeatedly fetch an unchanged tool, prompt, or resource catalogue.

Stable ordering also helps keep upstream prompt caches effective. In agent systems—where a large tool catalogue may be inserted into context on every run—less churn means lower latency and fewer wasted tokens.

Extensions are first-class

MCP now has a formal extension framework. Capabilities can mature independently without continuously expanding or destabilising the core protocol.

Tasks, for example, move into the io.modelcontextprotocol/tasks extension for long-running operations. MCP Apps and Enterprise Managed Authorization follow the same broader model: the core stays focused while specialised capabilities evolve at their own pace.

Authorization is stricter

The release tightens OAuth behaviour, including issuer validation and isolation of credentials between authorization servers. It also begins the move away from Dynamic Client Registration toward Client ID Metadata Documents.

These changes are less visible than a new tool API, but they close dangerous ambiguity around who issued a credential and where it may be reused. For remote MCP servers, that is foundational work.

What is being left behind

The old HTTP+SSE transport is deprecated. Roots, Sampling, and Logging are also deprecated in the core specification, with a minimum twelve-month window before removal.

Deprecation is not immediate deletion. Existing implementations have time to migrate, while new ones get a clear signal about which capabilities not to adopt. More importantly, MCP now has a formal lifecycle policy, so future changes should arrive with predictable support windows.

A practical migration checklist

If you operate an MCP client or server today:

  1. Upgrade to a supported SDK and explicitly enable the 2026-07-28 protocol—the TypeScript SDK does not switch existing integrations automatically.
  2. Remove assumptions about initialize, initialized, and Mcp-Session-Id.
  3. Move required cross-request state into explicit, integrity-protected handles.
  4. Add Mcp-Method and Mcp-Name handling to Streamable HTTP requests and infrastructure policies.
  5. Implement MRTR for operations that need user input or another model turn.
  6. Honour cache hints and deterministic list ordering.
  7. Review issuer validation, credential isolation, and the move toward Client ID Metadata Documents.
  8. Inventory deprecated Roots, Sampling, Logging, and legacy HTTP+SSE usage.
  9. Test modern and legacy peers during the transition; use server/discover where version negotiation is needed.

The bigger picture

The first phase of MCP was about interoperability: one protocol instead of a custom connector for every AI application and service.

This release is about operability. It asks whether that interoperability still works behind gateways, across autoscaled instances, through OAuth boundaries, during partial failures, and over long-running workflows.

That is the right evolution. Standards become valuable when they disappear into the infrastructure—when connecting an agent to a new capability feels routine, observable, and safe. MCP is not all the way there yet, but 2026-07-28 is its clearest step in that direction.

Further reading