MCP 2026-07-28: what stateless changes

The release changes the operational shape of MCP

Earlier remote MCP deployments could require servers and load balancers to preserve session state. That is workable at small scale, but it complicates failover, autoscaling and multi-region operation. The official MCP project describes the 2026-07-28 release as a shift to a stateless request-response core: each request can carry enough information to land on any healthy instance behind a normal round-robin load balancer.

Authorization also moved forward. The release added issuer validation, issuer-bound credentials and a transition from Dynamic Client Registration toward Client ID Metadata Documents. It also introduced a minimum twelve-month deprecation window, giving production teams a clearer migration horizon.

Why this matters now

The official project reported close to half a billion monthly downloads across its Tier‑1 SDKs at release time, with the TypeScript and Python SDKs each passing one billion total downloads. Anthropic had already reported more than 10,000 active public MCP servers in December 2025 and named adoption across ChatGPT, Cursor, Gemini, Microsoft Copilot and VS Code. These are ecosystem-owner figures, not an independent market census, but they show that MCP is no longer a niche interface experiment.

The more important signal is infrastructural. Microsoft now offers an enterprise MCP server in preview for governed access to Microsoft Graph data. Google Cloud documents remote MCP servers across its services. OpenAI supports custom MCP apps and remote MCP tools. The protocol is becoming a common edge between models and external systems.

Stateless transport does not solve the data layer

The new specification makes an MCP server easier to operate. It does not decide what business data the server should expose, how that data should be ingested, or whether a returned answer is current and traceable. Builders still need to own:

• Source ingestion: syncing files, databases and applications without producing duplicates or stale fragments.
• Permission boundaries: ensuring a key, user or agent can only reach the correct workspace and source scope.
• Retrieval quality: returning the right small slice rather than flooding the context window.
• Provenance: preserving source URLs, titles and stable document identifiers so an answer can be checked.
• Tool design: keeping tools distinct and minimal instead of registering one broad catalog the model cannot navigate.
• Observability: logging calls, failures, latency and usage without leaking secrets or customer content.

This is the distinction developed further in our MCP vs RAG vs API decision guide: MCP standardizes how an agent reaches a capability; it does not replace the systems that make the capability trustworthy.

What builders should do now

1. Target the current specification deliberately. Review the official v2 SDK migration notes rather than assuming a session-based v1 deployment behaves the same.
2. Move routing policy to the edge where appropriate. Header-visible method and tool names can simplify rate limits, authorization rules and service ownership.
3. Treat list caching as a model-quality feature. Stable, deterministic tool catalogs preserve prompt caches and reduce discovery overhead.
4. Audit deprecated features. Roots, Sampling, Logging and legacy HTTP+SSE have defined off-ramps. New designs should use the recommended replacement path.
5. Keep the server surface narrow. A scalable transport can still deliver an unusable tool catalog. Start with discovery and detail operations, then add only what earns its place.

Before any production rollout, work through the SPYN3 production MCP security checklist. The protocol is maturing quickly; permissions and data boundaries still belong to the implementer.