MCP unterstützt Transportmechanismen für die Kommunikation zwischen Bob und MCP-Servern.

Übersicht

MCP bietet drei Transportoptionen, die jeweils für unterschiedliche Bereitstellungsszenarien geeignet sind:

STDIO-Transport (lokale Server)
Streamable HTTP-Transport (moderner Standard für Remote-Server)
SSE-Transport (Legacy-Remote-Option)

Jeder Transport hat unterschiedliche Eigenschaften, Vorteile und Anwendungsfälle.

STDIO-Transport

STDIO-Transport läuft lokal auf Ihrem Computer und kommuniziert über Standard-Ein-/Ausgabeströme.

Wie STDIO-Transport funktioniert

Bob startet einen MCP-Server als Kindprozess
Die Kommunikation erfolgt über Prozessströme: Bob schreibt in STDIN des Servers, der Server antwortet auf STDOUT
Jede Nachricht wird durch ein Zeilenumbruchzeichen begrenzt
Nachrichten sind als JSON-RPC 2.0 formatiert

Client                    Server
  |                         |
  |---- JSON-Nachricht ---->| (über STDIN)
  |                         | (verarbeitet Anfrage)
  |<---- JSON-Nachricht ----| (über STDOUT)
  |                         |

STDIO-Eigenschaften

Lokalität: Läuft auf derselben Maschine 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 Werkzeuge, die auf derselben Maschine laufen
Sicherheitskritische Operationen
Anforderungen mit geringer Latenz
Einzelclient-Szenarien (eine Bob-Instanz pro Server)
Befehlszeilenwerkzeuge oder IDE-Erweiterungen

STDIO-Implementierungsbeispiel


const server = new Server({name: 'local-server', version: '1.0.0'});
// Werkzeuge registrieren...

// STDIO-Transport verwenden
const transport = new StdioServerTransport(server);
transport.listen();

Streamable HTTP-Transport ist der moderne Standard für die Remote-MCP-Serverkommunikation und ersetzt den älteren HTTP+SSE-Transport. Er arbeitet über HTTP/HTTPS und ermöglicht flexiblere Serverimplementierungen.

Wie Streamable HTTP-Transport funktioniert

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 mit HTTP POST
Der Server verarbeitet die Anfrage und sendet eine Antwort zurück
Optional kann der Server Server-Sent Events (SSE) über dieselbe Verbindung verwenden, um mehrere Nachrichten oder Benachrichtigungen an Bob zu streamen

Dies ermöglicht sowohl grundlegende Request-Response-Interaktionen als auch fortgeschritteneres Streaming und serverinitiierte Kommunikation.

Client                             Server
  |                                  |
  |---- HTTP POST /mcp_endpoint ---->| (Client-Anfrage)
  |                                  | (verarbeitet Anfrage)
  |<--- HTTP Response / SSE Stream --| (Server-Antwort / Stream)
  |                                  |

Streamable HTTP-Eigenschaften

Moderner Standard: Bevorzugte Methode für neue Remote-MCP-Serverimplementierungen
Remote-Zugriff: Kann auf einer anderen Maschine als Bob gehostet werden
Skalierbarkeit: Kann mehrere Client-Verbindungen gleichzeitig verarbeiten
Protokoll: Funktioniert über Standard-HTTP/HTTPS
Flexibilität: Unterstützt einfache Request-Response und fortgeschrittenes Streaming
Einzelner Endpunkt: Verwendet einen einzelnen URL-Pfad für die gesamte MCP-Kommunikation
Authentifizierung: Kann Standard-HTTP-Authentifizierungsmechanismen verwenden
Rückwärtskompatibilität: Server können Kompatibilität mit älteren HTTP+SSE-Clients aufrechterhalten

Wann Streamable HTTP verwenden

Streamable HTTP-Transport ist ideal für:

Alle neuen Remote-MCP-Serverentwicklungen
Server, die robuste, skalierbare und flexible Kommunikation erfordern
Integrationen, die Streaming-Daten oder servergesendete Benachrichtigungen beinhalten können
Öffentliche Dienste oder zentralisierte Werkzeuge
Ersatz von Legacy-SSE-Transportimplementierungen

Streamable HTTP-Implementierungsbeispiel

