TL;DR: Die neue MCP-Spezifikation macht Agenten-Infrastruktur skalierbarer und besser kontrollierbar, zwingt bestehende Integrationen aber zu einer sorgfältigen technischen Bestandsaufnahme.
Das Model Context Protocol, kurz MCP, hat am 28. Juli 2026 seine bisher größte technische Überarbeitung erhalten. Die neue Version 2026-07-28 entfernt Sitzungen aus dem Protokollkern und macht jeden Aufruf zu einer eigenständigen Anfrage – ein wichtiger Schritt für Unternehmen, die KI-Agenten nicht nur testen, sondern zuverlässig betreiben wollen.
Die Spezifikation und passende SDKs sind bereits verfügbar.
Warum MCP für KI-Agenten wichtig ist
MCP standardisiert, wie KI-Anwendungen auf Werkzeuge und Datenquellen zugreifen. Ein Agent kann darüber beispielsweise Dokumente durchsuchen, Daten aus einem CRM abrufen oder eine Aktion in einem Drittsystem auslösen, ohne für jede Kombination aus Modell und Anwendung eine eigene Schnittstelle zu benötigen.
Bislang brachte der Betrieb entfernter MCP-Server jedoch eine klassische Skalierungsfrage mit sich: Der Client eröffnete zunächst eine Sitzung und erhielt eine Mcp-Session-Id. Nachfolgende Anfragen mussten dieser Sitzung zugeordnet werden. Bei mehreren Serverinstanzen waren deshalb sogenanntes Sticky Routing oder ein gemeinsamer Sitzungsspeicher erforderlich.
Die neue Spezifikation entfernt sowohl den initialize-Handshake als auch die Mcp-Session-Id. Eine Anfrage enthält nun selbst die Protokollversion, den aufgerufenen Vorgang und die benötigten Metadaten. Dadurch kann ein gewöhnlicher Load Balancer sie an eine beliebige verfügbare Instanz verteilen.
Ein vereinfachter Aufruf sieht beispielsweise so aus:
POST /mcp HTTP/1.1MCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: kundenakte_suchen { "jsonrpc": "2.0", "id": 17, "method": "tools/call", "params": { "name": "kundenakte_suchen", "arguments": { "kundennummer": "K-1042" } }}Die zusätzlichen Header haben einen praktischen Vorteil: Gateways, Firewalls und Rate-Limiter können erkennen, welche Methode und welches Werkzeug aufgerufen werden, ohne dafür zuerst den JSON-Inhalt auswerten zu müssen. Listen mit Werkzeugen oder Ressourcen dürfen außerdem Angaben zur Gültigkeitsdauer und zum erlaubten Cache-Bereich enthalten. Die Protokollbetreiber beschreiben MCP deshalb nun als zustandslos, routbar und cachefähig.
Zustandslos bedeutet nicht gedächtnislos
Ein zustandsloses Protokoll verbietet keinen Anwendungszustand. Es macht ihn lediglich ausdrücklich sichtbar. Benötigt ein Agent etwa einen laufenden Warenkorb, einen Browserkontext oder einen Bearbeitungsentwurf, sollte ein Werkzeug eine eindeutige ID zurückgeben. Der Agent übermittelt diese ID bei späteren Aufrufen erneut.
Für eine Einführung ist das mehr als ein technisches Detail. Teams müssen unterscheiden, welche Informationen nur für einen einzelnen Aufruf gelten und welche einen Geschäftsprozess über mehrere Schritte hinweg begleiten. Versteckter Sitzungszustand sollte durch dokumentierte Kennungen ersetzt werden, deren Lebensdauer, Berechtigungen und Löschung nachvollziehbar sind.
Damit werden Abläufe transparenter, aber nicht automatisch sicher. Eine im Tool-Aufruf enthaltene Vorgangs-ID darf beispielsweise nicht genügen, um auf fremde Datensätze zuzugreifen. Der Server muss weiterhin bei jeder Anfrage prüfen, ob die authentifizierte Identität diese konkrete Ressource verwenden darf.
Freigaben funktionieren jetzt ohne dauerhafte Verbindung
Besonders relevant für geschäftliche Prozesse sind Aktionen, die eine Bestätigung benötigen: eine Rechnung versenden, Daten löschen oder einen kostenpflichtigen Dienst buchen. Die neue Spezifikation führt dafür Multi Round-Trip Requests, kurz MRTR, ein.
Kann ein Werkzeug noch nicht fortfahren, antwortet es mit input_required. Der Client zeigt die Rückfrage an und wiederholt anschließend den ursprünglichen Aufruf mit der Entscheidung des Nutzers:
{ "resultType": "input_required", "inputRequests": { "freigabe": { "type": "elicitation", "message": "Rechnung über 4.800 Euro versenden?", "schema": { "type": "boolean" } } }, "requestState": "opaque-server-state"}Diese Rückfrage benötigt keine dauerhaft geöffnete Verbindung. Sie lässt sich deshalb auch hinter gewöhnlichen, horizontal skalierten Webdiensten abbilden. Wichtig bleibt, dass eine Freigabe verständlich benennt, welche Handlung mit welchen Folgen bestätigt wird. Ein technisch vorhandener Bestätigungsdialog ersetzt kein sinnvolles Berechtigungskonzept.
Ein realistischer Einführungsweg
Unternehmen sollten nicht mit einem universellen Agenten beginnen, der auf alle internen Systeme zugreifen darf. Sinnvoller ist ein abgegrenzter Prozess mit wenigen, klar benannten Werkzeugen – etwa die Suche in einer Wissensbasis oder das Erstellen eines noch nicht versendeten CRM-Entwurfs.
Im zweiten Schritt sollten Verantwortliche erfassen, welche Werkzeuge nur lesen und welche Daten oder externe Zustände verändern. Schreibende Aktionen benötigen engere Berechtigungen, Protokollierung und gegebenenfalls eine explizite Freigabe. Die neuen Mcp-Method- und Mcp-Name-Header erleichtern die technische Überwachung, sind aber kein Ersatz für OAuth, Rollen und Prüfungen auf Ressourcenebene.
Erst danach folgt die Skalierung. Dazu gehören mehrere austauschbare Serverinstanzen, verteiltes Tracing, definierte Zeitlimits und ein kontrollierter Umgang mit langen Aufgaben. Letztere liegen nun in der Erweiterung io.modelcontextprotocol/tasks; Clients können ihren Status über tasks/get abfragen. TypeScript, Python, Go und C# unterstützen die neue Spezifikation bereits als Tier-1-SDKs. Cloudflare betreibt ebenfalls MCP-Server mit Unterstützung für die Version 2026-07-28.
Wo Migrationen scheitern können
Bestehende Installationen sollten zunächst nach Abhängigkeiten von Mcp-Session-Id, dem bisherigen Handshake und dem alten HTTP-plus-SSE-Transport suchen. Roots, Sampling und Logging sind ebenfalls als veraltet markiert. Sie funktionieren laut Release-Mitteilung noch mindestens zwölf Monate, sollten aber nicht mehr Grundlage neuer Implementierungen werden.
Beim TypeScript-SDK kommt zusätzlich eine Paketaufteilung hinzu: Client, Server, Kernschemas und Framework-Adapter werden getrennt ausgeliefert. Der offizielle Migrationsleitfaden für das TypeScript-SDK v2 beschreibt automatische Änderungen, nennt aber auch Stellen, die weiterhin eine manuelle Entscheidung benötigen – etwa bei Transporten, OAuth-Fehlern und öffentlichen Paket-APIs.
Kontext: Vom lokalen Werkzeug zum Infrastrukturstandard
MCP begann als ein vergleichsweise schlankes Protokoll zur Verbindung von Modellen, Werkzeugen und Kontextquellen. Mit wachsender Nutzung verlagert sich der Schwerpunkt nun vom lokalen Entwicklerwerkzeug zur betriebssicheren Infrastruktur: Lastverteilung, Autorisierung, Caching, Beobachtbarkeit und lange Prozesse werden zu zentralen Fragen. Die neue Version löst nicht jedes Problem, bringt das Protokoll technisch aber näher an etablierte Webarchitekturen.
Was jetzt zu beobachten ist
Entscheidend wird sein, wie schnell Clients und bestehende MCP-Server die neue Version vollständig übernehmen. Unternehmen sollten besonders beobachten, welche Plattformen MRTR-Freigaben korrekt darstellen, wie interoperabel die Tasks-Erweiterung wird und wann alte Transporte tatsächlich verschwinden.
Wer jetzt mit MCP startet, sollte direkt auf 2026-07-28 aufbauen; bestehende Installationen benötigen zuerst eine Bestandsaufnahme statt eines unkontrollierten Versionswechsels.
Drei Kernaussagen
- MCP-Anfragen benötigen keine Protokollsitzung mehr und lassen sich dadurch leichter auf mehrere Serverinstanzen verteilen.
- Zustände, Berechtigungen und Freigaben verschwinden nicht, sondern müssen jetzt ausdrücklicher modelliert werden.
- Eine sichere Einführung beginnt mit wenigen Werkzeugen, klaren Schreibrechten und überprüfbaren menschlichen Freigaben.