MCP-Server-Transports
MCP unterstützt Transport-Mechanismen für die Kommunikation zwischen Bob Shell und MCP-Servern.
Übersicht
MCP bietet drei Transport-Optionen, die jeweils für verschiedene Einsatzszenarien geeignet sind:
- STDIO-Transport (lokale Server)
- Streamable HTTP-Transport (moderner Standard für Remote-Server)
- SSE-Transport (veraltete Remote-Option)
Jeder Transport hat eigene Eigenschaften, Vorteile und Anwendungsfälle.
STDIO-Transport
STDIO-Transport läuft lokal auf deinem Gerät und kommuniziert über Standard-Ein-/Ausgabe-Streams.
Funktionsweise des STDIO-Transports
- Bob startet einen MCP-Server als Kindprozess
- Die Kommunikation erfolgt über Prozess-Streams: Bob schreibt in die STDIN des Servers, der Server antwortet über STDOUT
- Jede Nachricht wird durch ein Zeilenumbruchzeichen begrenzt
- Nachrichten sind als JSON-RPC 2.0 formatiert
Client Server
| |
|---- JSON-Nachricht ---->| (via STDIN)
| | (verarbeitet Anfrage)
|<---- JSON-Nachricht ----| (via STDOUT)
| |STDIO-Eigenschaften
- Lokalisierung: Läuft auf demselben Gerät wie Bob
- Leistung: Sehr geringe Latenz und Overhead (kein Netzwerk-Stack beteiligt)
- Einfachheit: Direkte Prozesskommunikation ohne Netzwerkkonfiguration
- Beziehung: Eins-zu-eins-Beziehung zwischen Client und Server
- Sicherheit: Inhärent sicherer ohne Netzwerkexposition
Wann STDIO verwenden
STDIO-Transport ist ideal für:
- Lokale Integrationen und Tools, die auf demselben Gerät laufen
- Sicherheitssensible Operationen
- Anforderungen mit geringer Latenz
- Single-Client-Szenarien (eine Bob-Instanz pro Server)
- Befehlszeilen-Tools und Skripte
STDIO-Implementierungsbeispiel
const server = new Server({name: 'local-server', version: '1.0.0'});
// Tools registrieren...
// STDIO-Transport verwenden
const transport = new StdioServerTransport(server);
transport.listen();Streamable HTTP-Transport
Streamable HTTP-Transport ist der moderne Standard für die Remote-MCP-Server-Kommunikation und ersetzt den älteren HTTP+SSE-Transport. Er arbeitet über HTTP/HTTPS und ermöglicht flexiblere Server-Implementierungen.
Funktionsweise des Streamable HTTP-Transports
- Der Server stellt einen einzelnen HTTP-Endpunkt (MCP-Endpunkt) bereit, der sowohl POST- als auch GET-Methoden unterstützt
- Bob sendet Anfragen an diesen MCP-Endpunkt über HTTP POST
- Der Server verarbeitet die Anfrage und sendet eine Antwort zurück
- Optional kann der Server Server-Sent Events (SSE) über dieselbe Verbindung nutzen, um mehrere Nachrichten oder Benachrichtigungen an Bob zu streamen
Dies ermöglicht sowohl einfache Anfrage-Antwort-Interaktionen als auch fortgeschritteneres Streaming und serverinitiierte Kommunikation.
Client Server
| |
|---- HTTP POST /mcp_endpoint ---->| (Client-Anfrage)
| | (verarbeitet Anfrage)
|<--- HTTP-Antwort / SSE-Stream ---| (Server-Antwort / Stream)
| |Streamable HTTP-Eigenschaften
- Moderner Standard: Bevorzugte Methode für neue Remote-MCP-Server-Implementierungen
- Remote-Zugriff: Kann auf einem anderen Gerät als Bob gehostet werden
- Skalierbarkeit: Kann mehrere Client-Verbindungen gleichzeitig verarbeiten
- Protokoll: Funktioniert über Standard-HTTP/HTTPS
- Flexibilität: Unterstützt einfache Anfrage-Antwort und fortgeschrittenes Streaming
- Einzelner Endpunkt: Verwendet einen einzelnen URL-Pfad für die gesamte MCP-Kommunikation
- Authentifizierung: Kann Standard-HTTP-Authentifizierungsmechanismen nutzen
- Rückwärtskompatibilität: Server können die Kompatibilität mit älteren HTTP+SSE-Clients aufrechterhalten
Wann Streamable HTTP verwenden
Streamable HTTP-Transport ist ideal für:
- Alle neuen Remote-MCP-Server-Entwicklungen
- Server, die robuste, skalierbare und flexible Kommunikation benötigen
- Integrationen, die möglicherweise Streaming-Daten oder Server-gesendete Benachrichtigungen beinhalten
- Öffentliche Dienste oder zentrale Tools
- Ersetzen veralteter SSE-Transport-Implementierungen
Streamable HTTP-Implementierungsbeispiel
Konfiguration in ~/.bob/mcp_settings.json (global) oder .bob/mcp.json (Projekt):
{
"mcpServers": {
"StreamableHTTPMCPName": {
"httpURL": "http://localhost:8080/mcp"
}
}
}Für die serverseitige Implementierung, siehe die MCP-SDK-Dokumentation für StreamableHTTPClientTransport.
Rückwärtskompatibilität mit HTTP+SSE
Clients und Server können die Rückwärtskompatibilität mit dem veralteten HTTP+SSE-Transport aufrechterhalten.
Server, die ältere Clients unterstützen möchten, sollten weiterhin sowohl den SSE-Endpunkt (/events) als auch den POST-Endpunkt (/message) des alten Transports neben dem neuen MCP-Endpunkt für den Streamable HTTP-Transport hosten.
SSE-Transport (Legacy)
Server-Sent Events (SSE)-Transport läuft auf einem Remote-Server und kommuniziert über HTTP/HTTPS. Für neue Remote-Server verwende stattdessen den Streamable HTTP-Transport.
Funktionsweise des SSE-Transports
- Bob verbindet sich über eine HTTP-GET-Anfrage mit dem SSE-Endpunkt des Servers
- Dies stellt eine persistente Verbindung her, über die der Server Ereignisse an Bob senden kann
- Für die Client-zu-Server-Kommunikation stellt Bob HTTP-POST-Anfragen an einen separaten Endpunkt
- Die Kommunikation erfolgt über zwei Kanäle:
- Ereignis-Stream (GET): Server-zu-Client-Updates
- Nachrichten-Endpunkt (POST): Client-zu-Server-Anfragen
Client Server
| |
|---- HTTP GET /events ----------->| (SSE-Verbindung herstellen)
|<---- SSE-Ereignis-Stream --------| (persistente Verbindung)
| |
|---- HTTP POST /message --------->| (Client-Anfrage)
|<---- SSE-Ereignis mit Antwort ---| (Server-Antwort)
| |SSE-Eigenschaften
- Remote-Zugriff: Kann auf einem anderen Gerät als Bob gehostet werden
- Skalierbarkeit: Kann mehrere Client-Verbindungen gleichzeitig verarbeiten
- Protokoll: Funktioniert über Standard-HTTP (keine speziellen Protokolle erforderlich)
- Persistenz: Hält eine persistente Verbindung für Server-zu-Client-Nachrichten aufrecht
- Authentifizierung: Kann Standard-HTTP-Authentifizierungsmechanismen nutzen
Wann SSE verwenden
SSE-Transport ist geeignet für:
- Remote-Zugriff über Netzwerke
- Multi-Client-Szenarien
- Öffentliche Dienste
- Zentrale Tools, auf die viele Nutzer zugreifen müssen
- Integration mit Web-Diensten
SSE-Implementierungsbeispiel
import express from 'express';
const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// Tools registrieren...
// SSE-Transport verwenden
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
console.log('MCP-Server lauscht auf Port 3000');
});Deployment-Überlegungen
Die Wahl zwischen STDIO und Remote-Transports (Streamable HTTP oder SSE) hat direkte Auswirkungen darauf, wie du deine MCP-Server deployest und verwaltest.
STDIO: Lokales Deployment
STDIO-Server laufen lokal auf demselben Gerät wie Bob:
- Installation: Die Server-Executable muss auf jedem Nutzergerät installiert werden
- Distribution: Du musst Installationspakete für verschiedene Betriebssysteme bereitstellen
- Updates: Jede Instanz muss separat aktualisiert werden
- Ressourcen: Verwendet CPU, Arbeitsspeicher und Festplatte des lokalen Geräts
- Zugriffskontrolle: Basiert auf den Dateisystem-Berechtigungen des lokalen Geräts
- Integration: Einfache Integration mit lokalen Systemressourcen (Dateien, Prozesse)
- Ausführung: Startet und stoppt mit Bob (Kindprozess-Lebenszyklus)
- Abhängigkeiten: Alle Abhängigkeiten müssen auf dem Nutzergerät installiert sein
Beispielanwendungsfall:
Ein lokales Dateisuchtool mit STDIO würde:
- Auf deinem Gerät laufen
- Direkten Zugriff auf das lokale Dateisystem haben
- Bei Bedarf von Bob gestartet werden
- Keine Netzwerkkonfiguration benötigen
- Neben Bob oder über einen Paketmanager installiert werden müssen
Remote: Gehostetes Deployment
Remote-Server (Streamable HTTP oder SSE) können auf Remote-Servern deployed und über das Netzwerk aufgerufen werden:
- Installation: Einmalig auf einem Server installiert, von vielen Nutzern aufgerufen
- Distribution: Ein einzelnes Deployment bedient mehrere Clients
- Updates: Zentralisierte Updates betreffen alle Nutzer sofort
- Ressourcen: Verwendet Server-Ressourcen, nicht lokale Geräteressourcen
- Zugriffskontrolle: Über Authentifizierungs- und Autorisierungssysteme verwaltet
- Integration: Komplexere Integration mit nutzerspezifischen Ressourcen
- Ausführung: Läuft als unabhängiger Dienst (oft kontinuierlich)
- Abhängigkeiten: Auf dem Server verwaltet, nicht auf Nutzergeräten
Beispielanwendungsfall:
Ein Datenbankabfragetool mit Remote-Transport würde:
- Auf einem zentralen Server laufen
- Mit serverseitigen Anmeldedaten eine Verbindung zu Datenbanken herstellen
- Kontinuierlich für mehrere Nutzer verfügbar sein
- Ordnungsgemäße Netzwerksicherheitskonfiguration erfordern
- Mit Container- oder Cloud-Technologien deployed werden
Hybride Ansätze
Einige Szenarien profitieren von einem hybriden Ansatz:
- STDIO mit Netzwerkzugriff: Ein lokaler STDIO-Server, der als Proxy zu Remote-Diensten fungiert
- Remote mit lokalen Befehlen: Ein Remote-Server, der Operationen auf dem Client-Gerät über Callbacks auslösen kann
- Gateway-Muster: STDIO-Server für lokale Operationen, die mit Remote-Servern für spezialisierte Funktionen verbunden sind
Transport-Vergleich
| Kriterium | STDIO | Streamable HTTP / SSE |
|---|---|---|
| Standort | Nur lokales Gerät | Lokal oder remote |
| Clients | Einzelner Client | Mehrere Clients |
| Leistung | Geringere Latenz | Höhere Latenz (Netzwerk-Overhead) |
| Einrichtungskomplexität | Einfacher | Komplexer (HTTP-Server erforderlich) |
| Sicherheit | Inhärent sicher | Erfordert explizite Sicherheitsmaßnahmen |
| Netzwerkzugriff | Nicht erforderlich | Erforderlich |
| Skalierbarkeit | Auf lokales Gerät beschränkt | Kann über Netzwerk verteilt werden |
| Deployment | Pro-Nutzer-Installation | Zentralisierte Installation |
| Updates | Verteilte Updates | Zentralisierte Updates |
| Ressourcennutzung | Verwendet Client-Ressourcen | Verwendet Server-Ressourcen |
| Abhängigkeiten | Client-seitige Abhängigkeiten | Server-seitige Abhängigkeiten |
Transports in Bob Shell konfigurieren
Detaillierte Informationen zur Konfiguration von Transports in Bob Shell, einschließlich Beispielkonfigurationen, findest du unter MCP in Bob Shell.