Konfiguration in settings.json:

{
  "mcpServers": {
    "StreamableHTTPMCPName": {
      "type": "streamable-http",
      "url": "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 Rückwärtskompatibilität mit dem veralteten HTTP+SSE-Transport aufrechterhalten.

Server, die ältere Clients unterstützen möchten, sollten weiterhin sowohl die SSE- (/events) als auch die POST-Endpunkte (/message) des alten Transports hosten, zusätzlich zum neuen MCP-Endpunkt, der für den Streamable HTTP-Transport definiert ist.

SSE-Transport (Legacy)

Server-Sent Events (SSE)-Transport läuft auf einem Remote-Server und kommuniziert über HTTP/HTTPS. Für neue Remote-Server verwenden Sie stattdessen Streamable HTTP-Transport.

Wie SSE-Transport funktioniert

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 sendet Bob HTTP-POST-Anfragen an einen separaten Endpunkt
Die Kommunikation erfolgt über zwei Kanäle:
- Ereignisstrom (GET): Server-zu-Client-Updates
- Nachrichten-Endpunkt (POST): Client-zu-Server-Anfragen

Client                             Server
  |                                  |
  |---- HTTP GET /events ----------->| (SSE-Verbindung herstellen)
  |<---- SSE-Ereignisstrom -----------| (persistente Verbindung)
  |                                  |
  |---- HTTP POST /message --------->| (Client-Anfrage)
  |<---- SSE-Ereignis mit Antwort ---| (Server-Antwort)
  |                                  |

SSE-Eigenschaften

Remote-Zugriff: Kann auf einer anderen Maschine 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 verwenden

Wann SSE verwenden

SSE-Transport ist geeignet für:

Remote-Zugriff über Netzwerke
Multi-Client-Szenarien
Öffentliche Dienste
Zentralisierte Werkzeuge, auf die viele Benutzer zugreifen müssen
Integration mit Webdiensten

SSE-Implementierungsbeispiel

import express from 'express';

const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// Werkzeuge registrieren...

// SSE-Transport verwenden
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
  console.log('MCP-Server hört auf Port 3000');
});

Bereitstellungsüberlegungen

Die Wahl zwischen STDIO und Remote-Transporten (Streamable HTTP oder SSE) wirkt sich direkt darauf aus, wie Sie Ihre MCP-Server bereitstellen und verwalten.

STDIO: Lokale Bereitstellung

STDIO-Server laufen lokal auf derselben Maschine wie Bob:

Installation: Die ausführbare Serverdatei muss auf dem Computer jedes Benutzers installiert werden
Verteilung: Sie müssen Installationspakete für verschiedene Betriebssysteme bereitstellen
Updates: Jede Instanz muss separat aktualisiert werden
Ressourcen: Verwendet CPU, Speicher und Festplatte der lokalen Maschine
Zugriffskontrolle: Verlässt sich auf die Dateisystemberechtigungen der lokalen Maschine
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 Computer des Benutzers installiert werden

Beispiel-Anwendungsfall:

Ein lokales Dateisuch-Werkzeug mit STDIO würde:

Auf dem Computer des Benutzers laufen
Direkten Zugriff auf das lokale Dateisystem haben
Bei Bedarf von Bob gestartet werden
Keine Netzwerkkonfiguration erfordern
Neben Bob oder über einen Paketmanager installiert werden müssen

Remote: Gehostete Bereitstellung

Remote-Server (Streamable HTTP oder SSE) können auf Remote-Servern bereitgestellt und über das Netzwerk aufgerufen werden:

Installation: Einmal auf einem Server installiert, von vielen Benutzern aufgerufen
Verteilung: Einzelne Bereitstellung bedient mehrere Clients
Updates: Zentralisierte Updates betreffen alle Benutzer sofort
Ressourcen: Verwendet Serverressourcen, nicht lokale Maschinenressourcen
Zugriffskontrolle: Verwaltet durch Authentifizierungs- und Autorisierungssysteme
Integration: Komplexere Integration mit benutzerspezifischen Ressourcen
Ausführung: Läuft als unabhängiger Dienst (oft kontinuierlich)
Abhängigkeiten: Auf dem Server verwaltet, nicht auf Benutzermaschinen