Der Streamable-HTTP-Transport ermöglicht es MCP-Clients, sich über HTTP-Verbindungen mit remote gehosteten Servern zu verbinden. Im Gegensatz zum Standard-I/O-Transport, der sowohl Client als auch Server auf derselben Maschine erfordert, eröffnet dieser Transport Möglichkeiten für öffentliche MCP-Server, auf die jeder zugreifen kann.
Es gibt jedoch einen wichtigen Vorbehalt: Bestimmte Konfigurationseinstellungen können die Funktionalität deines MCP-Servers erheblich einschränken. Wenn deine Anwendung lokal mit Standard-I/O-Transport einwandfrei funktioniert, aber bei der Bereitstellung mit HTTP-Transport nicht mehr funktioniert, ist dies wahrscheinlich die Ursache.
Konfigurationseinstellungen, die wichtig sind
Zwei zentrale Einstellungen steuern das Verhalten des Streamable-HTTP-Transports:
stateless_http- Steuert die Verwaltung des Verbindungszustandsjson_response- Steuert die Handhabung des Antwortformats
Standardmäßig sind beide Einstellungen false, aber bestimmte Bereitstellungsszenarien können dich zwingen, sie auf true zu setzen. Wenn diese aktiviert sind, können sie Kernfunktionen wie Fortschrittsbenachrichtigungen, Logging und vom Server initiierte Anfragen beeinträchtigen.
Die Herausforderung der HTTP-Kommunikation
Um zu verstehen, warum diese Einschränkungen bestehen, müssen wir uns ansehen, wie HTTP-Kommunikation funktioniert. Bei Standard-HTTP:
- Clients können problemlos Anfragen an Server initiieren (der Server hat eine bekannte URL)
- Server können problemlos auf diese Anfragen antworten
- Server können nicht ohne Weiteres Anfragen an Clients initiieren (Clients haben keine bekannten URLs)
- Antwortmuster vom Client zurück zum Server werden problematisch
Betroffene MCP-Nachrichtentypen
Diese HTTP-Einschränkung wirkt sich auf bestimmte MCP-Kommunikationsmuster aus. Die folgenden Nachrichtentypen lassen sich mit reinem HTTP nur schwer umsetzen:
- Vom Server initiierte Anfragen: Create-Message-Anfragen, List-Roots-Anfragen
- Benachrichtigungen: Fortschrittsbenachrichtigungen, Logging-Benachrichtigungen, Initialized-Benachrichtigungen, Cancelled-Benachrichtigungen
Genau das sind die Funktionen, die ausfallen, wenn du die restriktiven HTTP-Einstellungen aktivierst. Fortschrittsbalken verschwinden, das Logging funktioniert nicht mehr, und vom Server initiierte Sampling-Anfragen schlagen fehl.
Die Streamable-HTTP-Lösung
Der Streamable-HTTP-Transport bietet tatsächlich eine clevere Lösung, um die Einschränkungen von HTTP zu umgehen, allerdings mit Kompromissen. Wenn du gezwungen bist, stateless_http=True oder json_response=True zu verwenden, teilst du dem Transport im Grunde mit, innerhalb der Beschränkungen von HTTP zu arbeiten, anstatt sie zu umgehen.
Das Verständnis dieser Einschränkungen hilft dir, fundierte Entscheidungen zu treffen über:
- Welchen Transport du für unterschiedliche Bereitstellungsszenarien verwenden solltest
- Wie du deinen MCP-Server so gestaltest, dass er mit HTTP-Beschränkungen elegant umgeht
- Wann es sich lohnt, eingeschränkte Funktionalität zugunsten der Vorteile des Remote-Hostings in Kauf zu nehmen
Entscheidend ist zu wissen, dass diese Einschränkungen bestehen, und deine MCP-Server-Architektur entsprechend zu planen. Wenn deine Anwendung stark auf vom Server initiierte Anfragen oder Echtzeit-Benachrichtigungen angewiesen ist, musst du möglicherweise deine Wahl des Transports überdenken oder alternative Kommunikationsmuster implementieren.