--- type: Blog Post title: "MCP v2 Beta ist da: Die zustandslose Migration beginnt" description: "MCP v2 Beta bringt eine zustandslose Architektur. Was bricht, welche SDK-Pakete Sie anpinnen und wie Sie vor der Spezifikation am 28. Juli 2026 migrieren." resource: "https://www.contextstudios.ai/de/blog/mcp-v2-beta-zustandslose-migration" tags: [MCP, Migration, SDK, Architektur, KI-Agenten] language: de timestamp: "2026-07-02T07:33:59.250Z" --- # MCP v2 Beta ist da: Die zustandslose Migration beginnt
Ende Juni 2026 sind die ersten Beta-Versionen von Model Context Protocol v2 erschienen, und sie bringen die größte architektonische Änderung mit, die das Protokoll je erlebt hat: MCP wechselt von zustandsbehafteten, langlebigen Sitzungen zu einem zustandslosen Modell aus Anfrage und Antwort. Jeder bestehende Server muss migriert werden, bevor die Spezifikation vom 28. Juli 2026 in Kraft tritt.
Wer heute irgendetwas auf MCP aufsetzt, sollte diese Umstellung jetzt einplanen und nicht erst, wenn die Spezifikation endgültig ist. Das Python-SDK hat als mcp 2.0.0b1 den Beta-Status erreicht, das TypeScript-SDK unter völlig neuen Paketnamen (Python-SDK-Repository, TypeScript-SDK-Repository). Wir betreiben selbst einen MCP-Server im Produktivbetrieb mit einer großen Werkzeugoberfläche, deshalb steht diese Migration auch bei uns auf dem Plan. Im Folgenden lesen Sie, was sich konkret ändert, was dabei zerbricht und in welcher Reihenfolge Sie die Arbeit vor dem Stichtag angehen. Was „zustandslos“ für MCP v2 wirklich bedeutet
Die zentrale Änderung in MCP v2 besteht darin, dass das Protokoll auf der Transportebene zustandslos wird: Jede Anfrage steht für sich allein, sodass jede beliebige Serverinstanz jede Anfrage ohne gemeinsam genutzte Sitzung beantworten kann.
In Version 1 öffnete ein Client eine langlebige, bidirektionale Sitzung, häufig einen SSE-Kanal, und der Server vergab eine Sitzungskennung, die nachfolgende Anfragen wiederverwenden mussten. Dieses Design ging davon aus, dass ein Client für die gesamte Dauer eines Gesprächs an einen einzigen Serverprozess gebunden bleibt. MCP v2 verabschiedet sich von dieser Annahme. MCP wurde von Anthropic als zustandsbehaftetes, sitzungsorientiertes Protokoll eingeführt, und diese Form funktionierte für einzelne Desktop-Clients gut. Sobald man jedoch horizontal skalieren möchte, altert sie schlecht. Der offizielle Release Candidate der Spezifikation beschreibt die Umstellung auf Zustandslosigkeit als „die Art grundlegender Änderung, die einen sauberen Bruch verlangte“ (MCP-Blog). Sitzungen, klebrige Weiterleitung und gemeinsam genutzte Sitzungsspeicher verlieren damit ihre tragende Rolle (Leitfaden zur Vorbereitung). Vereinfacht gesagt: Eine Anfrage trägt alles in sich, was der Server benötigt, und der Server behält zwischen den Aufrufen nichts. Das ist der Kern der Sache, und jede weitere Entscheidung folgt daraus. Damit setzt sich der Faden fort, den wir schon beim Erscheinen der Alpha aufgenommen haben, nachzulesen in unserer früheren Einordnung zum Protokollwechsel am 28. Juli. Mit der Beta wird aus Planung terminierte Arbeit. Die Versionen, zu denen Sie tatsächlich migrieren
MCP v2 Beta steht für konkrete Pakete: Das Python-SDK erscheint als mcp 2.0.0b1 auf PyPI, das TypeScript-SDK unter zwei neuen Paketnamen als 2.0.0-beta.1, getrennt vom v1-Paket, das auf seiner 1.x-Linie bleibt.
Auf der Python-Seite führt PyPI nun mcp 2.0.0b1 als optionale Vorabversion, während die stabile v1-Linie bei 1.28.x liegt (PyPI mcp). Das Repository hält fest, dass v2 „eine umfassende Überarbeitung des SDK“ sei, sowohl zur Unterstützung der Spezifikation vom 28. Juli 2026 als auch zur Behebung langjähriger architektonischer Probleme; die stabile v2 ist für den 27. Juli 2026 vorgesehen (Python-SDK-Repository). Bei TypeScript lauert eine Falle, auf die man deutlich hinweisen muss. v2 erscheint nicht als neue Version von @modelcontextprotocol/sdk. Auf npm erscheint es als zwei völlig neue Pakete, @modelcontextprotocol/server und @modelcontextprotocol/client, beide als 2.0.0-beta.1, während das alte Paket auf v1 verbleibt (TypeScript-SDK-Repository). Wer als Aktualisierungsplan nur „die Versionsnummer anheben“ vorsieht, verpasst die Migration vollständig. Es handelt sich um eine geänderte Paketbenennung, nicht um einen bloßen Versionssprung. Abhängigkeitsprüfer, die allein @modelcontextprotocol/sdk beobachten, melden Sie als aktuell, obwohl Sie in Wahrheit eine ganze Hauptversion zurückliegen. Wer abwägt, wie viel Aufwand ein Wechsel einer Abhängigkeit rechtfertigt, sollte dies gemeinsam mit unserer Betrachtung zu den Opportunitätskosten von Rechenleistung lesen. Was in der Praxis zerbricht
Am häufigsten zerbricht bei einer MCP-v2-Migration die Infrastruktur rund um Sitzungsbindung: klebrige Lastverteiler, an SSE gebundene Clients und jeder Code, der Zustand pro Sitzung auf dem Server ablegte.
Am anschaulichsten zeigt sich das an einem Test mit dem Lastverteiler: Richtet man einen zustandsbehafteten v1-Client auf einen Reverse-Proxy mit Rundlauf-Verteilung über zwei Serverinstanzen, so eröffnet der Client eine Sitzung auf Instanz A, während die Folgeanfrage bei Instanz B landet, die von dieser Sitzung nichts weiß (Analyse zur Zustandslosigkeit). In Version 1 kaschierte man das mit klebriger Weiterleitung. In Version 2 verschwindet das Problem, weil es keine Sitzung mehr gibt, die stranden könnte, allerdings erst, wenn Sie den Code entfernt haben, der eine solche erwartete. Konkret sollten Sie vier Stellen anfassen: die Einrichtung des Transports, bei der die Annahme einer langlebigen SSE-Sitzung wegfällt, jeden serverseitigen Sitzungsspeicher, die Regeln zur klebrigen Weiterleitung in Ihrem Lastverteiler oder Gateway sowie die Logik zur Wiederverbindung im Client, die einen dauerhaften Kanal voraussetzte. Hinzu kommt eine sicherheitsrelevante Seite: Die neue Spezifikation eröffnet nach einer Analyse drei neue Angriffsflächen, wobei das Prüffenster bereits seit dem 21. Mai geöffnet ist (Backslash Security). Zustandslosigkeit verlagert Vertrauensentscheidungen auf jede einzelne Anfrage, weshalb die Autorisierung pro Anfrage wichtiger wird als bisher. Wenn Sie Ihre Werkzeugoberfläche länger nicht überprüft haben, verbinden Sie diese Migration mit einer gründlichen Prüfung Ihrer Werkzeuge und Fähigkeiten sowie der umfassenderen Checkliste zur Absicherung der Lieferkette. Wie Sie die Migration bis zum 28. Juli sinnvoll takten
Behandeln Sie MCP v2 als Migrationsplanung, nicht als endgültige Anleitung: Die SDKs sind Vorabversionen, ihre Schnittstellen können sich vor der stabilen Fassung vom 28. Juli 2026 noch ändern, weshalb es klüger ist, jetzt zu planen und zu erproben, statt bereits gegen die Beta auszuliefern.
Eine sinnvolle Reihenfolge sieht so aus: Erfassen Sie zuerst jede Stelle, an der Ihr System eine dauerhafte MCP-Sitzung voraussetzt, denn diese Bestandsaufnahme ist das eigentliche Ergebnis dieses Monats. Verankern Sie zweitens die Beta ausdrücklich in einem Zweig (mcp==2.0.0b1 für Python, die neuen Pakete @modelcontextprotocol/server und /client für TypeScript) und stellen Sie einen Prototyp-Server auf, ohne den Produktivbetrieb anzurühren. Prüfen Sie drittens mit dem oben beschriebenen Lastverteiler-Test, ob Ihre Anfragen es überstehen, über mehrere Instanzen verteilt zu werden. Verlagern Sie viertens die Autorisierung pro Anfrage in den Anfragepfad. Wie sieht diese Bestandsaufnahme konkret aus? Durchsuchen Sie Ihren Quellcode und Ihre Infrastruktur nach einigen verräterischen Mustern: jeder Verweis darauf, dass eine Sitzungskennung gespeichert oder wiederverwendet wird, jeder SSE-Endpunkt, den Ihr MCP-Transport öffnet, jede Regel im Lastverteiler, die einen Client an ein Backend bindet, und jede Annahme, dass zwei aufeinanderfolgende Werkzeugaufrufe denselben Prozess treffen. Jeder Treffer ist ein Posten auf Ihrem Migrationsplan. Die meisten Teams überrascht, wie viel davon in der Infrastrukturkonfiguration steckt und nicht im Anwendungscode, denn im Lastverteiler und im Gateway sammeln sich die zustandsbehafteten Annahmen still an, und genau deshalb schlägt eine Bestandsaufnahme das blinde Umschreiben. Da es sich um optionale Vorabversionen handelt, weisen die Verantwortlichen der Spezifikation ausdrücklich darauf hin, dass sich Schnittstellen vor der allgemeinen Verfügbarkeit noch verschieben können (Versionsdaten von libraries.io). Verstehen Sie die Beta als Generalprobe. Die Zeichen der Reife stimmen zuversichtlich, denn das Ökosystem behandelt diesen Schritt als den Moment, in dem MCP „erwachsen wird“, mit ernsthafter Arbeit an Konformität und neutraler Steuerung (AAIF), doch die Disziplin einer Generalprobe gilt weiterhin. Behalten Sie eine v1-Rückfallebene, bis die stabilen SDKs erscheinen, so wie eine modellunabhängige Haltung Sie davor schützt, dass eine einzelne Abhängigkeit aus dem Ruder läuft. Der Gewinn, wenn die Arbeit getan ist
Zustandslosigkeit macht MCP-Server erheblich einfacher skalierbar und betreibbar: Jede Instanz kann jede Anfrage bedienen, sodass Sie nach abgeschlossener Migration horizontale Skalierung, einfachere Auslieferungen und günstigere Fehlererholung gewissermaßen geschenkt bekommen.
Man sollte deutlich sagen, dass sich diese Migration auszahlt. Ein zustandsbehafteter Server ist unter Last eine Bürde, weil er klebrige Weiterleitung, einen gemeinsamen Sitzungsspeicher und eine sorgfältige Behandlung von Wiederverbindungen verlangt, und jeder dieser Bausteine kann für sich genommen ausfallen. Ein zustandsloser Server streicht diese gesamte Klasse von Problemen. Sie können auf null herunterskalieren und wieder hinauf, Instanzen während einer Auslieferung austauschen, ohne Sitzungen leerlaufen zu lassen, und einen schlichten Rundlauf-Verteiler vor die Serverflotte setzen. Wer Agenten-Lasten in großem Umfang betreibt, für den ist diese betriebliche Einfachheit der eigentliche Gewinn und nicht bloß die Einhaltung der Spezifikation. Bei Context Studios behandeln wir Verfügbarkeit als gleichrangige Entwurfsgröße neben Leistungsfähigkeit und Kosten, und ein zustandsloser Transport ist genau die Art Änderung, die alle drei zugleich verbessert. Weniger bewegliche Teile bedeuten weniger Fehlerquellen, und weniger Fehlerquellen bedeuten einen Agenten-Stapel, dem Sie im Produktivbetrieb wirklich vertrauen können. Die Kosten der Migration sind real, doch es sind einmalige Kosten, die ein wiederkehrendes Betriebsrisiko abbauen, und das ist der beste Handel, den ein Entwicklerteam eingehen kann. Warum der Zeitpunkt nicht verhandelbar ist
Der 28. Juli 2026 ist ein harter Stichtag, weil an diesem Tag die MCP-Spezifikation endgültig wird und die stabilen v2-SDKs erscheinen sollen, und ab diesem Moment beschleunigt sich die Verbreitung im Ökosystem, während Annahmen aus Version 1 zu veralten beginnen.
Die Spezifikation und die stabilen SDKs liegen kaum einen Tag auseinander: die Spezifikation am 28. Juli 2026, die stabile Python-v2 vorgesehen für den 27. Juli 2026 (Python-SDK-Repository). Sobald die SDKs der ersten Reihe die Unterstützung ausliefern, verstärkt sich die Verbreitung von selbst, und Server, die weiterhin von zustandsbehafteten Sitzungen ausgehen, fallen zunehmend aus dem Rahmen (offizielle MCP-Dokumentation). Das offizielle Repository der Spezifikation ist die maßgebliche Quelle, die Sie im Blick behalten sollten, während der Termin näher rückt (MCP-Spezifikations-Repository). Vorn liegen am Ende die Teams, die im Juli ihre Bestandsaufnahme gemacht, gegen die Beta einen Prototyp gebaut und in der Woche des stabilen SDK umgeschaltet haben, und nicht jene, die im August die geänderte Paketbenennung entdecken. Häufig gestellte Fragen Ist MCP v2 schon verfügbar? Ja, als Beta-Vorabversionen. Das Python-SDK ist mcp 2.0.0b1 auf PyPI, das TypeScript-SDK liegt als 2.0.0-beta.1 unter neuen Paketnamen vor. Beide sind optional; die stabile v2 ist für den 27. Juli 2026 vorgesehen (Python-SDK-Repository). Was ist die größte einzelne Änderung in MCP v2? Das Protokoll wird zustandslos: Anfragen sind in sich abgeschlossen, und jede beliebige Serverinstanz kann jede Anfrage bearbeiten, was das langlebige, sitzungsgebundene Modell aus Version 1 ablöst (MCP-Blog). Muss ich meinen MCP-Server selbst migrieren? Letztlich ja, denn jeder zustandsbehaftete Server muss migriert werden. Heute müssen Sie es noch nicht, doch die Wochen vor dem 28. Juli 2026 sind der richtige Zeitpunkt, um Sitzungsannahmen zu erfassen und einen Prototyp zu bauen (Backslash Security). Warum hat sich der TypeScript-Paketname geändert? v2 erscheint als @modelcontextprotocol/server und @modelcontextprotocol/client statt als neue Version des v1-Pakets @modelcontextprotocol/sdk, sodass ein bloßer Versionssprung Sie nicht aktualisiert (TypeScript-SDK-Repository). Das Fazit Die zustandslose Migration von MCP v2 ist jene seltene bruchhafte Änderung, die Ihre Infrastruktur nach getaner Arbeit einfacher macht: keine klebrigen Sitzungen mehr, keine gemeinsamen Sitzungsspeicher, jede Instanz beantwortet jede Anfrage. „Einfacher danach“ tritt allerdings nur ein, wenn Sie die Bestandsaufnahme erledigen, bevor die Spezifikation am 28. Juli 2026 in Kraft tritt. Kartieren Sie Ihre Sitzungsannahmen, bauen Sie einen Prototyp gegen die Beta und behalten Sie eine v1-Rückfallebene, bis die stabilen SDKs erscheinen. Wenn Sie einen zweiten Blick auf Ihren MCP-Migrationsplan wünschen oder einen produktionsreifen Server nach der Spezifikation vom 28. Juli 2026 brauchen, ist genau das unsere Arbeit. Quellen 1. Model Context Protocol – Release Candidate vom 28. Juli 2026: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate 2. Offizielles Python-SDK-Repository: https://github.com/modelcontextprotocol/python-sdk 3. Offizielles TypeScript-SDK-Repository: https://github.com/modelcontextprotocol/typescript-sdk 4. PyPI – mcp-Paket: https://pypi.org/project/mcp/ 5. Offizielles Repository der MCP-Spezifikation: https://github.com/modelcontextprotocol/modelcontextprotocol 6. Offizielle MCP-Dokumentation: https://modelcontextprotocol.io 7. Backslash Security – neue Angriffsflächen der MCP-Spezifikation: https://www.backslash.security/blog/new-mcp-spec-opens-new-attack-surfaces 8. Vorbereitung auf die kommenden MCP-Aktualisierungen: https://www.linkedin.com/pulse/preparing-upcoming-updates-model-context-protocol-mcp-amit-singh-zziye 9. Agentic AI Foundation – MCP wird erwachsen: https://aaif.io/blog/mcp-is-growing-up 10. libraries.io – Versionsdaten zu mcp: https://libraries.io/pypi/mcp