MCP wird zustandslos: Was sich für Agenteninfrastruktur verschiebt

Wenn ein MCP-Server unter Last ersetzt wird, sollte ein Tool-Aufruf nicht daran scheitern, dass er auf der falschen Instanz landet. Genau diese Abhängigkeit nimmt die zustandslose MCP-Entwicklung ins Visier: Der Transport soll nicht länger an eine bestimmte Sitzung zwischen Client und Server gebunden sein.

MCP, das Model Context Protocol, verbindet Sprachmodelle und Agenten-Frameworks mit externen Werkzeugen und Ressourcen. Dauerhafte Verbindungen, Handshakes und Session-Pinning waren bislang Teil des Transportmodells. Auf einem lokalen Rechner fällt das selten auf. Verteilt ein Gateway Aufrufe über mehrere Instanzen, wird aus der Verbindung jedoch ein Betriebsrisiko: Ein Neustart kann einen fachlich gültigen Auftrag unterbrechen, obwohl ein anderer Server ihn bearbeiten könnte.

Der Protokollkern braucht keine Sitzung mehr

Mit der Spezifikation vom 28. Juli 2026 entfallen der initialize/initialized-Handshake und der logische Header Mcp-Session-Id. Eine Anfrage muss damit nicht erst einer laufenden Protokollsitzung zugeordnet werden, bevor der Server sie bearbeitet.

Protokollversion, Client-Informationen und Fähigkeiten werden im _meta-Feld jeder Anfrage übertragen. Der einzelne Request wird zum vollständigen Übergabepunkt: Was der Server für den Protokollablauf benötigt, muss bei diesem Aufruf vorliegen.

Das heißt nicht, dass jeder Tool-Aufruf schneller wird. Es nimmt Client, Gateway und Server aber einen gemeinsamen Transportzustand ab, den sie bislang koordinieren mussten. Ein Tool-Aufruf kann dadurch als einzelne HTTP-Anfrage verarbeitet werden, statt von einer zuvor aufgebauten Sitzung abzuhängen.

Skalierung ähnelt stärker gewöhnlichen HTTP-Diensten

Wenn jede Instanz jeden Aufruf annehmen kann, braucht der Lastverteiler keine feste Zuordnung zwischen Client und Container. Round-Robin-Load-Balancing und Serverless-Muster passen dann deutlich besser zum Transportmodell.

Für Plattform- und Betriebsteams zeigt sich der Unterschied beim Austausch einer Instanz. Erwartet ist, dass derselbe autorisierte Tool-Aufruf nach einem Neustart auf einer neuen Instanz verarbeitet wird. Tauchen stattdessen ein fehlender Handshake, eine unbekannte Session oder eine nicht erklärbare Ablehnung auf, steckt im eigenen Pfad noch Transportzustand. Dann ist nicht das Skalierungsproblem gelöst, sondern nur verschoben.

Der fachliche Zustand verschwindet dadurch nicht. Ein Tool kann weiterhin Berechtigungen, Daten oder einen laufenden Arbeitsauftrag benötigen. Transportzustand und Anwendungszustand gehören in getrennte Verantwortungsbereiche. Das ist der nützlichste Teil der Änderung, weil versteckte Abhängigkeiten im Betrieb meist erst sichtbar werden, wenn sie bereits stören.

Jeder Aufruf wird zum Prüfpunkt

MCP-Werkzeuge lassen sich gezielter prüfen und kontrollieren als eine weit offene Shell mit Internetzugang. Der zustandslose Transport schafft dafür einen klareren Ansatzpunkt: Ein Request bringt mehr der Informationen mit, die der Server über den aufrufenden Client benötigt.

Das ersetzt keine Berechtigungsprüfung und macht ein zu weit gefasstes Tool nicht sicher. Protokollierung und Bewertung werden aber einfacher, weil relevante Protokollinformationen nicht erst aus einer vorher aufgebauten Sitzung rekonstruiert werden müssen.

Ein sinnvoller Test lautet daher: Lässt sich ein eingehender Tool-Aufruf isoliert nachvollziehen und bewerten? Falls dafür versteckter Transportzustand nötig ist, liegt die Abhängigkeit wahrscheinlich in der eigenen Anwendung. Dort sollte sie ausdrücklich modelliert und abgesichert sein.

Vor einer Migration die Abhängigkeiten prüfen

Bestehende Installationen müssen nicht über Nacht umgebaut werden. Zuerst lohnt sich eine Bestandsaufnahme:

• Hängen eigene Komponenten am Handshake oder an Mcp-Session-Id?
• Erzwingt ein Gateway noch eine feste Serverbindung?
• Welche Daten gehören wirklich zum Auftrag oder zur Autorisierung?
• Kann ein Testaufruf nach dem Austausch einer Instanz ohne zusätzliche Sitzungsdaten erklärt und autorisiert werden?

Erst mit diesen Antworten lässt sich entscheiden, ob die Spezifikation kurzfristig Betriebsaufwand senkt oder zunächst den Integrationspfad für kommende Komponenten vorgibt.

Die praktische Mindestregel

Zustandsloser Transport nimmt MCP nicht die fachliche Komplexität ab. Er verhindert aber, dass sie sich unbemerkt im Handshake, im Gateway oder an einer einzelnen Instanz versteckt. Metadaten, Autorisierung und fachlicher Zustand brauchen jeweils einen eindeutigen Platz. Dann wird ein Instanzwechsel zu einem normalen Betriebsereignis statt zu einer neuen Quelle schwer auffindbarer Fehler.