Die am 28. Juli 2026 veröffentlichte MCP-Spezifikation entfernt Sitzungen und den Initialize-Handshake. Jede JSON-RPC-Anfrage ist eigenständig, MCP-Server lassen sich hinter üblichen Load Balancern betreiben. Dazu kommen Tasks und MCP Apps als Erweiterungen, strengere Autorisierung und eine formale Deprecation-Policy. Wer eigene Server oder Clients betreibt, muss wegen Breaking Changes auf neue SDKs wechseln.
Wer MCP-Server betreibt, muss migrieren: In der Spezifikation vom 28. Juli 2026 steht jede Anfrage für sich.
Das Wichtigste in Kürze
- MCP ist ab dieser Version zustandslos. Der Initialize-Handshake und der Header
Mcp-Session-Identfallen, jede JSON-RPC-Anfrage ist in sich geschlossen. - Server skalieren hinter normalen Load Balancern. Clients sind nicht mehr an eine bestimmte Serverinstanz gebunden.
- Die Autorisierung wird strenger. Die Spezifikation verlangt Issuer-Prüfung nach RFC 9207 und bevorzugt Client ID Metadata Documents statt Dynamic Client Registration.
- Alte Funktionen laufen mindestens 12 Monate weiter. Roots, Sampling, Logging und der Transport HTTP+SSE gelten als veraltet, eine formale Deprecation-Policy regelt die Fristen.
Was sich bei MCP ändert
Bisher begann jede Verbindung mit einem Handshake, der einen Zustand auf dem Server aufbaute. Das war für Betreiber mühsam, denn Clients mussten an eine Instanz gebunden bleiben. Die neue Fassung entfernt diesen Schritt ganz.
Deshalb gibt es für Rückfragen, etwa eine Bestätigung oder einen fehlenden Parameter, das neue Verfahren Multi Round-Trip Requests. Dabei bleibt kein offener Datenstrom nötig.
Zudem stehen Methoden- und Toolname jetzt in den HTTP-Headern Mcp-Method und Mcp-Name. Ein Gateway kann so routen und freigeben, ohne den JSON-Körper zu lesen. Die Listen tools/list, prompts/list und resources/list tragen ausserdem ttlMs und cacheScope, damit Clients sie zwischenspeichern.
Erweiterungen und Autorisierung
Zudem wandern Tasks aus dem experimentellen Kern in die Erweiterung io.modelcontextprotocol/tasks. Ein Server liefert eine taskId, der Client fragt den Fortschritt ab. Das hilft bei langen Abläufen wie Pipelines, die sonst in Timeouts laufen.
Dazu kommen MCP Apps: Sie erlauben Servern, kleine HTML-Oberflächen in einem abgeschotteten iframe im Chat anzuzeigen. Das AAIF nennt Dashboards und Konfigurationsassistenten als Beispiele.
Auch bei der Anmeldung nennt das AAIF OAuth 2.1 und OpenID Connect als Pflicht. Hinzu kommt eine Erweiterung für unternehmensverwaltete Freigaben. Der MCP-Blog ergänzt, dass Zugangsdaten an den ausstellenden Autorisierungsserver gebunden werden.
Was Betreiber jetzt tun
Die Änderungen sind nicht abwärtskompatibel. Die Tier-1-SDKs für TypeScript, Python, Go und C# sind aktualisiert, das Rust-SDK unterstützt die Spezifikation als Beta. Für die Migration verweist der Blog auf die Dokumentation der SDKs.
- Suche in deinem Code nach Abhängigkeiten von Sitzungen und
Mcp-Session-Id. - Stelle den Transport HTTP+SSE auf den neuen Weg um.
- Prüfe, ob Roots, Sampling oder Logging im Einsatz sind. Das AAIF nennt als Zeitpunkt einer möglichen Entfernung die Zeit nach dem 28. Juli 2027.
- Teste die neue Autorisierung mit deinem Identity-Anbieter, bevor du Clients umstellst.
Wie wichtig Aufsicht über MCP-Server ist, zeigt die Studie zu 15.465 MCP-Servern ohne Governance. Den Aufbau eines Servers im Microsoft-Umfeld beschreibt der Artikel zum MCP-Server für Microsoft 365.
Der MCP-Blog hat die Spezifikation am 28. Juli 2026 veröffentlicht, ein späteres Update nennt er nicht.
Fazit
Die Version 2026-07-28 macht MCP betriebsfreundlicher, kostet Betreiber aber eine Migration. Der grösste Gewinn liegt bei der Skalierung hinter gewöhnlichen Load Balancern. Beginne mit der Bestandsaufnahme deiner Server und Clients, denn die Fristen für veraltete Funktionen laufen.
Quellen: MCP Blog, AAIF. Foto: Monfocus / Pixabay. Stand: 28. Juli 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.