Docker MCP Gateway

Docker MCP Gateway ist Dockers quelloffene, clientseitig erreichbare Gateway-Implementierung für Model Context Protocol. Es ist kein bloßes SDK und kein einzelnes Fachwerkzeug: Ein KI-Client verbindet sich mit einem Gateway, das registrierte MCP-Server startet, deren Werkzeuge bündelt, Anfragen weiterleitet und den Zugriff auf Zugangsdaten steuert. Der direkte Produktlink führt zur offiziellen Docker-Dokumentation; Quellcode und technische Details stehen im zugehörigen GitHub-Repository. Damit eignet sich das Gateway vor allem für Teams, die mehr als einen MCP-Server einsetzen wollen, ohne jede einzelne Verbindung, Container-Laufzeit und Geheimnisübergabe separat in Claude Code, Codex oder Cursor zu konfigurieren.

Gateway statt unkoordinierter Einzelserver

Einzelne MCP-Server sind schnell installiert, werden in größeren Setups aber unübersichtlich: Jede Client-Konfiguration enthält eigene Befehle, Tokens, Images und Rechte. Docker MCP Gateway bildet eine vermittelnde Schicht. Laut Docker verwaltet es Server-Lebenszyklen, Routing, Credentials und Zugriffskontrolle. Ein Client verbindet sich lokal üblicherweise über stdio mit docker mcp gateway run; das Gateway stellt dann die ausgewählten Tools der dahinterliegenden Server bereit. Für Netzwerkszenarien unterstützt es außerdem SSE und Streamable HTTP. Docker beschreibt den Betrieb über Docker Desktop mit MCP Toolkit, als docker mcp-CLI-Plugin auf Docker Engine oder mit Docker Compose.

Container, Zugriffsrechte und Geheimnisse

Der praktische Mehrwert liegt in der Betriebsgrenze. MCP-Server laufen laut Dokumentation in isolierten Containern mit eingeschränkten Privilegien, Ressourcen- und Netzwerkeinstellungen. Host-Umgebungsvariablen werden nicht standardmäßig weitergereicht. Geheimnisse werden einem einzelnen deklarierenden Server zugeordnet, statt pauschal an alle Container verteilt zu werden. Die Option --block-secrets ist standardmäßig aktiv und prüft Werkzeugargumente und Antworten auf geheimnisähnliche Werte. Das ist eine Schutzschicht, keine Zusage, dass jedes Geheimnis zuverlässig erkannt wird: Zugänge sollten weiter minimal berechtigt sein und nur für den tatsächlich benötigten Server hinterlegt werden.

Bei HTTP-Transporten verlangt das Gateway laut Sicherheitsdokumentation standardmäßig einen Bearer-Token, der über MCP_GATEWAY_AUTH_TOKEN gesetzt oder erzeugt wird. Die Option --allow-unauthenticated entfernt diese Schranke und ist für produktive, erreichbare Endpunkte keine sinnvolle Voreinstellung. Der Health-Endpunkt bleibt absichtlich ohne Authentifizierung. Auch Netzwerkzugriff ist nicht automatisch vollständig blockiert; wer ausgehende Verbindungen beschränken muss, konfiguriert dies bewusst über Blockierungs- oder Allowlist-Optionen. Für Drittanbieter-Images außerhalb der Docker-Signatur-Namensräume gelten nicht dieselben Signaturprüfungen wie für offizielle Images.

Clients und typische Einsätze

Docker dokumentiert die Einbindung in Claude Code, OpenAI Codex und Cursor jeweils ausdrücklich. Nach der Verbindung kann ein Team etwa einen Dokumentationsserver, einen Datenbankserver und einen Cloud-Server zentral aktivieren, während der Agent weiterhin nur einen MCP-Endpunkt sieht. Das reduziert Konfigurationsduplikate, ersetzt aber keine sorgfältige Werkzeugauswahl: Ein Gateway kann Rechte nicht sicherer machen als die eingebundenen Server und Tokens es erlauben. Besonders sinnvoll ist es für Entwicklerteams, die standardisierte Agentenarbeitsplätze oder mehrere MCP-Server über Docker Desktop und Compose betreiben.

Lizenz, Version und GitHub-Sterne

Das Repository steht unter MIT-Lizenz. Die GitHub-API meldete am 07.09.2026 1.556 Sterne; diese Momentaufnahme ist kein Sicherheits- oder Qualitätsnachweis. Der neueste Tag war v0.43.3; GitHub führte dabei keinen separaten Latest-Release-Datensatz. Das Gateway selbst ist quelloffen. Kosten können aus Docker-Produkten, der Infrastruktur oder aus den hinter dem Gateway verwendeten Diensten entstehen; dafür gelten jeweils die offiziellen Anbieterbedingungen.

Für wen sich Docker MCP Gateway lohnt

Das Gateway lohnt sich, wenn mehrere MCP-Server wiederholbar, containerisiert und mit klaren Grenzen an verschiedene Coding-Clients verteilt werden sollen. Für einen einzigen lokalen, vertrauenswürdigen Server ist der zusätzliche Layer oft nicht nötig. Starte mit einem kleinen, lesenden Toolset, prüfe Container-Images und Logs und erweitere Rechte erst nach einem nachvollziehbaren Test. So bleibt das Gateway eine Betriebsvereinfachung statt einer neuen, unkontrollierten Sammelstelle für Zugriffe.

Docker Desktop mit MCP Toolkit oder Docker Engine/Compose sowie ein MCP-Client.

Docker MCP Toolkit aktivieren oder Gateway mit Docker Compose betreiben. Den Client über docker mcp gateway run verbinden und zunächst nur freigegebene, lesende Server aktivieren.

docker mcp gateway run

Stdio läuft lokal. Für HTTP ist standardmäßig ein Bearer-Token erforderlich.

Rechte ergeben sich aus eingebundenen Servern, Secrets, Mounts und Netzwerkregeln.

Werkzeugaufrufe werden an die eingebundenen Server geroutet. Docker dokumentiert standardmäßig Metadaten-Logging, aber keine allgemeine Datenresidenz-Zusage.

Ungeprüfte Images, zu breite Tokens, Mounts oder Netzwerkfreigaben erweitern die Angriffsfläche. HTTP nie unbeabsichtigt unauthentifiziert bereitstellen.