Two things carry the date 2026-07-28: the Model Context Protocol's stateless spec goes final, and a stable v2 of the official Python SDK (mcp) is targeted for the same day. It's tempting to read that as "upgrade day." It isn't. A finalized spec and a production-ready SDK run on different clocks, and if you're shipping an MCP server to real users this week, the version you build on is v1.x — not the v2 stateless rewrite. Here's the one-screen answer, then the reasoning and the single command that keeps a breaking major from arriving in a deploy you didn't plan.
The one-screen answer#
- Ship on v1.x today. The SDK's own README is blunt: "v1.x is the only stable release line and remains recommended for production." Current stable is 1.28.1 (June 26, 2026). It keeps getting critical bug fixes and security patches on the
v1.xbranch. - v2 is a pre-release. v2.0.0 (
2.0.0rc1) is "a major rework of the SDK" aligned to the stateless spec — and the README says, in as many words, "do not use v2 in production yet." - Pin your upper bound now:
mcp>=1.27,<2. pip and uv won't grab a pre-release on their own, but the day stable v2 publishes, an unpinnedmcpresolves to a breaking major on the next clean install. One character of insurance. - Migrate to v2 deliberately — when it's stable, when you've read what breaks, and when statelessness actually buys you something. Deprecated features live at least 12 months, so this is a schedule you set.
Why "spec is final" doesn't mean "v2 is your default"#
The 2026-07-28 revision makes MCP stateless: it removes the initialize handshake and the Mcp-Session-Id header, so any request can hit any server instance behind a plain round-robin balancer — the change we walk through in MCP Goes Stateless: what the 2026-07-28 spec changes. That's the protocol. The SDK that implements it in Python has to be rebuilt to match, and that rebuild is v2 — currently a release candidate, not a shipped-and-hardened stable.
The maintainers drew the line for you. v1.x is "the only stable release line," still recommended for production; v2 is the rework and carries an explicit "do not use in production yet." That's not hedging — it's the difference between a spec that's content-locked and an SDK whose public API is still settling under the rc label.
And the spec going final doesn't put v1.x on a clock. The stateless revision ships with a formal 12-month deprecation policy: the features it removes or deprecates keep working for at least a year. Your v1.x server is not about to stop being valid. You are not being handed a deadline.
The one command to run today#
Whether or not you ever intend to touch v2 this quarter, do this now:
# in your server's dependency spec (pyproject.toml / requirements.txt)
mcp>=1.27,<2The reasoning, straight from the SDK's migration note: pre-releases aren't selected automatically by pip or uv, so you're safe today on an unpinned mcp. But the day stable v2.0.0 publishes, that unpinned dependency starts resolving to a new breaking major on your next clean install or CI run — the classic "our build broke and nobody changed anything" incident. An explicit <2 upper bound removes the possibility entirely and costs you nothing. Add it, commit it, move on.
If you want the full inventory of what changes across the boundary before you plan a move, we kept it separate: the MCP v2 SDK betas — what actually breaks.
When v2 is the right call#
Adopt the stateless SDK when three things line up:
- v2 is stable — a real release, not an rc. "Targeted for 2026-07-28" is a target; wait for the tag.
- You've read what breaks. The handshake and session id are gone; Sampling and Roots are deprecated (use direct LLM-provider APIs and tool parameters or resource URIs). If your server leans on any of those, that's migration work, not a version bump.
- Statelessness earns its keep. The concrete payoff is horizontal scaling: a stateless server lets any request land on any instance behind a plain round-robin load balancer — no sticky sessions, no shared session store. If you run a single instance today, that benefit is theoretical, and there's no reason to rush onto a pre-release to get it.
The deeper you are into infrastructure — multiple instances, autoscaling, a load balancer you'd rather keep dumb — the sooner v2's model pays off. The closer you are to "one process serving a handful of tools," the longer v1.x is simply the correct answer.
If you're still choosing how to build the server at all#
This piece assumes you've picked the official SDK. If you're earlier than that — deciding between the low-level Server, the bundled FastMCP decorators, and the standalone FastMCP package — start with FastMCP vs the official SDK: building an MCP server in 2026, then come back here for the version call. And if the open question is which language SDK to standardize on in the stateless era, that's its own decision.
The through-line for all three: on the day a spec finalizes, the disciplined move isn't to chase the newest tag — it's to ship on the stable line, pin the upper bound so the future can't surprise you, and cross the version boundary on a date you choose. For everything else that landed this week and what a team of one should do about it, see this week's Founder's Wire.
