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:

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

  1. Bob startet einen MCP-Server als Kindprozess
  2. Die Kommunikation erfolgt über Prozess-Streams: Bob schreibt in die STDIN des Servers, der Server antwortet über STDOUT
  3. Jede Nachricht wird durch ein Zeilenumbruchzeichen begrenzt
  4. 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

  1. Der Server stellt einen einzelnen HTTP-Endpunkt (MCP-Endpunkt) bereit, der sowohl POST- als auch GET-Methoden unterstützt
  2. Bob sendet Anfragen an diesen MCP-Endpunkt über HTTP POST
  3. Der Server verarbeitet die Anfrage und sendet eine Antwort zurück
  4. 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

  1. Bob verbindet sich über eine HTTP-GET-Anfrage mit dem SSE-Endpunkt des Servers
  2. Dies stellt eine persistente Verbindung her, über die der Server Ereignisse an Bob senden kann
  3. Für die Client-zu-Server-Kommunikation stellt Bob HTTP-POST-Anfragen an einen separaten Endpunkt
  4. 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:

  1. STDIO mit Netzwerkzugriff: Ein lokaler STDIO-Server, der als Proxy zu Remote-Diensten fungiert
  2. Remote mit lokalen Befehlen: Ein Remote-Server, der Operationen auf dem Client-Gerät über Callbacks auslösen kann
  3. Gateway-Muster: STDIO-Server für lokale Operationen, die mit Remote-Servern für spezialisierte Funktionen verbunden sind

Transport-Vergleich

KriteriumSTDIOStreamable HTTP / SSE
StandortNur lokales GerätLokal oder remote
ClientsEinzelner ClientMehrere Clients
LeistungGeringere LatenzHöhere Latenz (Netzwerk-Overhead)
EinrichtungskomplexitätEinfacherKomplexer (HTTP-Server erforderlich)
SicherheitInhärent sicherErfordert explizite Sicherheitsmaßnahmen
NetzwerkzugriffNicht erforderlichErforderlich
SkalierbarkeitAuf lokales Gerät beschränktKann über Netzwerk verteilt werden
DeploymentPro-Nutzer-InstallationZentralisierte Installation
UpdatesVerteilte UpdatesZentralisierte Updates
RessourcennutzungVerwendet Client-RessourcenVerwendet Server-Ressourcen
AbhängigkeitenClient-seitige AbhängigkeitenServer-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.

Wie ist dieses Thema?