EN
Book a call

Technology

MCP v2 Stateless vs MCP v1 Stateful (2026): Python at 2.2.0, Core SDK Still on 1.30.0

MCP v2 stateless vs MCP v1 stateful, four days after the July 28 deadline: the specification tag is final and PyPI mcp is on 2.0.0, but @modelcontextprotocol/sdk is still 1.30.0. Compare scaling, SDK stability, authorization and migration risk.

Reviewed by Michael Kerkhoff, as of

Definition
July 28, 2026 was the MCP migration deadline, and the honest answer changed within hours of it. Re-verified against the registries on August 1: the specification repository's 2026-07-28 tag is now final (prerelease=false, published 2026-07-28T16:47:49Z), and PyPI's mcp moved to 2.0.0 on the same day — so the two objections that defined deadline day, an RC-only specification and a Python ecosystem stuck on 1.28.1, are both gone. One gap survives: the core TypeScript SDK, @modelcontextprotocol/sdk, is still 1.30.0 from July 27. MCP v2 moves the protocol core to stateless request/response and adds Extensions, Tasks, MCP Apps, authorization hardening and a formal deprecation policy. MCP v1 remains the maintained baseline — and, if your code imports the core TypeScript SDK, still the only thing you can install. Re-verified 2026-09-08: PyPI's mcp is now 2.2.0 (with a same-day v1.30.0 backport), while @modelcontextprotocol/sdk has sat at 1.30.0 on npm for six weeks.
Category
Technology
Options
MCP v2 StatelessMCP v1 Stateful

Detailed Comparison

A side-by-side analysis of key factors to help you make the right choice.

MCP v2 Stateless vs MCP v1 Stateful
FactorMCP v2 StatelessMCP v1 Stateful
Horizontal scalingAny request can be routed to any compatible server instance once the app keeps state outside the protocol server WinnerLong-lived sessions and connection affinity are easier to reason about, but they complicate autoscaling and failover
SDK stabilityShipped in stages: the scoped server packages went 2.0.0 stable on July 27 and PyPI mcp followed on July 28, but @modelcontextprotocol/sdk is still 1.30.0 — v2 is installable everywhere except the core TypeScript packageStill what you get from @modelcontextprotocol/sdk, and still the maintained line for bug and security fixes on that package
Serverless and ephemeral hostingDesigned for short-lived request/response execution, so Vercel, Cloud Run, Lambda-style and container autoscaling patterns become cleaner WinnerWorks best when a process can keep session context alive; possible in serverless, but operationally awkward
State management modelForces state into explicit client context, shared stores or application databases, which is cleaner but requires refactoringLets server code keep conversational/session assumptions in memory, which is convenient for simple internal tools
Ecosystem compatibility todayThe specification is final and both the TypeScript server surface and Python are installable at 2.0.0, so a mixed-language stack can now move almost as one unit WinnerMost existing examples, packages and internal servers still assume v1 behaviour, and anything importing the core TypeScript SDK has no alternative
Authorization and governanceThe final 2026-07-28 specification requires OAuth 2.0 Protected Resource Metadata (RFC 9728) to advertise the authorization server location, and bundles a formal deprecation policy into the protocol roadmap WinnerAuthorization can be governed at the gateway, but the protocol line is older and less explicit about the new model
Migration riskNow spread across both registries: an unpinned install can jump to 2.0.0 on four scoped npm packages and on pip install mcp without you asking, so version bounds and parallel testing are mandatoryLow if you pin — but the risk is live on npm and PyPI now, not just on npm Winner
Future-proofingAligned with a specification that is now final rather than a release candidate; the server packages and Python are already there and the core SDK is the only piece still to follow WinnerA compatibility baseline with a named escape hatch (server-legacy), but one that shipped already deprecated
Security hardening (September 2026)2.x is the hardening line: origin-bound redirects since 2.2.0, authorization-server issuer checks on every OAuth path, opt-in token-resource validation, session idle/expiry caps — the containment lessons of the agent-SSRF incidents, shipped in the client itself Winnerv1.30.0 backports only the redirect origin-binding; legacy-path issuer checks and the new auth/session controls stay out. The 1.x line now demonstrably receives maintenance, not progression
Total Score · 2 ties6 / 91 / 9

Key Statistics

