The Vibe Father
The MCP 2026-07-28 specification is the largest revision of the Model Context Protocol since it launched, and the headline change is that the protocol goes stateless. The initialize handshake and protocol-level session are gone. Beta SDKs for Python, TypeScript, Go and C# are already available against the release candidate.
If you run agents in production, this is the most consequential infrastructure change of the quarter — more so than any model launch, because it changes how your servers scale rather than how well they answer. Here is what changed, what breaks, and the order to migrate in.
Related the 2026 agent framework landscape and running agents in a controlled harness.
The stateless core
Previously an MCP client opened a connection, performed an initialize handshake to exchange protocol version, client info and capabilities, and then held a protocol-level session for the duration.
In 2026-07-28 that is removed. Protocol version, client info and client capabilities now travel in _meta on every request, and a new server/discover method lets a client fetch server capabilities when it wants them up front.
| Before | After 2026-07-28 | |
|---|---|---|
| Connection setup | initialize handshake | None — first request carries everything |
| Capability exchange | Once, at connection | _meta per request, or server/discover |
| Session | Protocol-level, held open | No protocol-level session |
| Load balancing | Sticky sessions required | Plain round-robin |
| Shared session store | Needed across replicas | Not needed |
The operational payoff is large and immediate you can put an MCP server behind an ordinary round-robin load balancer. No sticky sessions, no shared session store, no affinity rules. Any replica can serve any request, so an MCP server becomes a normal stateless HTTP service that scales like everything else you run.
The cost is per-request overhead. Metadata that used to be exchanged once now rides on every call. For most deployments that is a fair trade — the bytes are small and the operational simplification is not.
Extensions become first class
The revision makes extensions a versioned, first-class mechanism rather than an informal convention, and ships two significant ones.
| Extension | What it enables | Who needs it |
|---|---|---|
| MCP Apps | Server-rendered UIs delivered through MCP | Tools whose output is interactive, not text |
| Tasks | Long-running work with a proper lifecycle | Anything slower than a request timeout |
Tasks is the one that matters for coding agents. Until now, a tool call that takes ten minutes — a full test suite, a large migration, a deploy — had to be faked with polling, a side channel, or a tool that returns immediately and lies about completion. A first-class long-running work primitive removes an entire category of hand-rolled scaffolding.
MCP Apps is more interesting for product surfaces than for terminals, but it matters for coding tools with a visual dimension, diff viewers, dependency graphs, coverage reports, trace explorers. Rendering those as server-provided UI instead of ASCII in a transcript is a real improvement.
Authorization moves toward OAuth and OIDC
Authorization in the new revision aligns more closely with OAuth and OpenID Connect deployments. That is less glamorous than a stateless core and probably more important for anyone trying to get agents through a security review.
The practical effect is that MCP auth stops being a bespoke thing your identity team has to reason about from scratch and starts looking like every other service they already govern. If your blocker on rolling out MCP servers internally was "how do we authenticate this," the answer is now closer to "the same way you authenticate everything else."
What is deprecated
Six Specification Enhancement Proposals drive the changes, and several existing features are now marked deprecated under a new lifecycle policy.
| Feature | Status | What to do |
|---|---|---|
| Protocol-level sessions | Removed | Move state into your own layer |
initialize handshake | Removed | Send _meta per request |
| Roots | Deprecated | Plan a migration, no rush |
| Sampling | Deprecated | Plan a migration, no rush |
| Logging | Deprecated | Plan a migration, no rush |
The lifecycle policy is genuinely good news and deserves more attention than the deprecations themselves. Every feature now follows Active → Deprecated → Removed, with at least twelve months between deprecation and the earliest possible removal.
That is a commitment you can plan against. A protocol that can remove a feature at any time is a protocol you cannot build a product on. Twelve months of guaranteed notice turns MCP from something you adopt nervously into something you can put in a roadmap.
Migration order
You do not need to do this in one pass. Sequence it by risk.
- Take the beta SDK in a branch. Python, TypeScript, Go and C# betas exist for the release candidate — do not hand-roll against the spec.
- Remove session assumptions. Anything your server keeps between calls because "the session holds it" needs an explicit home, a cache, a database, or the request itself.
- Move capability exchange to
_meta. Then verify a cold request with no prior context still works. - Drop sticky sessions from your load balancer and confirm requests survive hitting different replicas.
- Adopt Tasks for anything currently faked with polling.
- Schedule the deprecations. Roots, Sampling and Logging have at least twelve months. Put them on a quarterly list, not this sprint.
- Revisit auth if you deferred an internal rollout on identity grounds.
Step two is where the real work is. Statelessness is easy to declare and awkward to implement if your server accumulated convenience state — a cached working directory, an open database handle scoped to a session, a partially built index. Each of those needs an explicit lifetime now.
Why stateless matters more than it sounds
It is tempting to file this as a plumbing change. It is not, for three reasons.
Scaling stops being special. An MCP server that needs sticky sessions cannot use most of the infrastructure your platform team already operates. One that does not can be deployed like any other HTTP service — same autoscaling, same rollout strategy, same observability.
Failure modes get simpler. With protocol sessions, a replica restart drops sessions and clients have to detect and re-handshake. Statelessly, a replate restart is invisible, the next request lands somewhere else and works.
The cost curve changes. Session affinity forces over-provisioning, because you cannot rebalance load away from a busy replica without breaking its sessions. Round-robin lets you run closer to capacity.
| Concern | With sessions | Stateless |
|---|---|---|
| Deploy a new version | Drain sessions first | Rolling restart |
| Replica dies | Clients re-handshake | Next request routes elsewhere |
| Traffic spike | New replicas take only new sessions | Immediate load sharing |
| Debugging | Which replica held that session? | Every request is self-contained |
What changes if you author MCP servers
Server authors carry most of the migration weight, so it is worth being concrete about the work.
| Pattern you may have | What to do now |
|---|---|
Config cached at initialize | Read from _meta, or expose via server/discover |
| Working directory held per session | Pass it explicitly on each call |
| Open database handle per session | Pool connections at process level |
| Incrementally built index | Move to shared cache or rebuild on demand |
| Auth token validated once | Validate per request — cheap with OAuth patterns |
| Client capability checks at startup | Check per request from _meta |
The recurring theme is that anything scoped to "this connection" now needs a different lifetime. Usually that means one of three homes, the request itself, a process-level pool shared by all requests, or an external cache keyed by something in the request.
A useful test while migrating, start two instances of your server behind a load balancer and send an interleaved sequence of requests. If any request depends on a previous one having hit the same process, it will fail, and that failure is exactly the class of bug the new spec is designed to eliminate.
Observability gets easier, not harder
One counterintuitive benefit. With protocol sessions, understanding a failure meant reconstructing which replica held which session and what state it had accumulated — information that frequently did not survive the incident.
Statelessly, every request carries its own context. A trace of a single request contains everything needed to understand and replay it. That makes MCP servers considerably easier to debug, and it means standard HTTP observability — request logs, distributed tracing, per-endpoint latency — actually tells you what happened.
The trade is volume, metadata on every request means slightly more to log. Sample aggressively in production and keep full fidelity for errors.
What this means for coding agents specifically
Coding agents lean on MCP harder than most agent categories, because the work is tool-shaped, read a file, run a test, query a database, open a PR. A protocol change that makes those tools easier to operate compounds.
The Tasks extension is the standout. A coding agent's most valuable operations are frequently its slowest — running a full suite, executing a migration, waiting on CI. Modelling those as first-class long-running work instead of as a tool call that returns a fake success is the difference between an agent that reports honestly and one that reports optimistically.
The other quiet win is that stateless servers are much easier to run per-repository or per-branch. Spinning up an ephemeral MCP server for a worktree stops requiring session lifecycle management, so isolated agent environments become cheaper to build.
Common questions
When does the MCP 2026-07-28 spec ship?
The release candidate is published and beta SDKs for Python, TypeScript, Go and C# are available. Build against the betas rather than the raw spec.
What is the biggest breaking change?
The removal of the initialize handshake and protocol-level sessions. Any server holding state between calls because the session existed needs to move that state somewhere explicit.
Do I have to migrate immediately?
No. The new feature lifecycle policy guarantees at least twelve months between deprecation and removal, so plan rather than panic. Take the SDK beta in a branch first.
What is the Tasks extension?
A first-class mechanism for long-running work, replacing the polling and side-channel patterns people hand-rolled for operations slower than a request timeout.
Does this change how MCP servers are authenticated?
Yes — authorization aligns more closely with OAuth and OpenID Connect, which generally makes internal security review easier rather than harder.
What is MCP Apps?
An extension allowing servers to deliver rendered UIs through MCP rather than returning only text. Useful for tools whose output is inherently visual — diff viewers, dependency graphs, coverage reports, trace explorers.
Can I run old and new clients against the same server?
Plan for a transition window. The deprecation policy guarantees at least twelve months before removal, so the sensible approach is to support the new revision first and retire old paths on your own schedule rather than in a rush.
Does going stateless make servers slower?
Marginally, per request — metadata that was exchanged once now rides on every call. In exchange you get round-robin load balancing, rolling restarts without draining, and traces that are self-contained. For nearly all deployments that is a favourable trade.
Sources and further reading
- MCP blog, the 2026-07-28 release candidate
- MCP blog, beta SDKs for the release candidate
- Model Context Protocol releases
- Agent frameworks in 2026
- The controlled harness
A closing observation about protocol maturity. The first version of MCP had to prove that a shared tool protocol was worth having at all, and it did that by being easy to implement. This revision is what happens next, the protocol stops optimising for the demo and starts optimising for the operator. Stateless cores, versioned extensions, OAuth alignment and a twelve-month deprecation guarantee are not exciting features. They are the features that let a protocol survive being depended upon, and their arrival is a better signal about the health of the agent ecosystem than any individual model launch this month. The teams that benefit most will be the ones who treat this as an infrastructure upgrade rather than a spec to read later — take the SDK beta into a branch this week, find out which of your servers quietly depend on session state, and fix them while the deadline is still twelve months away rather than next quarter.
