Die Flags stateless_http und json_response in MCP-Servern steuern grundlegende Aspekte des Verhaltens deines Servers. Zu verstehen, wann und warum du sie einsetzen solltest, ist entscheidend, besonders wenn du planst, deinen Server zu skalieren oder in der Produktion einzusetzen.
Wann du Stateless HTTP benötigst
Stell dir vor, du baust einen MCP-Server, der populär wird. Anfangs hast du vielleicht nur wenige Clients, die sich mit einer einzelnen Serverinstanz verbinden:
Wenn dein Server wächst, versuchen vielleicht Tausende von Clients, sich zu verbinden. Eine einzelne Serverinstanz lässt sich nicht so skalieren, dass sie den gesamten Traffic bewältigen kann:
Die typische Lösung ist horizontale Skalierung – das Ausführen mehrerer Serverinstanzen hinter einem Load Balancer:
Aber hier wird es kompliziert. Denk daran, dass MCP-Clients zwei separate Verbindungen benötigen:
- Eine GET-SSE-Verbindung zum Empfangen von Server-zu-Client-Anfragen
- POST-Anfragen zum Aufrufen von Tools und Empfangen von Antworten
Mit einem Load Balancer können diese Anfragen an unterschiedliche Serverinstanzen weitergeleitet werden. Wenn dein Tool Claude verwenden muss (über Sampling), müsste der Server, der die POST-Anfrage bearbeitet, sich mit dem Server abstimmen, der die GET-SSE-Verbindung bearbeitet. Das führt zu einem komplexen Koordinationsproblem zwischen den Servern.
Wie Stateless HTTP dieses Problem löst
Das Setzen von stateless_http=True beseitigt dieses Koordinationsproblem, allerdings mit erheblichen Kompromissen:
Wenn Stateless HTTP aktiviert ist:
- Clients erhalten keine Sitzungs-IDs – der Server kann einzelne Clients nicht nachverfolgen
- Keine Server-zu-Client-Anfragen – der GET-SSE-Pfad steht nicht mehr zur Verfügung
- Kein Sampling – Claude oder andere KI-Modelle können nicht verwendet werden
- Keine Fortschrittsberichte – während langer Vorgänge können keine Fortschrittsaktualisierungen gesendet werden
- Keine Abonnements – Clients können nicht über Ressourcenaktualisierungen benachrichtigt werden
Es gibt jedoch einen Vorteil: Die Client-Initialisierung ist nicht mehr erforderlich. Clients können Anfragen direkt stellen, ohne den anfänglichen Handshake-Prozess durchlaufen zu müssen.
JSON Response verstehen
Das Flag json_response=True ist einfacher – es deaktiviert lediglich das Streaming für Antworten auf POST-Anfragen. Statt mehrerer SSE-Nachrichten während der Ausführung eines Tools erhältst du nur das Endergebnis als reines JSON.
Bei deaktiviertem Streaming:
- Keine zwischenzeitlichen Fortschrittsmeldungen
- Keine Log-Ausgaben während der Ausführung
- Nur das endgültige Tool-Ergebnis
Wann diese Flags verwendet werden sollten
Verwende Stateless HTTP, wenn:
- Du horizontale Skalierung mit Load Balancern benötigst
- Du keine Server-zu-Client-Kommunikation benötigst
- Deine Tools kein Sampling von KI-Modellen erfordern
- Du den Verbindungs-Overhead minimieren möchtest
Verwende JSON Response, wenn:
- Du keine Streaming-Antworten benötigst
- Du einfachere, nicht streamende HTTP-Antworten bevorzugst
- Du mit Systemen integrierst, die reines JSON erwarten
Entwicklung vs. Produktion
Wenn du lokal mit Standard-I/O-Transport entwickelst, aber planst, mit HTTP-Transport bereitzustellen, teste mit demselben Transport, den du in der Produktion verwenden wirst. Die Verhaltensunterschiede zwischen zustandsbehafteten und zustandslosen Modi können erheblich sein, und es ist besser, etwaige Probleme während der Entwicklung zu erkennen als nach der Bereitstellung.
Diese Flags verändern grundlegend, wie dein MCP-Server funktioniert. Wähle sie daher basierend auf deinen spezifischen Anforderungen an Skalierung und Funktionalität.