Real data from verified industry sources to support your decision.

  • The scoped MCP server packages — @modelcontextprotocol/server, /node, /hono and /server-legacy — all published their first non-prerelease 2.0.0 at 23:55 UTC on 2026-07-27, five minutes before deadline day, after four alphas and five betas. — npm registry (@modelcontextprotocol/server) (2026)
  • The specification tag 2026-07-28 is final: GitHub reports prerelease=false, published 2026-07-28T16:47:49Z — the first final MCP specification since 2025-11-25. — modelcontextprotocol/modelcontextprotocol GitHub releases (2026)
  • The core TypeScript SDK still has no 2.x: @modelcontextprotocol/sdk latest is 1.30.0, published 2026-07-27T17:56 UTC — it did not move when the scoped server packages, PyPI and the specification all went final. — npm registry (@modelcontextprotocol/sdk) (2026)
  • PyPI's mcp moved to 2.0.0 on 2026-07-28T13:45:28Z, superseding the 1.28.1 published on 2026-06-26 — a plain pip install mcp now installs v2. — PyPI (mcp) (2026)
  • The v1 escape hatch shipped pre-deprecated: server-legacy is published as “Frozen v1 SSE transport and OAuth Authorization Server helpers… Deprecated; use StreamableHTTP and a dedicated OAuth server in production.” — npm registry (@modelcontextprotocol/server-legacy) (2026)
  • The maintainers say 84% of more than 10,000 PyPI packages that depend on mcp declare no upper bound, so an unpinned install can pull a breaking v2 pre-release. — modelcontextprotocol/python-sdk GitHub (2026)
  • The July 28 deprecations of Roots, Sampling and Logging are annotation-only: those methods, types and capability flags keep working in this release and in every spec version published within a year of it, so existing v1 servers do not break on July 28. — Model Context Protocol Blog (2026)
  • MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728) to advertise their authorization server location; the 2026-07-28 RC additionally restricts server-initiated requests to only be issued while the server is actively processing a client request (SEP-2260). — Model Context Protocol Authorization Spec (2026)
  • The Python SDK line moved to 2.2.0 on PyPI on 2026-09-07, four weeks after 2.0.0 became the plain-pip default — while npm's @modelcontextprotocol/sdk remains at 1.30.0 with no 2.x published, six weeks past the migration deadline. — PyPI (mcp) + npm registry (@modelcontextprotocol/sdk) (2026)
  • python-sdk v2.2.0 restricts HTTP client redirects to the endpoint's own origin (scheme, host, port): a cross-origin redirect now fails with MCPError — the SSRF class that powered the Hugging Face agent escapes is closed at library level. — modelcontextprotocol/python-sdk release v2.2.0 (#3397) (2026)
  • The hardening is not 2.x-exclusive: a v1.30.0 backport published the same day carries the same origin-binding rule (#3448) — but issuer validation on the legacy auth path and the new session controls ship only in 2.x. — modelcontextprotocol/python-sdk release v1.30.0 (2026-09-07) (2026)
  • v2.2.0 adds operational guardrails: idle stateful Streamable-HTTP sessions expire after 30 minutes and servers cap at 10,000 concurrent sessions — configurable, and neither affects stateless or 2026-07-28-spec connections. — python-sdk v2.2.0 release notes (#3395) (2026)
  • September 23, 2026 (15:45 UTC): the TypeScript line joined the v2 era — @modelcontextprotocol/server and @modelcontextprotocol/node both shipped 2.1.0, matching the PyPI 2.2.0-era pattern, so the stateless-first server API now exists on both main SDK families. — npm registry (2026)

All statistics come from verified third-party sources. Source, year, and direct link are shown on each metric.

When to Choose Each Option

Clear guidance based on your specific situation and needs.

Our Recommendation

Four days after the deadline the picture has changed twice over. The specification is final: the 2026-07-28 tag went non-prerelease at 16:47 UTC on July 28, so the governance objection to cutting over is gone. PyPI followed the same day — pip install mcp now resolves to 2.0.0 (uploaded 13:45 UTC on July 28), not the 1.28.1 that was still current on deadline morning. What has not moved is the core TypeScript SDK: @modelcontextprotocol/sdk is still 1.30.0, published 2026-07-27T17:56 UTC, and counting. So the split is no longer TypeScript versus Python; it is server packages and Python versus the one core TypeScript package that almost every custom client imports. Choose v2 Stateless now if you build MCP servers in TypeScript (the scoped @modelcontextprotocol/server, /node and /hono packages are 2.0.0 stable) or in Python, and if you need horizontal scaling without sticky sessions, restart-safe routing and clean serverless execution. Stay on v1 Stateful where you depend on @modelcontextprotocol/sdk itself — client code and anything built on the core SDK has no 2.x to install — or where your clients and adapters are untested against a stateless server. Pin either way: four scoped npm packages and PyPI's mcp all now resolve latest to 2.0.0, so an unpinned install crosses a major version by itself. And nothing broke on July 28: the Roots, Sampling and Logging deprecations are annotation-only for at least a year, so migrate deliberately, package by package. September 2026 makes the asymmetry operational: with 2.2.0 plus the v1.30.0 backport landing the same day, redirect containment became table stakes on both lines — but issuer validation, token-resource checks and session controls are 2.x-only. The v1 line now demonstrably receives maintenance, not progression; if you were waiting for a reason to schedule the cutover, this is it. Snapshot 2026-09-23: with server and node both at 2.1.0, the 2.x line is the default on both package families — remaining 1.x pins now read as transitional debt rather than a stability anchor.

Choose MCP v2 Stateless when...
  • You ship MCP servers in TypeScript (@modelcontextprotocol/server 2.0.0) or in Python, where pip install mcp now resolves to 2.2.0
  • You need horizontal scaling without sticky sessions, or serverless and ephemeral hosting for remote tools
  • You can move session state into clients, databases or shared stores before cutover
  • Your governance required a final specification tag before cutover — the 2026-07-28 tag is now final, not a release candidate
Choose MCP v1 Stateful when...
  • Your code imports @modelcontextprotocol/sdk directly: it is still 1.30.0 and has no 2.x release to install
  • Your server logic still relies on long-lived sessions, or your clients and adapters are untested against a stateless server
  • You run pinned v1 infrastructure where an in-place major upgrade is riskier than the scaling headroom you would gain
  • Your rollout process requires client tooling and servers to sit on the same major version

Common questions about this comparison answered.

Frequently Asked Questions

(01)Did MCP v2 actually ship on July 28, 2026?
Yes, in stages, and most of it landed on the day itself. The scoped TypeScript server packages went 2.0.0 stable at 23:55 UTC on July 27; PyPI's mcp moved to 2.0.0 at 13:45 UTC on July 28; and the specification tag 2026-07-28 went non-prerelease at 16:47 UTC on July 28. The one piece still outstanding is the core TypeScript SDK, @modelcontextprotocol/sdk, which remains 1.30.0.
(02)Is MCP v2 production-ready today?
For servers, largely yes: the specification is final, the TypeScript server packages are 2.0.0 stable and Python installs 2.0.0 by default. The remaining gap is client-side and library-side — anything importing @modelcontextprotocol/sdk is still on 1.30.0. Pilot the server layer first and keep code that depends on the core SDK pinned.
(03)Should teams pin MCP dependencies now?
More urgently than on deadline day. The latest tag now resolves to 2.0.0 on four scoped npm packages and on PyPI's mcp, so an unpinned install crosses a major version by itself. The maintainers report that 84% of the 10,000+ PyPI packages depending on mcp declare no upper bound — that population is now exposed in practice, not in theory.
(04)What is @modelcontextprotocol/server-legacy for?
It is the named v1 escape hatch, and it shipped already deprecated: frozen v1 SSE transport plus OAuth Authorization Server helpers, published with the instruction to use StreamableHTTP and a dedicated OAuth server in production. Use it to keep a v1 server running while you migrate — not as a destination.
(05)Does stateless MCP mean the application cannot keep state?
No. Stateless means the protocol server should not depend on a long-lived session to answer a request. Your application can still keep state, but it should live in the client, a database, a cache or another explicit persistence layer.
(06)Who should move first to MCP v2?
Teams running remote MCP server infrastructure at scale, in either TypeScript or Python: they gain ordinary load balancing, stateless routing and clearer authorization, and both languages now have a stable 2.0.0. Teams whose code imports the core TypeScript SDK should wait for its 2.x, because there is nothing yet to install.
(07)What does the 7 September SDK hardening release change for this decision?
It ends the waiting phase on both lines. mcp 2.2.0 and the v1.30.0 backport landed the same day, so redirect containment is now standard everywhere — but issuer validation, token-resource checks and session controls arrive only in 2.x. Staying on v1 means taking fixes late and missing controls entirely, which quietly strengthens the case for cutover even at conservative shops.

Need help deciding?

Book a free 30-minute consultation and we'll help you determine the best approach for your specific project.

Book Free ConsultationEmail Us

Free consultation · No obligation · Personal reply