Das Model Context Protocol hat einen wichtigen Infrastruktur-Meilenstein erreicht: Die Überarbeitung vom 28.07.2026 verschiebt das Protokoll in Richtung eines zustandslosen Kerns. Für Teams, die Agentensysteme, Toolserver, IDE-Integrationen oder Orchestrierungsebenen mit mehreren Modellen erstellen, handelt es sich hierbei nicht um ein kosmetisches Spezifikationsupdate. Es ändert Annahmen über Sitzungen, Initialisierung, Skalierung, Kompatibilität und Governance.
Der MCP-Release-Kandidat beschrieb die Spezifikation vom 28. Juli als das Hinzufügen eines zustandslosen Protokollkerns, eines Erweiterungs-Frameworks, Aufgaben, MCP-Apps, Autorisierungshärtung und einer formellen veralteten Richtlinie. Der offizielle MCP-Blog warnte außerdem, dass die Veröffentlichung wichtige Änderungen enthält. GitHub, das eine der sichtbarsten MCP-Server-Implementierungen betreibt, sagte vor der endgültigen Veröffentlichung, dass sein MCP-Server die neue Spezifikation bereits unterstütze und beschrieb das Protokoll am 28. Juli als „zustandslos werden“.
Die praktische Bedeutung ist klar: MCP wird weniger wie eine sitzungslastige lokale Integrationsschicht als vielmehr wie ein Internet-Protokoll für den Remote-Tool-Zugriff geformt. Das ist wichtig, weil Agentensysteme nicht mehr auf Desktop-Entwicklertools beschränkt sind. Sie laufen zunehmend in Cloud-Diensten, CI-Systemen, Kundensupport-Workflows, Issue-Trackern und Unternehmensautomatisierungsplattformen.
Was sich in MCP geändert hat
Die wichtigste Änderung ist die Umstellung auf einen zustandslosen Protokollkern. Im Änderungsprotokoll von GitHub heißt es, dass der neue Kern Sitzungen entfernt und initialisiert, mit dem Ziel, Remote-MCP-Bereitstellungen einfacher skalierbar zu machen. Das ist ein bedeutender architektonischer Wandel. Zustandsbehaftete Protokolle können für lokale Tools und kontrollierte Umgebungen gut funktionieren, erschweren jedoch die horizontale Skalierung, serverlose Ausführung, Failover, Edge-Bereitstellung und Lastausgleich.
Ein zustandsloser Kern gibt Implementierern mehr Freiheit, MCP-Server hinter einer gewöhnlichen Webinfrastruktur auszuführen. Anfragen können über Instanzen verteilt werden, ohne dass eine langlebige Sitzung auf einem bestimmten Backend aufrechterhalten wird. Für große Unternehmen kann dies die betriebliche Komplexität reduzieren. Für kleinere Teams kann es gehostete MCP-Server möglicherweise einfacher machen, sie mithilfe verwalteter Datenverarbeitung anstelle einer benutzerdefinierten, lang laufenden Infrastruktur bereitzustellen.
Die umfassendere Version vom 28.07.2026 führt laut den Materialien der Veröffentlichungskandidaten auch ein Erweiterungs-Framework und Aufgaben ein. Diese Ergänzungen deuten darauf hin, dass MCP modularer und expliziter in Bezug auf länger laufende Arbeiten wird. MCP-Apps und Autorisierungshärtung weisen in die gleiche Richtung: Das Protokoll reift vom frühen Ökosystem-Kleber zu einer formelleren Schicht für die Agent-zu-Tool-Interaktion.
Der Preis dieser Reifung ist Kompatibilitätsarbeit. Der MCP-Blog beschrieb die Veröffentlichung als eine Version mit bahnbrechenden Änderungen, und die im Zusammenhang mit der Überarbeitung veröffentlichten TypeScript- und C#-SDK-Materialien konzentrieren sich auf Migrationsunterstützung und zustandslose Konzepte. Jedes Team, das einen MCP-Server betreibt, MCP in eine IDE-Erweiterung einbettet oder Agentenaufrufe über die interne Infrastruktur weiterleitet, sollte die Überarbeitung als technisches Ereignis und nicht als Standardaktualisierung im Hintergrund behandeln.
Warum zustandsloses MCP für Entwickler und Betreiber wichtig ist
Agent-Tools haben ein Skalierungsproblem, das anders aussieht als die normale API-Skalierung. Eine einzelne Benutzeranfrage kann viele Werkzeugaufrufe, Modelldrehungen, Wiederholungsversuche, Dateilesevorgänge, Suchabfragen und Genehmigungsschritte auslösen. Wenn das Tool-Protokoll dauerhafte Sitzungen voraussetzt, müssen Produktionsbetreiber den Status über diese Interaktionen hinweg beibehalten oder Problemumgehungen rund um das Protokoll erstellen.
Durch das Entfernen von Sitzungen aus dem Kern eignet sich MCP besser für Umgebungen, in denen die Arbeitslast der Agenten stoßweise, verteilt und asynchron ist. Serverlose Funktionen, Edge-Worker, Kubernetes-Bereitstellungen und Systeme mit mehreren Regionen profitieren alle davon, wenn Anfragen unabhängig voneinander bearbeitet werden können. Dadurch wird der Status nicht aus Agent-Anwendungen entfernt; Es verschiebt den Status in Anwendungsdatenbanken, Aufgabenwarteschlangen, Identitätssysteme oder explizite Workflow-Ebenen, anstatt ihn in den Protokollkern einzubetten.
Für Entwickler sollte die Änderung letztendlich die Nutzung von Remote-Tool-Servern einfacher machen. Für Plattformteams kann es die Beobachtbarkeit und Kapazitätsplanung vereinfachen. Anstatt undurchsichtiges Sitzungsaffinitätsverhalten zu debuggen, können sich Bediener auf Ablaufverfolgungen auf Anforderungsebene, Tool-Aufruflatenz, Autorisierungsentscheidungen und Fehlermuster konzentrieren.
Es gibt auch einen Governance-Aspekt. Da MCP in Codierungsassistenten und Unternehmensagenten immer häufiger zum Einsatz kommt, benötigen Unternehmen Richtlinien dazu, welche Tools Agenten aufrufen können, auf welche Daten sie zugreifen können und welche Benutzer oder Dienste sie aufrufen dürfen. Die Autorisierungshärtung in der neuen Revision ist daher kein Zufall.Es spiegelt die Realität wider, dass der Toolzugriff mittlerweile eine Sicherheitsgrenze und nicht nur eine Annehmlichkeit für Entwickler darstellt.
Wer ist betroffen?
Die am stärksten betroffenen Gruppen sind MCP-Server-Betreuer, SDK-Benutzer, Agentenplattformteams und Organisationen, die interne Tools KI-Agenten zugänglich machen. Wenn ein Server vom Sitzungsverhalten oder älteren Initialisierungsabläufen abhängig ist, muss er anhand der neuen Spezifikation getestet werden. Wenn eine Anwendung mehrere MCP-Versionen unterstützt, sind möglicherweise Versionsverhandlungen, Kompatibilitätsebenen oder ein schrittweiser Migrationsplan erforderlich.
IDE- und Entwicklertool-Anbieter sind ebenfalls im Umfang enthalten. MCP erscheint zunehmend neben Codierungsagenten, benutzerdefinierten Agenten und Modellverwaltungsfunktionen. Ein zustandsloser Protokollkern erleichtert es diesen Produkten, Remote-Tools zuverlässig aufzurufen, allerdings nur, wenn ihre Integrationen mit der Spezifikation Schritt halten.
Unternehmen, die Agentenautomatisierung verwenden, sollten aufmerksam sein, auch wenn sie die MCP-Spezifikation nie lesen. Die Änderung kann sich auf die Zuverlässigkeit von Agenten auswirken, die eine Verbindung zu Repositorys, Ticketsystemen, Datenbanken, internen Wissensdatenbanken oder Bereitstellungstools herstellen. Während der Migrationsfenster sind die wahrscheinlichen Fehlermodi nicht nur offensichtliche Ausfälle. Dazu können fehlende Tool-Funktionen, geändertes Authentifizierungsverhalten oder Agenten gehören, die andere Pfade einschlagen, weil sich ein Tool-Server nicht mehr wie erwartet verhält.
Für ein KI-API-Gateway wie Model Gate ist die Verbindung praktisch. Eine einheitliche KI-API ist zunehmend in der Nähe von Modellrouting, API-Schlüsselverwaltung, Nutzungsanalyse und Team-API-Governance angesiedelt. Da Agentensysteme neben gewöhnlichen Modellaufrufen auch MCP-Toolaufrufe hinzufügen, müssen Gateway- und Observability-Ebenen beide Seiten des Workflows berücksichtigen: welches Modell verwendet wurde, welche Tools aufgerufen wurden, was sie kosten, wer sie autorisiert hat und wo Fehler aufgetreten sind.
Migrationsprioritäten und offene Fragen
Die erste Migrationspriorität ist die Kompatibilitätsprüfung. Teams sollten MCP-Clients und -Server inventarisieren, Abhängigkeiten von Sitzungen identifizieren oder Verhalten initialisieren und Tests anhand der SDKs vom 28.07.2026 oder Konformitätsmaterialien durchführen, sofern verfügbar. Produktionssysteme sollten das Upgrade durchführen, insbesondere wenn Agenten Aktionen mit Nebenwirkungen ausführen, wie z. B. das Erstellen von Pull-Requests, das Ändern von Problemen, das Abfragen von Kundendaten oder das Ausführen von Bereitstellungsworkflows.
Die zweite Priorität ist die Beobachtbarkeit. Eine zustandslose Infrastruktur kann einfacher zu skalieren sein, verteilte Agentensysteme benötigen jedoch weiterhin Korrelations-IDs, Trace-Erfassung, Anforderungsprotokolle und Richtlinienereignisse. Ohne diese können Teams die Sitzungskomplexität gegen die Debugging-Komplexität eintauschen. Bei der Nutzungsanalyse sollte zwischen Modellaufrufen und Toolaufrufen unterschieden werden, insbesondere wenn Agenten-Workflows in Rechnung gestellt, ratenbegrenzt oder vom Team geprüft werden.
Die dritte Priorität ist die Autorisierungsüberprüfung. Wenn die neue Spezifikation die Autorisierungssemantik verschärft, sollten Implementierer nicht einfach alte Zugriffsannahmen in die neue Version portieren. Sie sollten Token-Umfänge, Benutzerdelegierung, Dienstkonten, Prüfprotokolle und Ablehnungsverhalten erneut überprüfen. Der Tool-Zugriff sollte standardmäßig auf die geringsten Rechte beschränkt sein, insbesondere bei Remote-MCP-Bereitstellungen.
Einige Details sollten noch überprüft werden, bevor Unternehmen unumkehrbare Designentscheidungen treffen. Die für diesen Artikel verfügbaren Recherchen umfassten den Release Candidate, die Spezifikationsseite, SDK-Migrationsmaterialien und den Implementierungshinweis von GitHub. Der endgültige normative Wortlaut der Spezifikation vom 28.07.2026 sollte direkt überprüft werden, bevor genaue Protokollanforderungen in internen Standards oder Kundendokumentationen zitiert werden.
Trotz dieser Einschränkung ist die Richtung klar. MCP entwickelt sich zu einem stärker produktionsorientierten Protokoll für die Agenteninfrastruktur. Der zustandslose Kern sollte die Skalierung von Remote-Bereitstellungen erleichtern, zwingt das Ökosystem jedoch auch dazu, Annahmen früherer Implementierungen zu bereinigen. Für Teams, die mit Agenten aufbauen, ist dies die Art von Protokolländerung, die ein Sprint-Ticket und nicht nur ein Lesezeichen verdient.