MCP: stdio, Streamable HTTP und SSE im Vergleich
stdio oder Streamable HTTP für MCP? Vergleichen Sie Startweg, Betrieb, Anmeldung und Fehlersuche. Mit Einordnung des älteren SSE-Transports.
Sie haben einen passenden MCP-Server gefunden und müssen entscheiden, wie Ihr Client ihn erreicht. Beginnen Sie mit der dokumentierten Schnittstelle des konkreten Servers: ein ausführbarer Befehl für stdio oder ein Endpunkt für HTTP. Prüfen Sie danach, ob Ihr Client diesen Weg unterstützt. Die Entscheidung verändert, wer den Prozess startet, wo Dateien liegen und welche Fehler Sie zuerst untersuchen. Sie entscheidet nicht automatisch über Funktionsumfang, Qualität oder die Rechte einer Verbindung.
stdio verbindet den Client mit einem Unterprozess
Bei stdio startet der Client den Server als Unterprozess. Protokollnachrichten laufen über Standardeingabe und Standardausgabe; Diagnosemeldungen können auf stderr ausgegeben werden. Zusätzlicher gewöhnlicher Text auf stdout stört dagegen die Protokollkommunikation. Der Start braucht einen verfügbaren Befehl, seine Argumente und die richtige Umgebung. Notieren Sie deshalb nicht nur die Paketkennung, sondern auch Laufzeit und vollständige Pfade.
Dieser Weg passt zu einem Prozess, dessen Lebenszyklus Ihr Client übernimmt. Das kann ein direkt gestartetes Programm oder ein Docker-Container mit stdio sein. „Lokal“ ist dabei eine Angabe zum Prozessstart und keine Zusicherung, dass der Server niemals externe Dienste aufruft. Lesen Sie auch die Beschreibung seiner Werkzeuge und Datenquellen.
Streamable HTTP erreicht einen eigenständigen Dienst
Streamable HTTP verbindet den Client mit einem HTTP-Endpunkt eines eigenständigen Servers. Die Protokollfassung 2025-11-25 beschreibt dafür HTTP-Anfragen und optional Ereignisströme. Das frühere HTTP+SSE-Verfahren ist ein eigener älterer Transport. Dass in beiden Zusammenhängen SSE vorkommt, macht die Konfigurationsformen nicht austauschbar. Verwenden Sie den exakt dokumentierten Endpunkt und prüfen Sie die unterstützte Fassung beider Seiten.
Ein HTTP-Dienst kann auf demselben Rechner oder entfernt laufen. Klären Sie in Ihrer Planung, wer ihn startet und betreibt. Ein offener Browser zeigt nur eine Antwort auf dessen Anfrage; er führt keine vollständige MCP-Initialisierung aus. Testen Sie die Verbindung im vorgesehenen Client. Anmeldung, Sitzungsverwaltung und Netzwerkzugriff gehören dabei zu unterschiedlichen Prüfschritten.
Die Unterschiede für Ihre Einrichtung vergleichen
| Frage | stdio | Streamable HTTP |
|---|---|---|
| Was trägt die Konfiguration? | Befehl und Argumente | Dokumentierte Endpunktadresse |
| Wer startet den Server? | Der Client als Unterprozess | Der Betreiber des Dienstes |
| Wo zuerst nach Fehlern suchen? | Startumgebung, Pfade, Prozessausgabe | Endpunkt, Netzwerk, Anmeldung |
| Wie prüfen Sie Erfolg? | Initialisierung und begrenzte Operation | Initialisierung und begrenzte Operation |
Öffnen Sie die Clientübersicht und vergleichen Sie die Form Ihrer Konfigurationsdatei. Wählen Sie in der Konfigurationserstellung denselben Client. Übernehmen Sie eine Vorlage nur, wenn ihr Startweg zur dokumentierten Serverfassung passt. Ein geparstes JSON-Dokument belegt sein Format; es beweist nicht, dass ein Befehl vorhanden oder ein Endpunkt erreichbar ist.
Für die Suche nach Kandidaten können Sie die Registerkategorien stdio und Streamable HTTP nutzen. Die Zuordnung beruht auf den erfassten Angaben. Fehlende oder ältere Deklarationen sollten Sie an der Originalquelle prüfen. Ein Eintrag im Register ist kein laufender Verbindungstest und kein Versprechen über die heutige Erreichbarkeit.
Von der Entscheidung zum überprüften Ergebnis
Notieren Sie Client, Serverfassung und dokumentierten Transport. Prüfen Sie bei HTTP den vollständigen Pfad, bei stdio Befehl und Argumentliste.
Bereiten Sie eine unkritische Ressource und das erwartete Leseergebnis vor. Begrenzen Sie dafür Dateipfade oder Kontozugriffe auf das Nötige.
Initialisieren Sie die Verbindung und lesen Sie die Werkzeugliste. Ein fehlendes Werkzeug ist ein anderer Befund als ein fehlgeschlagener Prozessstart.
Führen Sie die vorbereitete Operation aus und vergleichen Sie das Ergebnis. Halten Sie Beobachtung und verbleibende Grenzen fest.
Bei Fehlern hilft die systematische Verbindungsdiagnose. Ein Wechsel des Transports sollte eine begründete Entscheidung sein. Wenn die Ursache ein falscher Dateipfad ist, behebt eine andere HTTP-Adresse den Fehler nicht. Ändern Sie einen Punkt nach dem anderen und wiederholen Sie denselben Test, damit Sie die Ursache nachvollziehen können.
- Ist stdio automatisch offline?
- Nein. Der Transport zwischen Client und Prozess sagt nichts darüber aus, welche externen Dienste der Server selbst aufruft.
- Ist HTTP automatisch ein Cloud-Dienst?
- Nein. Ein HTTP-Endpunkt kann auch auf Ihrem eigenen Rechner oder im internen Netz liegen.
- Sind SSE und Streamable HTTP dasselbe?
- Nein. Streamable HTTP kann SSE für Antworten nutzen, ist aber vom älteren HTTP+SSE-Transport zu unterscheiden.
- Welcher Transport ist grundsätzlich besser?
- Das lässt sich ohne Anforderungen nicht entscheiden. Maßgeblich sind Clientunterstützung, dokumentierter Serverweg und Ihr Betriebsmodell.
Offizielle Dokumentation geprüft am 1. Oktober 2026. Die Testpläne sind redaktionelle Vorschläge.
- MCP specification 2025-11-25: transports
Abrufbefehl anzeigen
curl -s https://modelcontextprotocol.io/specification/2025-11-25/basic/transports