--- type: "Comparison" title: "MCP v2 zustandslos vs. MCP v1 zustandsbehaftet (2026): Python bei 2.2.0, Core-SDK weiterhin 1.30.0" description: "MCP v2 zustandslos vs. MCP v1 zustandsbehaftet, vier Tage nach dem Stichtag 28. Juli: Der Spezifikations-Tag ist final und PyPI mcp steht auf 2.0.0, doch @modelcontextprotocol/sdk bleibt bei 1.30.0. Skalierung, SDK-Stabilität, Autorisierung und Migrationsrisiko im Vergleich." resource: "https://www.contextstudios.ai/de/vergleich/mcp-v2-stateless-vs-mcp-v1-stateful" language: "de" tags: ["MCP v2", "MCP zustandslos", "MCP v1", "Model Context Protocol", "MCP Migration", "Python SDK v2"] generated: by: "process:contextstudios-md/1" at: "2026-10-08T22:20:25.390Z" status: "stable" --- # MCP v2 zustandslos vs. MCP v1 zustandsbehaftet (2026): Python bei 2.2.0, Core-SDK weiterhin 1.30.0 Der 28. Juli 2026 war der MCP-Migrationsstichtag — und die ehrliche Antwort hat sich innerhalb weniger Stunden danach geändert. Am 1. August erneut gegen die Registries geprüft: Der Tag 2026-07-28 im Spezifikations-Repository ist jetzt final (prerelease=false, veröffentlicht 2026-07-28T16:47:49Z), und PyPI hat mcp am selben Tag auf 2.0.0 gehoben. Damit sind beide Einwände, die den Stichtag geprägt haben — eine nur als RC getaggte Spezifikation und ein Python-Ökosystem auf 1.28.1 — hinfällig. Eine Lücke bleibt: das Core-TypeScript-SDK @modelcontextprotocol/sdk steht weiterhin auf 1.30.0 vom 27. Juli. MCP v2 verlagert den Protokollkern auf zustandsloses Request/Response und ergänzt Extensions, Tasks, MCP Apps, gehärtete Autorisierung und eine formale Deprecation-Policy. MCP v1 bleibt die gepflegte Basislinie — und wenn Ihr Code das Core-TypeScript-SDK importiert, weiterhin das Einzige, was Sie installieren können. Am 08.09.2026 erneut verifiziert: mcp auf PyPI steht jetzt auf 2.2.0 (plus v1.30.0-Backport am selben Tag), während @modelcontextprotocol/sdk seit sechs Wochen auf 1.30.0 in npm liegt. ## Detaillierter Vergleich | Faktor | MCP v2 zustandslos | MCP v1 zustandsbehaftet | Gewinner | |--------|------|------|--------| | Horizontale Skalierung | Jede Anfrage kann an eine passende Serverinstanz gehen, sobald der Anwendungszustand außerhalb des Protokollservers liegt | Langlebige Sitzungen und feste Verbindungen sind leichter zu verstehen, erschweren aber automatische Skalierung und Ausfälle | MCP v2 zustandslos | | SDK-Stabilität | In Etappen ausgeliefert: Die Scoped-Server-Pakete wurden am 27. Juli 2.0.0 stable, PyPI mcp folgte am 28. Juli — aber @modelcontextprotocol/sdk steht weiter auf 1.30.0. v2 ist überall installierbar außer im Core-TypeScript-Paket | Weiterhin das, was @modelcontextprotocol/sdk liefert, und für dieses Paket weiterhin die gepflegte Linie für Fehler- und Sicherheitsfixes | Unentschieden | | Serverlose und kurzlebige Umgebungen | Für kurze Anfrage-Antwort-Ausführung ausgelegt, sodass Muster mit Vercel, Cloud Run, Lambda-ähnlichen Diensten und Containern sauberer werden | Funktioniert am besten, wenn ein Prozess Sitzungskontext halten kann; serverlos möglich, aber im Betrieb sperriger | MCP v2 zustandslos | | Umgang mit Zustand | Zwingt Zustand in explizite Client-Kontexte, gemeinsame Speicher oder Anwendungsdatenbanken; sauberer, aber mit Umbauaufwand | Erlaubt Servercode, Sitzungsannahmen bequem im Speicher zu halten, was für kleine interne Werkzeuge praktisch ist | Unentschieden | | Ökosystem-Kompatibilität heute | Die Spezifikation ist final, und sowohl die TypeScript-Serverfläche als auch Python sind auf 2.0.0 installierbar — ein mehrsprachiger Stack kann sich jetzt fast als Einheit bewegen | Die meisten Beispiele, Pakete und internen Server setzen weiterhin v1-Verhalten voraus, und wer das Core-TypeScript-SDK importiert, hat keine Alternative | MCP v2 zustandslos | | Autorisierung und Governance | Die finale Spezifikation 2026-07-28 verlangt OAuth 2.0 Protected Resource Metadata (RFC 9728), um den Ort des Autorisierungsservers anzuzeigen, und verankert eine formale Deprecation-Policy in der Protokoll-Roadmap | Autorisierung lässt sich am Gateway steuern, doch die Protokolllinie ist älter und beim neuen Modell weniger explizit | MCP v2 zustandslos | | Migrationsrisiko | Verteilt sich jetzt auf beide Registries: Ein ungepinnter Install kann bei vier Scoped-npm-Paketen und bei pip install mcp ungefragt auf 2.0.0 springen — Versionsgrenzen und Paralleltests sind Pflicht | Gering, wenn Sie pinnen — aber das Risiko ist jetzt auf npm und PyPI real, nicht mehr nur auf npm | MCP v1 zustandsbehaftet | | Zukunftssicherheit | Ausgerichtet auf eine Spezifikation, die jetzt final ist statt Release Candidate; die Server-Pakete und Python sind bereits da, das Core-SDK ist das einzige Stück, das noch folgen muss | Eine Kompatibilitätsbasis mit benannter Notausfahrt (server-legacy) — die allerdings bereits als deprecated ausgeliefert wurde | MCP v2 zustandslos | | Sicherheitshärtung (September 2026) | 2.x ist die Härtungslinie: origin-gebundene Redirects seit 2.2.0, Issuer-Prüfung des Autorisierungsservers auf jedem OAuth-Pfad, opt-in Token-Resource-Validierung, Sitzungs-Timeouts — die Containment-Lehren der Agenten-SSRF-Vorfälle, geliefert im Client selbst | v1.30.0 backportet nur die Redirect-Origin-Bindung; Issuer-Prüfung auf dem Legacy-Pfad und die neuen Auth-/Sitzungskontrollen bleiben draußen. Die 1.x-Linie erhält nachweislich Wartung, keine Weiterentwicklung | MCP v2 zustandslos | ## Wichtige Statistiken - **Die MCP-Server-Pakete — @modelcontextprotocol/server, /node, /hono und /server-legacy — haben ihre erste stabile Version 2.0.0 am 27.07.2026 um 23:55 UTC veröffentlicht, fünf Minuten vor dem Stichtag, nach vier Alphas und fünf Betas.** — [npm registry (@modelcontextprotocol/server)](https://www.npmjs.com/package/@modelcontextprotocol/server) (2026) - **Der Spezifikations-Tag 2026-07-28 ist final: GitHub meldet prerelease=false, veröffentlicht 2026-07-28T16:47:49Z — die erste finale MCP-Spezifikation seit 2025-11-25.** — [modelcontextprotocol/modelcontextprotocol GitHub Releases](https://github.com/modelcontextprotocol/modelcontextprotocol/releases) (2026) - **Das Core-TypeScript-SDK hat weiterhin kein 2.x: @modelcontextprotocol/sdk steht bei latest auf 1.30.0, veröffentlicht 2026-07-27 um 17:56 UTC — es bewegte sich nicht, als Server-Pakete, PyPI und Spezifikation final wurden.** — [npm registry (@modelcontextprotocol/sdk)](https://www.npmjs.com/package/@modelcontextprotocol/sdk) (2026) - **PyPIs mcp ging am 2026-07-28T13:45:28Z auf 2.0.0 und löste die am 2026-06-26 veröffentlichte 1.28.1 ab — ein einfaches pip install mcp installiert jetzt v2.** — [PyPI (mcp)](https://pypi.org/project/mcp/) (2026) - **Der v1-Notausgang wurde bereits als veraltet ausgeliefert: server-legacy ist beschrieben als „eingefrorener v1-SSE-Transport und OAuth-Authorization-Server-Helfer… Veraltet; verwenden Sie StreamableHTTP und einen dedizierten OAuth-Server in der Produktion.“** — [npm registry (@modelcontextprotocol/server-legacy)](https://www.npmjs.com/package/@modelcontextprotocol/server-legacy) (2026) - **Laut den Maintainern deklarieren 84 % von mehr als 10.000 PyPI-Paketen, die von mcp abhängen, keine Obergrenze — eine ungepinnte Installation kann also ein brechendes v2-Pre-Release ziehen.** — [modelcontextprotocol/python-sdk GitHub](https://github.com/modelcontextprotocol/python-sdk) (2026) - **Die Abkündigungen von Roots, Sampling und Logging zum 28. Juli sind reine Annotationen: Diese Methoden, Typen und Capability-Flags funktionieren in diesem Release und in jeder innerhalb eines Jahres veröffentlichten Spezifikationsversion weiter — bestehende v1-Server brechen am 28. Juli also nicht.** — [Model Context Protocol Blog](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) (2026) - **MCP-Server MÜSSEN OAuth 2.0 Protected Resource Metadata (RFC 9728) implementieren, um den Ort ihres Authorization-Servers bekanntzugeben; der RC vom 28.07.2026 erlaubt servergesteuerte Anfragen zusätzlich nur noch, während der Server aktiv eine Client-Anfrage bearbeitet (SEP-2260).** — [Model Context Protocol Authorization Spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) (2026) - **Die Python-SDK-Linie ist am 07.09.2026 auf PyPI bei 2.2.0 angekommen — vier Wochen nachdem 2.0.0 zum pip-Standard wurde — während @modelcontextprotocol/sdk auf npm weiterhin bei 1.30.0 steht, sechs Wochen nach dem Migrationsstichtag.** — [PyPI (mcp) + npm-Registry (@modelcontextprotocol/sdk)](https://pypi.org/pypi/mcp/) (2026) - **python-sdk v2.2.0 beschränkt HTTP-Client-Redirects auf die Origin des Endpunkts (Schema, Host, Port): ein Cross-Origin-Redirect schlägt jetzt mit MCPError fehl — die SSRF-Klasse der Hugging-Face-Agenten-Ausstiege ist auf Bibliotheksebene geschlossen.** — [modelcontextprotocol/python-sdk Release v2.2.0 (#3397)](https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0) (2026) - **Die Härtung ist kein 2.x-Vorrecht: Ein am selben Tag veröffentlichter v1.30.0-Backport trägt dieselbe Origin-Bindungsregel (#3448) — aber Issuer-Prüfung auf dem Legacy-Auth-Pfad und die neuen Sitzungskontrollen gibt es nur in 2.x.** — [modelcontextprotocol/python-sdk Release v1.30.0 (07.09.2026)](https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0) (2026) - **v2.2.0 ergänzt Betriebs-Leitplanken: Idle-stateful Streamable-HTTP-Sitzungen laufen nach 30 Minuten ab, Server kappen bei 10.000 gleichzeitigen Sitzungen — konfigurierbar, und weder stateless noch 2026-07-28-Kontexte betroffen.** — [python-sdk v2.2.0 Release Notes (#3395)](https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0) (2026) - **23.09.2026 (15:45 UTC): Die TypeScript-Linie ist in der v2-Ära angekommen — @modelcontextprotocol/server und @modelcontextprotocol/node liefern beide 2.1.0 und passen damit zum PyPI-Muster 2.2.0; die stateless-first Server-API existiert nun in beiden Haupt-SDK-Familien.** — [npm registry](https://www.npmjs.com/package/@modelcontextprotocol/server) (2026) ## Wählen Sie MCP v2 zustandslos, wenn... - @modelcontextprotocol/server 2.0.0) oder in Python aus, wo pip install mcp jetzt 2.2.0 liefert - Sie brauchen horizontale Skalierung ohne Sticky Sessions oder Serverless- und Ephemeral-Hosting für Remote-Tools - Sie können Session-State vor dem Umstieg in Clients, Datenbanken oder gemeinsame Stores verlagern - Ihre Governance verlangte vor dem Umstieg einen finalen Spezifikations-Tag — der Tag 2026-07-28 ist jetzt final, kein Release Candidate mehr ## Wählen Sie MCP v1 zustandsbehaftet, wenn... - Ihr Code importiert @modelcontextprotocol/sdk direkt: Es steht weiterhin auf 1.30.0, ein 2.x-Release existiert nicht - Ihre Serverlogik stützt sich weiterhin auf langlebige Sessions, oder Ihre Clients und Adapter sind nicht gegen einen zustandslosen Server getestet - Sie betreiben gepinnte v1-Infrastruktur, bei der ein Major-Upgrade im Bestand riskanter ist als der gewonnene Skalierungsspielraum - Ihr Rollout-Prozess verlangt, dass Client-Werkzeuge und Server auf derselben Major-Version stehen ## Unsere Empfehlung Vier Tage nach dem Stichtag hat sich das Bild gleich zweifach gedreht. Die Spezifikation ist final: Der Tag 2026-07-28 wurde am 28. Juli um 16:47 UTC auf non-prerelease gesetzt, der Governance-Einwand gegen einen Umstieg entfällt damit. PyPI zog am selben Tag nach — pip install mcp liefert jetzt 2.0.0 (hochgeladen am 28. Juli, 13:45 UTC) statt der 1.28.1, die am Morgen des Stichtags noch aktuell war. Nicht bewegt hat sich das Core-TypeScript-SDK: @modelcontextprotocol/sdk steht unverändert auf 1.30.0, veröffentlicht am 2026-07-27 um 17:56 UTC. Die Trennlinie verläuft also nicht mehr zwischen TypeScript und Python, sondern zwischen Server-Paketen plus Python auf der einen und dem einen Core-TypeScript-Paket auf der anderen Seite, das nahezu jeder eigene Client importiert. Wählen Sie jetzt v2 zustandslos, wenn Sie MCP-Server in TypeScript betreiben (die Scoped-Pakete @modelcontextprotocol/server, /node und /hono sind 2.0.0 stable) oder in Python, und wenn Sie horizontale Skalierung ohne Sticky Sessions, neustartsicheres Routing und saubere Serverless-Ausführung brauchen. Bleiben Sie bei v1 zustandsbehaftet, wo Sie direkt von @modelcontextprotocol/sdk abhängen — für Client-Code und alles, was auf dem Core-SDK aufsetzt, gibt es kein 2.x zu installieren — oder wo Ihre Clients und Adapter nicht gegen einen zustandslosen Server getestet sind. Pinnen Sie in jedem Fall: Vier Scoped-npm-Pakete und PyPIs mcp auflösen latest inzwischen auf 2.0.0, ein ungepinnter Install überschreitet also von selbst eine Major-Version. Und am 28. Juli ist nichts zerbrochen: Die Deprecations von Roots, Sampling und Logging sind mindestens ein Jahr lang reine Annotationen — migrieren Sie bewusst, Paket für Paket. Der September 2026 macht die Asymmetrie operativ: Mit 2.2.0 plus dem v1.30.0-Backport vom selben Tag ist Redirect-Containment auf beiden Linien Grundvoraussetzung — doch Issuer-Validierung, Token-Resource-Prüfung und Sitzungskontrollen bleiben 2.x-vorbehalten. Die v1-Linie erhält nachweislich nur noch Wartung, keine Weiterentwicklung; wer auf einen Grund für den Cutover gewartet hat, hat ihn jetzt. Stand 23.09.2026: Mit server und node jeweils auf 2.1.0 ist die 2.x-Linie in beiden Paket-Familien der Default — verbleibende 1.x-Pins sind nun Übergangs-Schuld statt Stabilitätsanker. ## Häufig gestellte Fragen **Q: Ist MCP v2 am 28. Juli 2026 wirklich erschienen?** A: Ja, in Etappen — und das meiste davon am Stichtag selbst. Die Scoped-TypeScript-Server-Pakete wurden am 27. Juli um 23:55 UTC 2.0.0 stable, PyPIs mcp ging am 28. Juli um 13:45 UTC auf 2.0.0, und der Spezifikations-Tag 2026-07-28 wurde am 28. Juli um 16:47 UTC auf non-prerelease gesetzt. Offen bleibt allein das Core-TypeScript-SDK @modelcontextprotocol/sdk, das auf 1.30.0 verharrt. **Q: Ist MCP v2 heute produktionsreif?** A: Für Server weitgehend ja: Die Spezifikation ist final, die TypeScript-Server-Pakete sind 2.0.0 stable, und Python installiert standardmäßig 2.0.0. Die verbleibende Lücke liegt auf Client- und Bibliotheksseite — alles, was @modelcontextprotocol/sdk importiert, steht noch auf 1.30.0. Pilotieren Sie zuerst die Serverschicht und halten Sie Code, der vom Core-SDK abhängt, gepinnt. **Q: Sollten Teams MCP-Abhängigkeiten jetzt pinnen?** A: Dringlicher als am Stichtag. Der latest-Tag löst inzwischen bei vier Scoped-npm-Paketen und bei PyPIs mcp auf 2.0.0 auf — ein ungepinnter Install überschreitet also von selbst eine Major-Version. Die Maintainer berichten, dass 84 % der über 10.000 PyPI-Pakete mit mcp-Abhängigkeit keine Obergrenze deklarieren; diese Population ist jetzt praktisch exponiert, nicht mehr nur theoretisch. **Q: Wofür ist @modelcontextprotocol/server-legacy gedacht?** A: Es ist der benannte v1-Notausgang — und er wurde bereits als veraltet ausgeliefert: eingefrorener v1-SSE-Transport plus OAuth-Authorization-Server-Helfer, veröffentlicht mit dem Hinweis, in der Produktion StreamableHTTP und einen dedizierten OAuth-Server zu verwenden. Nutzen Sie ihn, um einen v1-Server während der Migration weiterlaufen zu lassen — nicht als Ziel. **Q: Bedeutet zustandsloses MCP, dass die Anwendung keinen Zustand halten kann?** A: Nein. Zustandslos heißt, dass der Protokollserver für die Beantwortung einer Anfrage nicht auf eine langlebige Sitzung angewiesen sein soll. Ihre Anwendung darf weiterhin Zustand halten — er gehört aber in den Client, eine Datenbank, einen Cache oder eine andere explizite Persistenzschicht. **Q: Wer sollte zuerst auf MCP v2 wechseln?** A: Teams, die entfernte MCP-Serverinfrastruktur im größeren Maßstab betreiben — in TypeScript wie in Python. Sie gewinnen gewöhnliches Load Balancing, zustandsloses Routing und klarere Autorisierung, und beide Sprachen haben jetzt ein stabiles 2.0.0. Teams, deren Code das Core-TypeScript-SDK importiert, sollten dessen 2.x abwarten, weil es schlicht nichts zu installieren gibt. **Q: Was ändert das Härtungs-Release der SDKs am 7. September an dieser Entscheidung?** A: Es beendet die Wartephase auf beiden Linien. mcp 2.2.0 und der v1.30.0-Backport kamen am selben Tag, damit ist Redirect-Containment überall Standard — aber Issuer-Validierung, Token-Resource-Prüfung und Sitzungskontrollen gibt es nur in 2.x. Auf v1 zu bleiben heißt, Fixes spät zu bekommen und Kontrollen ganz zu verpassen — das stärkt das Cutover-Argument auch für konservative Teams.