DE
Gespräch buchen

Technologie

MCP v2 zustandslos vs. MCP v1 zustandsbehaftet (2026): Python bei 2.2.0, Core-SDK weiterhin 1.30.0

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.

Geprüft von Michael Kerkhoff, Stand

Definition
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.
Kategorie
Technologie
Optionen
MCP v2 zustandslosMCP v1 zustandsbehaftet

Detaillierter Vergleich

Eine Gegenüberstellung der wichtigsten Faktoren für Ihre Entscheidung.

MCP v2 zustandslos vs MCP v1 zustandsbehaftet
FaktorMCP v2 zustandslosMCP v1 zustandsbehaftet
Horizontale SkalierungJede Anfrage kann an eine passende Serverinstanz gehen, sobald der Anwendungszustand außerhalb des Protokollservers liegt GewinnerLanglebige Sitzungen und feste Verbindungen sind leichter zu verstehen, erschweren aber automatische Skalierung und Ausfälle
SDK-StabilitätIn 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-PaketWeiterhin das, was @modelcontextprotocol/sdk liefert, und für dieses Paket weiterhin die gepflegte Linie für Fehler- und Sicherheitsfixes
Serverlose und kurzlebige UmgebungenFür kurze Anfrage-Antwort-Ausführung ausgelegt, sodass Muster mit Vercel, Cloud Run, Lambda-ähnlichen Diensten und Containern sauberer werden GewinnerFunktioniert am besten, wenn ein Prozess Sitzungskontext halten kann; serverlos möglich, aber im Betrieb sperriger
Umgang mit ZustandZwingt Zustand in explizite Client-Kontexte, gemeinsame Speicher oder Anwendungsdatenbanken; sauberer, aber mit UmbauaufwandErlaubt Servercode, Sitzungsannahmen bequem im Speicher zu halten, was für kleine interne Werkzeuge praktisch ist
Ökosystem-Kompatibilität heuteDie 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 GewinnerDie meisten Beispiele, Pakete und internen Server setzen weiterhin v1-Verhalten voraus, und wer das Core-TypeScript-SDK importiert, hat keine Alternative
Autorisierung und GovernanceDie 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 GewinnerAutorisierung lässt sich am Gateway steuern, doch die Protokolllinie ist älter und beim neuen Modell weniger explizit
MigrationsrisikoVerteilt 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 PflichtGering, wenn Sie pinnen — aber das Risiko ist jetzt auf npm und PyPI real, nicht mehr nur auf npm Gewinner
ZukunftssicherheitAusgerichtet 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 GewinnerEine Kompatibilitätsbasis mit benannter Notausfahrt (server-legacy) — die allerdings bereits als deprecated ausgeliefert wurde
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 Gewinnerv1.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
Gesamtpunktzahl · 2 unentschieden6 / 91 / 9

Wichtige Statistiken

Echte Daten aus verifizierten Branchenquellen zur Unterstützung Ihrer Entscheidung.

  • 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) (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 (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) (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) (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) (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 (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 (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 (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) (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) (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) (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) (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 (2026)

Alle Statistiken stammen aus verifizierten Drittquellen. Quelle, Jahr und Original-Link werden direkt bei jeder Kennzahl angezeigt.

Wann Sie welche Option wählen sollten

Klare Orientierung basierend auf Ihrer spezifischen Situation und Ihren Bedürfnissen.

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.

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

Häufige Fragen zu diesem Vergleich beantwortet.

Häufig gestellte Fragen

(01)Ist MCP v2 am 28. Juli 2026 wirklich erschienen?
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.
(02)Ist MCP v2 heute produktionsreif?
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.
(03)Sollten Teams MCP-Abhängigkeiten jetzt pinnen?
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.
(04)Wofür ist @modelcontextprotocol/server-legacy gedacht?
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.
(05)Bedeutet zustandsloses MCP, dass die Anwendung keinen Zustand halten kann?
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.
(06)Wer sollte zuerst auf MCP v2 wechseln?
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.
(07)Was ändert das Härtungs-Release der SDKs am 7. September an dieser Entscheidung?
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.

Brauchen Sie Hilfe bei der Entscheidung?

Buchen Sie ein kostenloses 30-minütiges Beratungsgespräch und wir helfen Ihnen, den besten Ansatz für Ihr Projekt zu bestimmen.

Kostenloses BeratungsgesprächE-Mail senden

Kostenlose Beratung · Unverbindlich · Persönliche Antwort