MCP Servers in 2026: What the New Stateless Spec Changes

The Model Context Protocol published its 2026-07-28 specification as final on July 28, 2026, and it is the largest revision since the protocol launched. The headline change is that MCP is now stateless at the protocol layer: the initialize handshake and the session ID header are gone. If you depend on MCP servers rather than build them, the practical translation is that these integrations just got a lot easier to run in production, and that a client and a server on different revisions is now a real way for things to break.

We could write the changelog. The changelog already exists. What is harder to find is the version for someone who runs a business, depends on a handful of these connections, and needs to know whether this is a Tuesday problem or a next-quarter problem.

What is an MCP server, in one paragraph?

An MCP server is a standard adapter that exposes one system's tools and data to any AI client that speaks the protocol. It is what lets a model read your ticket queue, search your document store, or write a record to your CRM without someone building a bespoke integration for every model you might want to use. Before a shared protocol, connecting N models to M systems meant building and maintaining N times M integrations, which is the kind of math that quietly kills an AI roadmap.

That is the whole idea. If you want the longer primer, we wrote one earlier this year: MCP in plain English for businesses. This post is about what changed.

What changed on July 28, 2026?

Four things matter.

The core went stateless. The specification eliminates the initialize and initialized handshake along with the Mcp-Session-Id header. Requests now travel independently, carrying the protocol version and client identity in metadata rather than depending on a live session. MCP moved from a bidirectional stateful protocol to a request and response model.

Extensions became a governed framework. MCP Apps (server-rendered UI in a sandboxed iframe), Tasks (long-running work), and Enterprise Managed Authorization are now formal extensions rather than experimental parts of the core. Tasks in particular moved out of the experimental core into its own extension namespace, which means it can evolve without waiting on a spec revision.

Authorization got stricter. Three changes stand out: RFC 9207 issuer validation, where servers must return an iss parameter and clients must validate it before redeeming an authorization code; an application_type declared at client registration, which is what permits localhost redirects for desktop and CLI applications; and client credentials bound to their issuing authorization server so they cannot be reused across servers.

There is a formal deprecation policy now. Deprecated features stay functional for at least twelve months. Roots, Sampling, Logging, and the legacy HTTP with SSE transport are all in that window. This is genuinely good news, because it turns an upgrade into something you can plan rather than react to.

The revision does carry non-backward-compatible changes. A server on the new revision may not work with an older client, and the reverse is also true.

Why does statelessness matter if you are not the one running the server?

Because it is the difference between an integration that demos well and one you can put on the critical path of a business process.

Here is the version without jargon. A stateful protocol means the server has to remember who you are between requests. Remembering means the client has to keep hitting the same server instance, which means sticky sessions at the load balancer, which means either a shared session store or a rule that pins traffic to one box. Every one of those is a thing that can fail. When the pod restarts, the session is gone. When traffic grows and you add instances, the routing gets fragile in a way that is annoying to debug.

Stateless removes that entire category of problem. A remote MCP server that previously needed sticky sessions, a shared session store, and gateway-level inspection can now sit behind a plain round-robin load balancer. Servers can deploy on serverless and edge infrastructure. A restart stops being an outage.

This is our standing position stated once and then dropped: in most AI projects we see, the model is rarely the risk. The plumbing is. A spec that finally treats these connections as ordinary HTTP requests is a maturity signal, and maturity signals are what a business should actually be waiting for before it puts something load-bearing on a new technology.

What should a team actually do about this quarter?

Four things, in order, none of which involve a rewrite.

Inventory what you depend on. List every MCP server your agents talk to, first-party and vendor, and write down who maintains each one. Most teams cannot produce this list from memory, which is itself the finding.

Ask your vendors which revision they target, and when. This is the question that used to be optional and is not anymore. Cross-revision pairs may simply not interoperate, so "we'll get to it" from a vendor on your critical path is an answer worth escalating.

Put authorization on the review list. Issuer validation and registration application types are not cosmetic. If a vendor cannot tell you how they handle the RFC 9207 changes, that tells you something about how much attention the integration is getting.

Do not rush. The twelve-month deprecation window exists precisely so nobody has to do this in a panic. A planned migration next quarter beats an unplanned one this week.

If any of that inventory turns out to be load-bearing and nobody owns it, that is the kind of AI integration for business work we do, and it is usually a smaller project than teams expect.

Should a smaller team build MCP servers at all?

Sometimes. The honest build-versus-buy line runs roughly here.

Use the vendor's server when one exists. If your CRM, your help desk, or your data warehouse ships an MCP server, use it. You are not going to out-maintain the people who own the API, and a connector you build is a connector you own forever.

Build a thin one when the system is yours. Internal tools, your own database, a process that only exists in your company: nobody else is going to build that, and it is usually a small piece of work if you keep it small.

The failure mode we see most often is over-scoped tool surfaces. Teams mirror their entire API into tools, end up with sixty of them, and then wonder why the agent picks the wrong one. Fewer, sharper tools beat an exhaustive mirror almost every time. A tool should map to a decision someone actually makes, not to an endpoint that happens to exist.

For buyers, governance is worth one line. Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation on December 9, 2025, alongside founding contributions from Block and OpenAI and support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. Every major lab now ships MCP support in its agent stack. The old objection to adopting a connector standard was that you were betting on one vendor's format. That objection is now weak, and a vendor-neutral protocol under a foundation is the cheaper bet for a business that does not want to pick a lab for the next decade.

Frequently asked questions

Is MCP an Anthropic thing? It started at Anthropic and is no longer governed there. It moved to the Agentic AI Foundation under the Linux Foundation in December 2025, and OpenAI, Google, Microsoft, and AWS all build on it.

Do I need to upgrade immediately? No. Deprecated features stay functional for at least twelve months. The urgent part is knowing what you depend on and what revision each piece targets, not shipping a migration this month.

Does MCP replace an API? No. It sits in front of one. The API is still how the system works. MCP is a standard way to describe that system's capabilities so any compliant AI client can use them without a custom integration.

What breaks if my client and server are on different revisions? Potentially the connection itself. The revision includes non-backward-compatible changes, so a mismatch is a failure mode rather than a warning. This is why the vendor question above is the practical one.

Should this change our roadmap? Usually not the roadmap, but possibly the confidence level. If you shelved an integration because remote MCP servers looked operationally fussy, that objection is materially weaker now.

The pattern here is one we have watched play out in three products we build and run: Smile PreVue, Howdy Dispatch, and RunLink. The interesting work is almost never the model. It is the boring connective tissue that decides whether the thing survives contact with real traffic. A protocol getting less clever is usually a sign it is getting more useful.

If you want help figuring out what your agents actually depend on, and what to do about it, tell us what you are building.