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 zu Sitzungen, Initialisierung, Skalierung, Kompatibilität und Governance.
Der Release-Kandidat MCP 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-Serverimplementierungen betreibt, sagte vor der endgültigen Veröffentlichung, dass sein MCP-Server die neue Spezifikation bereits unterstützt und beschrieb das Protokoll am 28. Juli als „zustandslos werdend“.
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 hat sich in MCP
geändert? 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-Bereitstellungen MCP 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 normalen 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 von Managed Computing 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 für 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 Ebene 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 zustandslose MCP für Entwickler und Betreiber wichtig ist
Agent-Tools haben ein Skalierungsproblem, das sich von der normalen API-Skalierung unterscheidet. 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 MCP passt es besser zu 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 vorkommt, 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 Authorization-Verhärtung in der neuen Revision ist daher kein Zufall. Dies spiegelt die Realität wider, dass der Toolzugriff nun eine Sicherheitsgrenze und nicht nur eine Bequemlichkeit für Entwickler darstellt.
Wer ist betroffen
Die am stärksten betroffenen Gruppen sind MCP Serverbetreuer, 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 Toolfunktionen, geändertes Authentifizierungsverhalten oder Agents gehören, die unterschiedliche Pfade einschlagen, weil sich ein Toolserver nicht mehr wie erwartet verhält.
Für ein AI 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 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 Nebeneffekten ausführen, wie z. B. das Erstellen von Pull-Anfragen, 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 für 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 aus früheren 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.