MCP 2026-07-28: Stateless, Production-Ready, and Not Replaced by Skills

The Model Context Protocol just shipped its biggest revision since launch. Spec 2026-07-28 deletes the two things every MCP implementation was built around: sessions and the initialize handshake.

That sounds brutal. It is also the change that finally makes MCP boring infrastructure — the kind you can run behind a load balancer without thinking about it. Here is the short version of what happened, what breaks, and why the "Skills vs. MCP" debate has the wrong premise.

The Headline: Stateless MCP

Until now, talking to a remote MCP server over HTTP meant a ritual: client and server exchanged capabilities, the server minted an Mcp-Session-Id, and every subsequent call had to land on the same process. In production that means sticky sessions, a shared Redis for session state, and gateways doing deep packet inspection to route correctly. Fun at a demo. Painful at scale.

Spec 2026-07-28 removes protocol-level sessions entirely. There is no Mcp-Session-Id header anymore, and no handshake. Every request now carries what it needs in _meta:

• io.modelcontextprotocol/protocolVersion — the version this request speaks
• io.modelcontextprotocol/clientCapabilities — what the client supports
• io.modelcontextprotocol/clientInfo — who is calling

Servers answer with their own identity in each result's _meta. A version mismatch returns UnsupportedProtocolVersionError instead of failing somewhere deep in the call. List endpoints (tools/list, resources/list, prompts/list) no longer vary per connection — the same request gets the same answer, no matter which replica handles it.

If a server genuinely needs state across calls, it mints an explicit handle and the client passes it back as an ordinary tool argument. State becomes application data, not protocol magic.

The practical result: an MCP server is now just an HTTP endpoint. Serverless functions, autoscaling pods, CDN-cached list responses — all of it works without special routing.

What Actually Changed

MRTR is the conceptually interesting one. The old model had servers calling back into clients for sampling, roots, or user input — which only works if the connection is stateful and bidirectional. The new model turns every interaction into a plain request/response cycle that can be retried. Elicitation, approvals, missing parameters: all of it becomes "here is what I still need, ask me again."

The Deprecation List

MCP also adopted a formal feature lifecycle policy: Active → Deprecated → Removed, with a minimum twelve-month deprecation window and a public registry. Nothing disappears overnight, but new implementations should not adopt these:

Roots, Sampling, and Logging becoming deprecated is a statement of intent: MCP is narrowing to what only a protocol can do — transport, discovery, authorization, tool and resource semantics. Everything else belongs to the host application or to purpose-built infrastructure.

Quietly Important: Auth, Caching, Tracing

The minor changes are where the "production ready" part lives:

• Authorization hardening. Authorization servers should return the iss parameter (RFC 9207) and clients MUST validate it before redeeming a code. Client credentials are bound to the issuing authorization server — no reuse across issuers, re-register when it changes. Dynamic Client Registration gives way to Client ID Metadata Documents.
• Cacheable results. tools/list, prompts/list, resources/list, resources/read and templates now carry ttlMs and cacheScope (public/private). Clients cache instead of polling; intermediaries know what they may hold.
• Deterministic tool order. Servers should return tools in a stable order — small change, real effect on LLM prompt cache hit rates.
• OpenTelemetry. Documented conventions for traceparent, tracestate and baggage in _meta. Agent calls become traceable across service boundaries.
• Standard headers. Mcp-Method and Mcp-Name on Streamable HTTP POSTs, so gateways can route and rate-limit without parsing the JSON-RPC body.

Read together: sticky-session-free transport, audience-bound OAuth, cache hints, and distributed tracing. That is the checklist an enterprise platform team hands you before they let anything near production.

Skills vs. MCP: The Wrong Question

Parallel to all this, Agent Skills — plain Markdown files with procedural instructions, loaded on demand into an isolated context — got very popular, and the internet promptly declared MCP dead.

It is not. What is dying is a specific bad habit: mechanically wrapping a REST API into an MCP server. MCP co-creator David Soria Parra has called simple REST-to-MCP wrappers an anti-pattern, and the numbers back him up. Exposing 40 REST endpoints as 40 tools injects 40 JSON schemas into the system prompt on every single turn. In Claude Code, static tool definitions routinely consumed over 56,000 tokens before the user typed anything. Every intermediate payload then flows back through the context window, so moving a document between two systems can push the same text through the model twice.

Attention is finite and quadratic. More tokens means more cost, more latency, and measurably worse recall — context rot.

Two patterns fix this, and neither of them requires abandoning MCP:

• Progressive Discovery (tool search). Don't inject schemas up front. Give the model a search_tools capability and load only the schemas the current step needs. In Anthropic's own measurements this cut Claude Code's base tool overhead from ~56,000 to ~9,000 tokens — roughly 84 % less context burned before work starts.
• Programmatic Tool Calling (Code Mode). Instead of one inference turn per tool call, the agent writes a single script that runs in a sandbox where MCP servers are exposed as normal code APIs. Loops, filtering, and error handling happen locally; only the final result re-enters the context. Reported effect on complex workflows: 150,000 tokens down to ~2,000.

So the 2026 stack is not one mechanism, it is three complementary pillars:

• Agent Skills — procedural knowledge, local workflows, zero upfront cost.
• MCP — the governed connectivity fabric: discovery, authorization, transport, tool and resource semantics.
• Code execution — the efficient runtime where data actually moves.

They compose. A skill can explicitly tell the agent which MCP tools to call and how. Servers can ship their own domain knowledge alongside their tools, so guidance updates travel with the server instead of living in every client. And higher-level layers like MCP Apps (server-rendered UI) sit on top of the protocol kernel rather than inside it — the core stays lean, the ecosystem grows around it.

What To Do Now

1. Drop session assumptions. If your server depends on Mcp-Session-Id, replace it with explicit, server-minted handles passed as tool arguments.
2. Implement server/discover. It is mandatory, and it is your compatibility story for older clients.
3. Move callbacks to MRTR. Anything that used sampling, roots, or elicitation callbacks becomes an input_required result plus a retry.
4. Migrate off deprecated features while the twelve-month window is open — especially HTTP+SSE and Dynamic Client Registration.
5. Stop shipping REST wrappers. Design a small set of agent-native tools, add ttlMs, keep tool order stable, and let progressive discovery or code execution handle the rest.

The Takeaway

MCP is not being replaced — it is being demoted to infrastructure, which is the best thing that can happen to a protocol. The 2026-07-28 revision trades clever bidirectional statefulness for something far more valuable in production: a stateless, cacheable, traceable, audience-bound HTTP protocol that scales like everything else in your cluster.

The naive tool-wrapping era is over. The connectivity-fabric era just started.