MCP Python SDK 2.0: Warum ein Dependency-Update jetzt zum Protokoll-Migrationsprojekt wird

Die stabile Version 2.0 des offiziellen MCP Python SDKs ist da — und sie ist kein normales Paket-Update. Seit dem Release vom 28. Juli installiert pip install mcp die 2.x-Linie. Wer seine Abhängigkeit bislang nicht nach oben begrenzt hat, kann damit direkt in eine Protokoll- und API-Migration laufen.

Der entscheidende Punkt: v2 implementiert die MCP-Revision vom 28. Juli 2026, bedient aber weiterhin Clients der älteren 2025er-Ära vom selben Server. Das ist ein sinnvoller Kompatibilitätsschritt für Server-Betreiber. Für Python-Code rund um Server, Clients, Imports und OAuth ist der Versionssprung dennoch bewusst einschneidend.

Was sich im Betrieb ändert

• Neue API-Oberfläche: FastMCP heißt nun MCPServer. Ein eigenständiges Client(target)-Objekt ersetzt das bisherige Zusammenspiel aus Transport, ClientSession und explizitem initialize().
• Neue Protokollära, ein Server: Die 2026-07-28-Revision arbeitet mit zustandslosen Requests ohne Handshake; gleichzeitig soll derselbe MCPServer ältere Clients über Streamable HTTP und stdio bedienen.
• Interaktion während Tool-Aufrufen wird umgebaut: Weil der Server in der neuen Revision den Client nicht mehr initiativ aufruft, nutzt v2 Multi-Round-Trip-Requests und Resolve(fn) für Rückfragen bzw. Dependency Injection.
• Imports und Typen ändern sich: Die Protokolltypen liegen jetzt im separat veröffentlichten Paket mcp-types (Import: mcp_types); die Migrationsdokumentation führt die inkompatiblen Umstellungen auf.
• Mehr Defaults mit Betriebswirkung: OpenTelemetry-Tracing ist standardmäßig aktiv. Bei stdio-Servern wird stdout zum Schutz des Protokollkanals nach stderr umgeleitet. Streamable-HTTP-Server weisen Bodies über 4 MiB mit HTTP 413 zurück.

„v1.x is in maintenance mode and will only receive security fixes from now on.“

— MCP Python SDK v2.0.0 Release

Warum das jetzt eine Dependency-Frage ist

Der Release macht den Upgrade-Pfad ungewöhnlich klar: Wer noch nicht migrieren kann, soll eine obere Versionsgrenze setzen. Das ist keine kosmetische Empfehlung. Ohne Constraint kann ein frischer Build, ein erneuertes Lockfile oder ein neues Entwickler-Environment unvermittelt 2.x auflösen.

# Bis die Anwendung gegen v2 getestet und migriert ist
mcp >= 1.28, < 2

Für Teams mit MCP-Servern bedeutet das: Dependency-Manifest und Lockfile prüfen, dann Tests gegen die betroffenen stdio- und Streamable-HTTP-Pfade laufen lassen. Besonders wichtig sind eigene Imports von Protokolltypen, clientseitige Initialisierung, Tool-Flows mit Nutzer-Rückfragen und Observability-/Log-Pipelines. Das standardmäßig aktivierte Tracing gehört dabei in die Datenschutz- und Telemetrieprüfung, nicht nur in den Testlauf.

Die pragmatische Upgrade-Checkliste

1. Heute pinnen oder bewusst freigeben: Bestehende v1-Deployments auf mcp>=1.28,<2 begrenzen, falls kein sofortiges Upgrade vorgesehen ist.
2. Code-Migration isolieren: FastMCP/MCPServer, ClientSession/Client und mcp.types/mcp_types gezielt suchen.
3. Beide Transportwege testen: stdout-Verhalten bei stdio sowie Größenlimits und Fehlerantworten bei Streamable HTTP gehören in die Integrationstests.
4. Observability und Auth prüfen: Tracing-Export, Log-Scrubbing und die strengere OAuth-Validierung vor dem Rollout in Produktionsumgebungen abnehmen.

Einordnung: Das SDK macht einen wichtigen Schritt, weil es die neue MCP-Revision und ältere Clients in einem Server zusammenführt. Aber der Major-Release verschiebt zentrale Abstraktionen. Für Betreiber ist die richtige Haltung daher nicht „Update einspielen“, sondern „Migration planen“.

Quellen: offizieller Release v2.0.0 (28. Juli 2026) · offizieller Migrationsleitfaden