Die 10 besten MCP-Gateways und Proxys für lokale KI im Jahr 2026

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Top 10 MCP Gateways and Proxies for Local AI in 2026 - Zima Store Online

Ein MCP-Server ist unkompliziert. Zehn davon können jeden KI-Client in ein Durcheinander aus Endpunkten, Token, Tool-Schemas, Transportbesonderheiten und doppelten Berechtigungen verwandeln.

Ein MCP-Gateway platziert einen zentralen Kontrollpunkt dazwischen. Deine Agenten verbinden sich einmal; das Gateway steuert, welche Server sie erreichen dürfen, welche Tools sie sehen, wie Zugangsdaten eingeschleust werden und wie jeder Tool-Aufruf weitergeleitet oder protokolliert wird.

Was ist ein MCP-Gateway und warum braucht lokale KI eines?

Das Model Context Protocol bietet KI-Clients eine standardisierte Möglichkeit, Tools, Ressourcen und Prompts zu entdecken und aufzurufen. Das Protokoll erfordert nicht, dass jede Bereitstellung über ein Gateway verfügt.

Wenn du einen KI-Client und ein oder zwei MCP-Server betreibst, sind direkte Verbindungen in der Regel einfacher:

KI-Client
   |
   +---- Dateisystem-MCP
   |
   +---- GitHub-MCP

Das Problem tritt auf, wenn sich beide Seiten vervielfachen.

Claude Code ----\
Codex -----------\
OpenClaw ---------> MCP-Gateway
Cline ------------/      |
                     +----+-------+-------+
                     |            |       |
                  GitHub       Dateien    Datenbank
                    MCP         MCP       MCP

Anstatt GitHub-, Dateisystem-, Datenbank-, Browser-, Automatisierungs- und interne MCP-Server in jedem Client separat zu konfigurieren, wird das Gateway zur gemeinsamen Kontrollebene.

Dies ist besonders nützlich für lokale KI-Agenten. Das Modell kann auf deiner eigenen Hardware ausgeführt werden, aber sobald es privilegierte Tools aufrufen kann, löst die lokale Ausführung allein weder Authentifizierung und Autorisierung noch Isolation oder Auditierung.

Die wichtigere architektonische Frage lautet:

Modellabsicht
     |
     v
MCP-Gateway
     |
Authentifizierung / Richtlinien / Tool-Filter
Zugangsdaten / Protokolle / Routing
     |
     v
Privilegierte Tools

Diese Gateway-Ebene steht in engem Zusammenhang mit der Vertrauensgrenze bei der Tool-Ausführung: Ein Modell kann eine Aktion anfordern, aber eine separate Ausführungsebene sollte entscheiden, ob diese Aktion tatsächlich zulässig ist.

Wie wir die besten MCP-Gateways und Proxys bewertet haben

Dies ist keine Rangliste nach GitHub-Sternen, und die zehn Projekte lösen nicht alle exakt dasselbe Problem.

Einige sind vollständige MCP-Plattformen. Andere sind Sicherheits-Gateways, Aggregatoren, Agent-Gateways oder leichtgewichtige Transport-Proxys. Wir haben sie anhand der Aspekte bewertet, die für lokale und selbst gehostete KI am wichtigsten sind:

Selbsthosting: Kannst du das Gateway auf einer Infrastruktur betreiben, die du kontrollierst?
MCP-Aggregation: Können mehrere MCP-Server hinter einem einzigen Endpunkt erscheinen?
Tool-Filterung: Kannst du begrenzen, welche Tools ein Agent tatsächlich sieht?
Authentifizierung und Autorisierung: Unterstützt es die Client-Identität, OAuth, Token, RBAC, ACLs oder Richtlinien-Engines?
Verwaltung von Zugangsdaten: Können Geheimnisse zentralisiert werden, anstatt sie in jeden KI-Client zu kopieren?
Transportunterstützung: Funktioniert es über stdio, SSE, Streamable HTTP oder andere Bereitstellungsmuster?
Isolation: Können MCP-Server oder Tool-Ausführungen vom Host getrennt werden?
Beobachtbarkeit: Sind Protokolle, Traces, Metriken oder Prüfprotokolle verfügbar?
Flexibilität bei der Bereitstellung: Eignet es sich für einen Laptop, Heimserver, Docker-Host, eine VM oder einen Kubernetes-Cluster?
Aktuelle Ausrichtung: Ist das Projekt für den sich schnell wandelnden MCP-Stack von 2026 noch relevant?

Die numerische Reihenfolge ist redaktionell und stellt keinen synthetischen Benchmark-Wert dar.

Die 10 besten MCP-Gateways und Proxys für lokale KI auf einen Blick

Rang	Gateway / Proxy	Am besten geeignet für	Self-Hosted	Aggregation	Sicherheit / Richtlinien	Wichtiger Unterschied
1	Docker MCP Gateway	Lokale KI auf Docker-Basis	Ja	Ja	Stark	Container-Isolation und Lebenszyklusverwaltung
2	ToolHive	Verwaltete, selbst gehostete MCP-Plattformen	Ja	Ja	Stark	Gateway + Registry + Laufzeitumgebung + Portal
3	agentgateway	Einheitliche Agenteninfrastruktur	Ja	Ja	Stark	MCP-, LLM- und A2A-Gateway
4	MCPJungle	Einfacher gemeinsamer MCP-Endpunkt	Ja	Ja	Moderat bis stark	Reibungsloser Übergang von lokal zu teamweit
5	IBM ContextForge	Protokoll- und API-Föderation	Ja	Ja	Stark	MCP-, A2A- und REST/gRPC-Föderation
6	Microsoft MCP Gateway	MCP-Infrastruktur für Kubernetes	Ja	Ja	Stark	Sitzungsbewusstes Routing und Lebenszyklusverwaltung
7	OpenZiti MCP Gateway	Zero-Trust-Zugriff auf entfernte MCPs	Ja	Ja	Stark	Keine öffentlichen Ports erforderlich
8	MetaMCP	Reduzierung des Kontexts von Tool-Schemas	Ja	Ja	Fokussiert	Fasst viele MCP-Tools in vier Meta-Tools zusammen
9	Kong AI Gateway	Vorhandene Enterprise-Gateway-Stacks	Ja, abhängig von der Bereitstellung	Ja	Stark	Governance für APIs, KI und MCP
10	Supergateway	MCP-Transportkonvertierung	Ja	Eingeschränkt	Grundlegend	stdio ↔ Streamable HTTP / SSE / WebSocket

1. Docker MCP Gateway — Insgesamt beste Wahl für lokale KI auf Docker-Basis

Docker MCP Gateway: Einheitliche, sichere Infrastruktur für agentische KI Docker MCP Gateway: Open-Source-Infrastruktur für sichere agentische KI | Docker

Docker MCP Gateway ist einer der naheliegendsten Ausgangspunkte für eine lokale KI-Umgebung, da MCP-Server letztlich Programme sind, die einen sicheren und vorhersehbaren Ausführungsort benötigen.

Das Docker-Gateway sitzt zwischen KI-Clients und MCP-Servern und zentralisiert Konfiguration, Zugangsdaten, Routing, Authentifizierung sowie die Verwaltung des Server-Lebenszyklus.

Die wichtigste Funktion für Self-Hosting-Nutzer ist die Isolation. Anstatt jeden MCP-Server und seine Abhängigkeiten direkt auf dem Host zu installieren, kann Docker Server in eingeschränkten Containern ausführen und dabei Berechtigungen, Netzwerkzugriff, CPU-Ressourcen und Geheimnisse kontrollieren.

Das Gateway kann außerdem nur ausgewählte Tools bereitstellen, anstatt sämtliche Tools aller Server in den Client zu laden. Die MCP-Tools von Docker umfassen Profil- und Tool-Steuerungen, die dazu dienen, Unübersichtlichkeit und unnötigen Token-Verbrauch zu reduzieren.

Ein Client kann sich mit einem Gateway verbinden:

{
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"]
    }
  }
}

während Docker die dahinter laufenden MCP-Server-Prozesse verwaltet.

Das passt besonders gut zu einem Heimserver:

Claude Code / Codex / Cline
            |
     Docker MCP Gateway
            |
    +-------+-------+
    |       |       |
 Dateisystem GitHub  n8n
 Container  Server  Server

Am besten für: lokale KI-Nutzer, die bereits Docker einsetzen und ein Gateway sowie isolierte MCP-Server-Ausführung, Geheimnisverwaltung, Tool-Filterung und zentralisierte Protokolle wünschen.

Kompromiss: Docker bietet inzwischen mehrere verwandte MCP-Funktionen, darunter MCP Toolkit, Gateway, Sandboxes und neuere Governance-Funktionen. Einige Funktionen der Docker-KI-Governance sind separat eingeschränkt. Überprüfe daher, welche Funktionen deine Bereitstellung tatsächlich umfasst, anstatt anzunehmen, dass jede Docker-MCP-Funktion in jeder Edition verfügbar ist.

2. ToolHive — Am besten für die vollständige selbst gehostete MCP-Verwaltung

GitHub – stacklok/toolhive: ToolHive ist eine Plattform auf Unternehmensniveau zum Ausführen und Verwalten von Model-Context-Protocol-(MCP-)Servern. · GitHub

ToolHive geht weit über einen schlanken Proxy hinaus.

Die Architektur ist in mehrere Ebenen aufgeteilt:

Gateway: stellt Clients kontrollierte MCP-Endpunkte bereit;
Registry: verwaltet einen Katalog genehmigter MCP-Server und Fähigkeiten;
Laufzeit: stellt MCP-Server bereit und betreibt sie;
Portal: stellt eine Verwaltungs- und Erkennungsoberfläche bereit.

Das Gateway kann mehrere Tools aggregieren, Identitätsanbieter über OAuth/OIDC integrieren, Zugriffsrichtlinien anwenden, Tools und Beschreibungen filtern und die Protokollierung zentralisieren.

Die Laufzeit kann MCP-Server lokal über Docker oder Podman starten, während der Kubernetes-Operator denselben Ansatz auf größere Cluster ausweitet. Die Unterstützung für OpenTelemetry und Prometheus sorgt für eine deutlich bessere Betriebsperspektive als bei einem einfachen Reverse-Proxy.

Dadurch ist ToolHive besonders für Teams interessant. Entwickler müssen nicht mehr nach einem beliebigen MCP-Repository suchen, es manuell installieren, Zugangsdaten in eine Client-Konfiguration einfügen und hoffen, dass alle anderen dieselbe Einrichtung korrekt wiederholen.

Stattdessen:

Vertrauenswürdige Registry
      |
    Laufzeit
      |
 MCP-Server
      |
   Gateway
      |
+-----+------+------+
Claude     Codex   VS Code

Am besten für: Teams, die MCP-Erkennung, Bereitstellung, Sicherheit, Richtlinien, Beobachtbarkeit und Gateway-Zugriff in einer selbst gehosteten Plattform vereinen möchten.

Kompromiss: ToolHive ist deutlich umfangreicher, als ein Setup für einen einzelnen Benutzer benötigt. Wenn du nur fünf Server hinter einem Endpunkt betreiben möchtest, ist MCPJungle einfacher.

3. agentgateway — Am besten für MCP-, LLM- und Agent-zu-Agent-Datenverkehr in einer Ebene

Agentgateway v1.0.x – agentgateway | Agent-Konnektivität gelöst

agentgateway ist eines der wichtigsten Projekte, die man im Auge behalten sollte, weil es eine umfassendere Frage stellt:

Warum sollte man ein Gateway für MCP, ein weiteres für LLM-APIs und noch eines für Agent-zu-Agent-Datenverkehr entwickeln?

Seine Architektur vereint drei zunehmend wichtige Datenverkehrsklassen:

Agent
  |
  +--> LLM-Gateway
  |
  +--> MCP-Gateway
  |
  +--> A2A-Gateway

Für MCP unterstützt es die Föderation von Tools sowie die Transporte stdio, HTTP, SSE und Streamable HTTP. Zu den Authentifizierungsoptionen gehören OAuth, JWT und API-Schlüssel, während fein abgestufte RBAC, Ratenbegrenzung, TLS und OpenTelemetry die Governance-Ebene bereitstellen.

Es hat außerdem einen direkten Bezug zu lokaler KI: agentgateway kann Inferenz an selbst gehostete Modelle und Kubernetes-Inferenzinfrastrukturen weiterleiten, statt davon auszugehen, dass jeder Modellaufruf an einen Cloud-Anbieter geht.

Das Projekt passt sich außerdem aktiv an neuere Generationen des MCP-Protokolls an, einschließlich der deutlich umfangreicheren Protokolländerungen von 2026 und des Kompatibilitätsproblems, das entsteht, wenn Clients und Server zu unterschiedlichen Zeitpunkten aktualisiert werden.

Am besten geeignet für: fortgeschrittene Self-Hosted-KI-Infrastrukturen, in denen Agenten eine einheitliche Konnektivitätsebene für Modelle, Tools und andere Agenten benötigen.

Kompromiss: Wenn dein einziges Problem darin besteht, einige wenige lokale MCP-Server zu konsolidieren, ist agentgateway möglicherweise eine umfangreichere Architektur, als du benötigst.

4. MCPJungle — Das beste einfache Self-Hosted-Gateway für mehrere MCP-Server

🚀 MCPJungle wird heute vorgestellt. Heute habe ich ein Projekt als Open Source veröffentlicht, an dem ich schon eine Weile gearbeitet habe. SZENARIO Du stellst KI-Agenten in deinem Unternehmen bereit. Verschiedene Teams in deiner Organisation stellen ihre internen… |

MCPJungle ist wahrscheinlich das am einfachsten zu erklärende Projekt auf dieser Liste:

Registriere deine MCP-Server einmal und lasse dann deine KI-Clients eine Verbindung zu einem einzigen Endpunkt herstellen.

GitHub MCP ------\
Postgres MCP -----\
Filesystem MCP ----> MCPJungle ----> /mcp
Browser MCP -------/                    |
n8n MCP ----------/          +----------+---------+
                              Claude   Cursor   Codex

Das Projekt unterstützt entfernte MCP-Server und MCP-Server über stdio und bietet gleichzeitig eine einheitliche Erkennung von Tools, Prompts und Ressourcen.

Mit Tool Groups kannst du für einen bestimmten Anwendungsfall nur eine kuratierte Teilmenge der verfügbaren Tools bereitstellen, statt jedem Client den gesamten Tool-Katalog zu geben.

MCPJungle bietet außerdem eine sinnvolle Entwicklung von persönlicher zu gemeinsam genutzter Infrastruktur. Du kannst mit Docker Compose und einem lokalen Endpunkt beginnen und später zu Client-Identitäten, Zugriffstoken, expliziten Server-Allowlists, PostgreSQL und OpenTelemetry übergehen, sobald die Bereitstellung wichtiger wird.

Dadurch eignet es sich besonders gut für ein Home-Lab. Du musst nicht mit der Installation von Kubernetes oder dem Aufbau einer Identitätsarchitektur für Unternehmen beginnen.

Am besten für: Entwickler und kleine Teams, die einen übersichtlichen MCP-Endpunkt wünschen, ohne eine deutlich größere KI-Infrastrukturplattform einzuführen.

Kompromiss: Fortgeschrittene Governance-Funktionen sind an produktions- oder unternehmensorientierte Modi gebunden, und sein Sicherheitsmodell ist nicht so umfassend wie das von ToolHive, agentgateway oder einem ausgereiften API-Gateway.

5. IBM ContextForge – Am besten für die Föderation von MCP mit bestehenden APIs und Agents

GitHub – IBM/mcp-context-forge: Ein KI-Gateway, eine Registry und ein Proxy, der vor beliebigen MCP-, A2A- oder REST-/gRPC-APIs sitzt und einen einheitlichen Endpunkt mit zentralisierter Erkennung, Schutzvorgaben und Verwaltung bereitstellt. Optimiert Agent

IBM ContextForge wird besonders nützlich, wenn deine Infrastruktur nicht sauber aus MCP-Servern aufgebaut ist.

In realen Umgebungen findet sich normalerweise eine Mischung:

MCP-Server
REST-API
gRPC-Dienst
A2A-Agent
Legacy-interne API
       |
       v
  ContextForge
       |
       v
   KI-Clients

ContextForge fungiert als Registry-, Proxy- und Föderationsebene für MCP-, A2A-, REST- und gRPC-Dienste.

Die aktuelle Architektur umfasst Gateway-Funktionen für Tools, API-Übersetzung, Agent-Routing, erweiterbare Plugins, Ratenbegrenzung, Authentifizierung, Wiederholungsversuche und auf OpenTelemetry basierende Beobachtbarkeit.

Das Projekt erreichte 2026 den Meilenstein der allgemeinen Verfügbarkeit (1.0) mit zusätzlicher Sicherheitshärtung, Protokollarbeit, Katalogverbesserungen und produktionsorientierten Änderungen an der Bereitstellung.

Es kann über Python-Pakete oder Docker betrieben werden und bis hin zu Kubernetes- und Multi-Cluster-Bereitstellungen skaliert werden.

Am besten für: Organisationen oder fortgeschrittene Home-Labs, die bestehende REST-/gRPC-Systeme für Agents verfügbar machen möchten, ohne jeden Dienst als dedizierten MCP-Server neu zu schreiben.

Kompromiss: ContextForge ist umfassender als ein reines MCP-Gateway. Diese Flexibilität bringt im Vergleich zu MCPJungle oder Supergateway zusätzliche betriebliche Komplexität mit sich.

6. Microsoft MCP Gateway – Am besten für Stateful-MCP-Server unter Kubernetes

GitHub – microsoft/mcp-gateway: MCP Gateway ist ein Reverse-Proxy und eine Verwaltungsebene für MCP-Server und ermöglicht skalierbares, sitzungsbewusstes Stateful-Routing sowie die Verwaltung des MCP-Server-Lebenszyklus in Kubernetes-Umgebungen. · GitHub

Microsoft MCP Gateway ist besonders relevant, wenn die MCP-Server selbst zu verwalteter Infrastruktur werden müssen.

Das Projekt kombiniert ein Datengateway mit einer Steuerungsebene.

Die Datenschicht leitet den MCP-Datenverkehr weiter, während die Verwaltungsschicht Server als verwaltete Ressourcen darstellen und Bereitstellungs-, Aktualisierungs- und Löschvorgänge übernehmen kann.

Sein herausragendes Merkmal ist zustandsbehaftetes Routing mit Sitzungsbezug.

Einige MCP-Server sind keine austauschbaren zustandslosen HTTP-Endpunkte. Eine Clientsitzung muss möglicherweise weiterhin dieselbe Backend-Instanz erreichen. Das Microsoft MCP Gateway kann Anfragen mit derselben Sitzungs-ID wieder an dieselbe Serverinstanz weiterleiten und gleichzeitig mehrere Instanzen hinter dem Gateway zulassen.

Client-Sitzung A ----> Gateway ----> MCP-Pod 1
Client-Sitzung A ----> Gateway ----> MCP-Pod 1

Client-Sitzung B ----> Gateway ----> MCP-Pod 2

Das Projekt umfasst außerdem Autorisierung, Telemetrie, Zugriffskontrollintegration und Lebenszyklusmanagement, die auf Kubernetes-Umgebungen ausgelegt sind.

Am besten geeignet für: Teams, die bereits Kubernetes verwenden und zustandsbehaftete oder dynamisch verwaltete MCP-Server-Flotten betreiben.

Kompromiss: Für einen einzelnen Heimserver ist dies nicht die naheliegendste Wahl. Docker MCP Gateway oder MCPJungle lassen sich normalerweise deutlich einfacher betreiben.

7. OpenZiti MCP Gateway — Am besten geeignet für Zero-Trust-Remotezugriff auf private MCP-Tools

Wir haben ein Open-Source-LLM-Gateway und MCP-Gateway auf Basis von OpenZiti und zrok veröffentlicht: r/OpenSourceeAI

OpenZiti MCP Gateway löst eines der praktischsten Probleme lokaler KI:

Was passiert, wenn sich der Agent und der MCP-Server nicht im selben LAN befinden?

Eine typische private Einrichtung sieht so aus:

Laptop / KI-Client
        |
      Internet
        |
 Heimserver / NAS
        |
 Private MCP-Tools

Die konventionelle Lösung besteht häufig darin, einen HTTPS-Endpunkt bereitzustellen, Firewall-Regeln zu konfigurieren, ein VPN einzurichten oder einen weiteren Reverse-Proxy vor den Dienst zu setzen.

OpenZiti verfolgt stattdessen einen Zero-Trust-Overlay-Ansatz. Sein MCP Gateway kann interne Tools als „Dark Services“ bereitstellen, die nicht auf öffentlichen IP-Adressen lauschen und keine herkömmliche Portweiterleitung erfordern.

Kryptografische Identitäten, mTLS, Isolation pro Client und Kontrollen auf Tool-Ebene bilden die Zugriffsschicht. Das Projekt kann außerdem mehrere Backends zusammenführen und lokale Stdio-Server als remote zugängliche MCP-Dienste bereitstellen.

Das ist besonders relevant für einen privaten KI-Agenten-Arbeitsbereich, in dem die Agentenlaufzeit, Dateien und Dienste auf einem ständig aktiven Heimserver liegen, aber sicher von einem anderen Gerät aus erreichbar sein müssen.

Am besten geeignet für: Nutzer, die remote auf private MCP-Tools zugreifen möchten, ohne diese Tools direkt dem öffentlichen Internet auszusetzen.

Kompromiss: Sie übernehmen das OpenZiti/zrok-Netzwerkmodell als Teil der Lösung. Wenn ein herkömmliches privates LAN oder ein vorhandenes VPN das Verbindungsproblem bereits löst, ist dies möglicherweise unnötig.

8. MetaMCP — Am besten zur Reduzierung des Kontext-Overheads von Werkzeugschemas

MetaMCP-Dokumentation – MetaMCP

MetaMCP löst ein anderes MCP-Skalierungsproblem.

Angenommen, ein Agent verbindet sich direkt mit:

Playwright-MCP      52 Werkzeuge
Datenbank-MCP        20 Werkzeuge
GitHub-MCP          30 Werkzeuge
Dateisystem-MCP      15 Werkzeuge
Monitoring-MCP      18 Werkzeuge

Das Modell muss möglicherweise zunächst eine große Sammlung von JSON-Werkzeugschemas erhalten, bevor es überhaupt mit sinnvoller Arbeit beginnt.

Das verbraucht Kontext und kann die Werkzeugauswahl unübersichtlicher machen.

MetaMCP stellt diese untergeordneten Server hinter einer kleinen, stabilen Schnittstelle bereit. Das aktuelle Design stellt vier zentrale Meta-Werkzeuge für Erkennung, Bereitstellung, Aufruf und mehrstufige Ausführung bereit, anstatt die Schemas aller nachgelagerten Werkzeuge direkt offenzulegen.

Die Architektur sieht dann so aus:

               +-- Playwright
               +-- GitHub
Lokales LLM --> MetaMCP -- Datenbank
               +-- Dateien
               +-- Weitere Server

Das Modell sieht: 4 Meta-Werkzeuge

Das ist besonders für lokale Modelle interessant. Moderne Cloud-Modelle verfügen zunehmend über große Kontextfenster und eine zuverlässige Werkzeugauswahl, aber kleinere selbst gehostete Modelle reagieren möglicherweise empfindlicher auf die Prompt-Größe und umfangreiche Werkzeugkataloge.

Die Dokumentation von MetaMCP zeigt, wie der Schema-Overhead ungefähr konstant bleiben kann, wenn zusätzliche untergeordnete MCP-Server hinzugefügt werden, anstatt mit jedem nachgelagerten Werkzeug linear zu wachsen.

Am besten für: lokale KI-Bereitstellungen mit vielen MCP-Servern, bei denen Werkzeugschemas zu viel Kontext verbrauchen oder die Auswahl der Modellwerkzeuge erschweren.

Kompromiss: Die Abstraktion verändert, wie das Modell mit Werkzeugen interagiert. Sie gewinnen Kontexteffizienz, fügen jedoch eine weitere Erkennungs- und Routing-Schicht zwischen dem Modell und den tatsächlichen MCP-Werkzeugen hinzu.

9. Kong AI Gateway — Am besten, wenn Sie bereits ein API-Gateway betreiben

Kong Gateway | Kong-Dokumentation

Kong AI Gateway verfolgt einen anderen Ansatz als die oben genannten, primär auf Heimlabore ausgerichteten Projekte.

Wenn Ihre Organisation Kong bereits für APIs, Authentifizierung, Routing oder Service-Governance einsetzt, kann die Integration von MCP in dieselbe Steuerungsebene attraktiver sein als die Bereitstellung einer vollständig separaten MCP-Plattform.

Kongs aktuelle KI-Gateway-Architektur erkennt MCP und A2A neben herkömmlichem Modellverkehr. Die MCP-Serverkonfiguration unterstützt Aggregation und Zugriffskontrolle auf Werkzeugebene, während bestehende Gateway-Funktionen Authentifizierung, Routing, Metriken und eine umfassendere Governance ermöglichen.

Ein nützliches Muster sieht folgendermaßen aus:

KI-Clients
     |
Kong AI Gateway
     |
+----+-------+--------+
|            |        |
MCP A    MCP B    REST-API
|            |
Tools       Tools

Dies ist besonders wertvoll, wenn dieselbe Plattform bereits normale Anwendungs-APIs und den Datenverkehr von KI-Modellen verwaltet.

Am besten geeignet für: Teams, die Kong bereits einsetzen und MCP-Governance in eine bestehende API- und KI-Gateway-Strategie integrieren möchten.

Kompromiss: Die Verfügbarkeit der MCP-Funktionen von Kong variiert je nach Bereitstellung und Produktkonfiguration, und einige neuere Rezepte für sicheres MCP unterliegen derzeit Konnect-spezifischen Einschränkungen. Für einen kleinen lokalen Docker-Server ist dies nicht die einfachste Wahl.

10. Supergateway – Beste schlanke MCP-Transportbrücke

Aktivität · supercorp-ai/supergateway · GitHub

Supergateway gehört aus einem deutlich engeren Grund auf diese Liste: Transportkompatibilität.

Ein großer Teil der frühen MCP-Software basierte auf stdio. Das ist praktisch, wenn der MCP-Server als untergeordneter Prozess auf demselben Rechner wie der KI-Client läuft.

Es wird umständlich, wenn der Server auf einem NAS, einer VM, einem Container-Host oder einem anderen Rechner im Netzwerk laufen soll.

Supergateway kann zwischen MCP-Transporten überbrücken, darunter:

stdio
  |
  +--> SSE
  |
  +--> WebSocket
  |
  +--> Streamable HTTP

und es kann entferntes Streamable HTTP wieder in stdio umwandeln, damit Clients, die weiterhin einen lokalen Prozess erwarten, darauf zugreifen können.

Beispielsweise kann ein lokaler stdio-Dateisystemserver als Streamable HTTP bereitgestellt werden:

npx -y supergateway \
  --stdio "npx -y @modelcontextprotocol/server-filesystem ./data" \
  --outputTransport streamableHttp \
  --port 8000

Es unterstützt außerdem Header, Bearer-Authentifizierung, Health-Endpunkte, zustandsbehaftete Streamable-HTTP-Sitzungen und mehrere Bereitstellungsoptionen.

Am besten geeignet für: Entwickler, die bereits funktionierende MCP-Server haben, aber Unterschiede bei den Transportprotokollen zwischen lokalen und entfernten Clients überbrücken müssen.

Kompromiss: Supergateway ist ein Transport-Proxy und keine vollständige Governance-Plattform. Es ist kein Ersatz für ToolHive, Docker MCP Gateway oder agentgateway, wenn Sie zentrale Richtlinien, Identitäts-, Lebenszyklus- und Auditverwaltung benötigen.

Welches MCP-Gateway sollten Sie wählen?

Wenn Sie Folgendes benötigen ...	Beginnen mit	Warum
Lokale MCP-Server auf Docker-Basis	Docker MCP Gateway	Container-Isolierung, Lebenszyklus, Secrets, Profile und Tool-Filterung
Eine vollständige MCP-Managementplattform	ToolHive	Gateway, Registry, Laufzeit, Richtlinien und Portal in einem Stack
MCP-, Modell- und Agent-zu-Agent-Routing	agentgateway	Vereinheitlicht drei Ebenen des Agentenverkehrs
Ein einfacher, selbst gehosteter MCP-Endpunkt	MCPJungle	Reibungslose Aggregation mit einem klaren Upgrade-Pfad für Teams
REST, gRPC, MCP und Agenten zusammen	IBM ContextForge	Föderiert vorhandene APIs, statt eine ausschließlich auf MCP basierende Infrastruktur vorauszusetzen
MCP-Flotten in Kubernetes	Microsoft MCP Gateway	Sitzungsbewusstes Routing und Verwaltung des Server-Lebenszyklus
Remote-Tools in privaten Netzwerken ohne offene Ports	OpenZiti MCP Gateway	Zero-Trust-Overlay-Konnektivität
Weniger Tool-Schemas im Modellkontext	MetaMCP	Große Tool-Kataloge zu Meta-Tools zusammenfassen
MCP-Governance innerhalb eines bestehenden API-Gateways	Kong AI Gateway	Nutzt etablierte Authentifizierungs-, ACL-, Routing- und Gateway-Infrastruktur
stdio- / HTTP-Transportkonvertierung	Supergateway	Einfache Transportbrücke ohne vollständige Plattform

Docker MCP Gateway vs. ToolHive vs. MCPJungle

Dies sind drei der relevantesten Optionen für eine selbst gehostete Umgebung, sie richten sich jedoch an unterschiedliche Komplexitätsstufen.

Bereich	Docker MCP Gateway	ToolHive	MCPJungle
Hauptidee	Containerisierte MCP-Server ausführen und verwalten	Eine MCP-Plattform betreiben	Viele MCP-Server hinter einem Endpunkt zusammenfassen
Für Home-Labs geeignet	Hervorragend	Gut	Hervorragend
Server-Isolation	Starke Docker-Integration	Docker / Podman / Kubernetes	Von der Bereitstellung abhängig
Registry	Docker-MCP-Ökosystem	Erstklassige Registry	Katalog registrierter Server
Identität / Richtlinien	Umfangreiche Kontrollen	Stark, auf Teams ausgerichtet	Zugriffskontrolle für Clients
Observability	Protokollierung und Tracing	OpenTelemetry / Prometheus	OpenTelemetry-Optionen
Am besten geeignet für	Docker-Nutzer	Teams / Plattform-Engineering	Persönlicher Server bis kleines Team

Wählen Sie Docker MCP Gateway, wenn Docker bereits die Grundlage Ihres selbst gehosteten KI-Stacks bildet und Container-Isolation wichtig ist.

Wählen Sie ToolHive, wenn mehrere Entwickler einen vertrauenswürdigen MCP-Katalog, zentrale Bereitstellung, Identitätsintegration, Richtlinien und Monitoring benötigen.

Wählen Sie MCPJungle, wenn Ihr Hauptproblem einfach darin besteht, dass Claude, Codex, Cursor und andere Clients nicht mehr doppelte MCP-Konfigurationen mitführen sollen.

MCP-Gateway vs. Proxy vs. Aggregator vs. Transportbrücke

Die Terminologie rund um die MCP-Infrastruktur ist noch uneinheitlich, daher können Produktnamen allein irreführend sein.

Ebene	Hauptaufgabe	Beispiel
Gateway	Zentraler Einstiegspunkt mit Routing, Identität, Sicherheit und Governance	Docker MCP Gateway, ToolHive
Proxy	MCP-Datenverkehr weiterleiten und dabei ausgewählte Kontrollen hinzufügen	Kong, schlanke Sicherheits-Proxys
Aggregator	Mehrere MCP-Server hinter einem Endpunkt zusammenfassen	MCPJungle
Meta-Router	Große nachgelagerte Tool-Kataloge hinter einer kleineren Schnittstelle verbergen	MetaMCP
Transportbrücke	stdio, SSE, Streamable HTTP oder andere Transporte umwandeln	Supergateway
Agent-Gateway	MCP sowie den Datenverkehr zwischen Modellen und Agenten verwalten	agentgateway, ContextForge

Ein Projekt kann mehrere dieser Aufgaben gleichzeitig übernehmen. Entscheidend ist nicht, wie das Repository sich selbst bezeichnet, sondern welches Steuerungsproblem es tatsächlich löst.

So erstellen Sie eine lokale MCP-Gateway-Architektur

Ein praktisches lokales Setup muss nicht mit einer riesigen Plattform beginnen.

Beginnen Sie mit vier Ebenen:

KI-Clients
Claude Code / Codex / OpenClaw
             |
             v
        MCP-Gateway
             |
    +--------+--------+
    |        |        |
 Dateien     GitHub   Automatisierung
 MCP       MCP       MCP
    |
Lokaler Speicher / NAS

Das Gateway nah an den Tools halten

Wenn die meisten MCP-Server auf lokale Dateien, Docker, Home Assistant, Datenbanken, Git-Repositories oder private APIs zugreifen, gehört das Gateway normalerweise in dasselbe vertrauenswürdige Servernetzwerk und nicht auf jeden Entwickler-Laptop.

Dies entspricht der Architektur eines privaten KI-Agenten-Arbeitsbereichs: Der Client kann wechseln, aber privater Speicher, Laufzeitumgebung, Protokolle und Automatisierungsdienste verbleiben auf einem ständig verfügbaren Host.

Modell-Hosting und MCP-Hosting trennen

Das MCP-Gateway muss nicht auf demselben Rechner wie das LLM laufen.

Agent-Host             GPU-Server
    |                       |
MCP-Gateway              Ollama
    |                     vLLM
Lokale Tools
    |
Dateien / DBs / APIs

Das ist wichtig, weil der MCP-Datenverkehr im Vergleich zur Inferenz normalerweise leichtgewichtig ist. Ein bescheidener Server, der ständig läuft, kann Gateway- und Tooldienste hosten, während eine Workstation oder ein GPU-Knoten das Modell verarbeitet.

Kuratierte Tool-Sets verwenden, statt alles bereitzustellen

Ein Coding-Agent benötigt wahrscheinlich keine Smart-Home-Steuerung. Ein Recherche-Agent benötigt wahrscheinlich keine Docker-Administration. Ein persönlicher Wissensassistent sollte nicht automatisch Zugriff auf Produktionsdatenbanken erhalten.

Separate Profile oder Toolgruppen erstellen:

coding
  - github
  - filesystem-dev
  - docs

research
  - browser
  - papers
  - local-knowledge

home-ops
  - monitoring
  - home-assistant
  - docker-readonly

Das passt natürlich zu lokalen KI-Workflows: Die MCP-Schicht bestimmt, welche Fähigkeiten vorhanden sind, während Skills und Agentenanweisungen festlegen, wie und wann diese Fähigkeiten genutzt werden sollen.

Warum Tool-Filterung für lokale Modelle wichtig ist

Sicherheit ist nur ein Grund, die Anzahl der Tools zu begrenzen.

Der Kontext ist ein weiterer Aspekt.

Jedes Tool kann einen Namen, eine Beschreibung, Argumente, ein JSON-Schema und weitere Metadaten zur dem Modell verfügbaren Tool-Oberfläche beitragen.

Bei einer Handvoll Tools ist das trivial.

Bei Hunderten kann dies Teil des Prompt-Budgets werden:

5 MCP-Server
x 20 Tools
= 100 Toolschemata

20 MCP-Server
x 20 Tools
= 400 Toolschemata

Dadurch kann der für Konversation, Repository-Code, abgerufene Dokumente, Schlussfolgerungen und Ausgaben verfügbare Kontext reduziert werden.

Das kann die Toolauswahl jedoch erschweren. Wenn ein Agent mehrere ähnlich benannte Such-, Abfrage-, Abruf-, Lese- oder Ausführungstools sieht, wird die Auswahl des richtigen Tools zu einer weiteren Denksaufgabe.

Es gibt drei Hauptlösungen:

Tool-Filterung: Nur die für einen bestimmten Agenten relevanten Tools bereitstellen.
Toolgruppen oder Profile: Verschiedenen Clients unterschiedliche Kataloge bereitstellen.
Meta-Routing: Eine kleine Discovery- und Aufrufschnittstelle bereitstellen und nachgelagerte Tools bei Bedarf auflösen.

Docker MCP Gateway und ToolHive legen den Schwerpunkt auf Filterung und kuratierte Bereitstellung. MCPJungle bietet Tool-Gruppen. MetaMCP geht am weitesten, indem es viele untergeordnete Tools in eine kleine, stabile Meta-Tool-Oberfläche überführt.

Das ist noch wichtiger, wenn MCP eine lokale Wissensdatenbank verbindet, weil Tool-Schemas nun mit Dokumenten und abgerufenem Kontext um dasselbe Modellfenster konkurrieren.

Sicherheits-Checkliste für MCP-Gateways für lokale KI

Ein Gateway ist nicht allein deshalb nützlich, weil der gesamte Datenverkehr durch es hindurchläuft. Sein Wert ergibt sich daraus, was das Gateway tatsächlich durchsetzt.

Den Client authentifizieren

Das Gateway sollte wissen, ob der Aufrufer Codex auf einem Entwicklerrechner, ein ständig laufender Agent, ein CI-Prozess oder ein anderer Dienst ist.

Behandle „innerhalb meines LANs“ nicht als Identität.

Server und Tools getrennt autorisieren

Der Zugriff auf den GitHub-MCP-Server bedeutet nicht zwangsläufig Zugriff auf jedes GitHub-Tool.

Eine sinnvolle Richtlinie kann Folgendes erlauben:

read_issue
list_pull_requests
search_code

und gleichzeitig Folgendes verweigern:

merge_pull_request
delete_repository
change_branch_protection

Zugangsdaten aus Agent-Konfigurationsdateien heraushalten

Einer der größten Vorteile eines Gateways besteht darin, API-Schlüssel und Dienstzugangsdaten aus den Konfigurationsdateien einzelner KI-Clients zu entfernen.

Der ideale Ablauf ist:

Agent
  |
Tool-Anfrage
  |
Gateway
  |
Begrenzte Zugangsdaten injizieren
  |
MCP-Server

Das Modell muss das zugrunde liegende Token nicht sehen.

Nicht vertrauenswürdige MCP-Server isolieren

Ein MCP-Server ist ausführbare Software.

Wenn ein Server aus einem Repository eines Drittanbieters installiert wird, solltest du ihn wie jede andere Softwareabhängigkeit behandeln. Überprüfe das Paket, fixiere nach Möglichkeit die Versionen, beschränke den Netzwerk- und Dateisystemzugriff und verwende gegebenenfalls Container oder eine andere Isolation.

Tool-Aufrufe protokollieren, nicht nur HTTP-Fehler

Wenn ein Agent eine Datei ändert oder ein externes System aktualisiert, benötigst du genügend Informationen, um Folgendes zu rekonstruieren:

welcher Client die Anfrage gestellt hat;
welches Tool ausgewählt wurde;
welche Argumente genehmigt wurden;
welches Ergebnis zurückgegeben wurde;
ob der Seiteneffekt tatsächlich abgeschlossen wurde.

Deshalb ist Beobachtbarkeit ein grundlegender Bewertungsfaktor und kein Zusatz, der nur für Unternehmen gedacht ist.

Umgehungspfade entfernen

Ein sorgfältig konfiguriertes MCP-Gateway definiert nicht die tatsächliche Sicherheitsgrenze, wenn derselbe Agent außerdem über Folgendes verfügt:

eine uneingeschränkte Host-Shell;
ein beschreibbarer Docker-Socket;
Administratorzugangsdaten;
direkter Root-Zugriff auf die Datenbank;
eine weitere uneingeschränkte MCP-Verbindung.

Die Vertrauensgrenze für die Tool-Ausführung ist nur dann relevant, wenn privilegierte Aktionen tatsächlich über sie laufen.

Brauchst du wirklich ein MCP-Gateway?

Wahrscheinlich nicht, wenn deine Einrichtung so aussieht:

Ein KI-Client
   |
Zwei MCP-Server

Das Hinzufügen eines Gateways würde einen weiteren Dienst schaffen, den Sie installieren, aktualisieren, absichern, überwachen und debuggen müssen.

Ein Gateway wird sinnvoll, wenn mehrere dieser Bedingungen erfüllt sind:

Sie verwenden mehrere KI-Clients;
Sie haben mehrere MCP-Server;
dieselben MCP-Server werden wiederholt konfiguriert;
Zugangsdaten werden auf Client-Rechnern dupliziert;
verschiedene Agenten sollten unterschiedliche Tools sehen;
Remote-Geräte benötigen Zugriff auf private MCP-Dienste;
Sie benötigen Audit-Protokolle;
einige MCP-Server sollten isoliert ausgeführt werden;
Tool-Schemas verbrauchen zu viel Modellkontext;
Sie müssen Stdio- und Netzwerktransporte verbinden;
Die Bereitstellung entwickelt sich zur gemeinsam genutzten Infrastruktur.

Eine nützliche Faustregel lautet:

1 Client + 2 Server
        ↓
Direktes MCP ist in Ordnung

Mehrere Clients + mehrere Server
        ↓
Das Gateway wird hilfreich

Teams + Zugangsdaten + Richtlinien + Audit
        ↓
Das Gateway wird zur Infrastruktur

Wo Soth MCP Proxy einzuordnen ist

Soth MCP Proxy ist ebenfalls einen Blick wert, insbesondere wenn Sie vorrangig eine Sicherheitsrichtlinienschicht vor einer bestehenden MCP-Bereitstellung platzieren möchten.

Das aktuelle Design umfasst die Durchsetzung von OPA-/Rego-Richtlinien, dauerhafte Audit-Protokollierung, Sitzungssteuerung, Prometheus-Metriken, Health-Endpunkte und TLS.

Das ist eine nützliche Architektur:

Agent
  |
Soth Policy Proxy
  |
Vorhandener MCP-Server

Wir haben es nicht in die primären Top 10 aufgenommen, da es sich noch in einer deutlich früheren Entwicklungsphase befindet als die meisten oben genannten Gateways und mehrere Transport- und Administrationsfunktionen noch Teil seiner Roadmap sind.

Betrachten Sie es vorerst eher als vielversprechenden, schlanken Sicherheits-Proxy denn als ausgereifte MCP-Managementplattform.

Der Wandel im Jahr 2026: Das MCP-Gateway wird zur Agenteninfrastruktur

Die ursprüngliche MCP-Frage lautete:

Wie verbinde ich meinen KI-Assistenten mit diesem Tool?

Die neuere Frage lautet:

Wie verwalte ich jedes Tool, das von jedem Agenten verwendet wird?

Das verändert die Architektur.

2025

Agent
  |
MCP-Server
  |
Tool


2026

Agenten
  |
Agenten-/MCP-Gateway
  |
Identität
Richtlinie
Routing
Zugangsdaten
Tool-Erkennung
Observability
Protokollübersetzung
  |
Viele MCP-Server
  |
APIs / Dateien / Datenbanken / Dienste

Deshalb beschränken sich Projekte wie agentgateway und ContextForge nicht mehr auf MCP. Sie erweitern sich auch in Richtung Modell-Routing und Agent-zu-Agent-Protokolle.

Das Gateway entwickelt sich zur Konnektivitäts- und Governance-Schicht zwischen probabilistischem KI-Schlussfolgern und den Systemen, die tatsächlich Aufgaben ausführen können.

Für Nutzer, die bereits mit CLI-KI-Tools und Coding-Agenten experimentieren, dürfte dies zunehmend wichtiger werden. Ein Coding-Agent mit fünf Tools ist eine Anwendung. Zehn Agenten, die sich fünfzig Tools teilen, sind Infrastruktur.

Abschließendes Urteil

Wählen Sie Docker MCP Gateway, wenn Ihr lokaler KI-Stack bereits unter Docker läuft und Sie eine praktische Kombination aus MCP-Server-Lebenszyklus, Container-Isolierung, Anmeldedaten, Filterung und zentralem Zugriff wünschen.

Wählen Sie ToolHive, wenn MCP zu einer gemeinsam genutzten Team-Infrastruktur wird und Sie statt eines einzelnen Proxys eine Registry-, Laufzeit-, Gateway-, Richtlinien- und Beobachtungsebene benötigen.

Wählen Sie agentgateway, wenn Sie erwarten, dass MCP-Datenverkehr, Modelldatenverkehr und die Kommunikation zwischen Agenten hinter einem einzigen KI-nativen Gateway zusammenlaufen.

Wählen Sie MCPJungle, wenn Sie den einfachsten Weg von verstreuten MCP-Client-Konfigurationen zu einem einzigen selbst gehosteten Endpunkt suchen.

Wählen Sie IBM ContextForge, wenn Ihre Umgebung bereits REST- oder gRPC-APIs enthält, die neben MCP- und Agentendiensten nutzbar werden sollen.

Wählen Sie Microsoft MCP Gateway, wenn Ihre MCP-Server-Flotte bereits in Kubernetes betrieben wird und sitzungsbewusstes Routing sowie Lebenszykluskontrolle benötigt.

Wählen Sie OpenZiti MCP Gateway, wenn Agenten Fernzugriff auf private MCP-Tools benötigen, ohne diese Dienste an öffentlichen Ports bereitzustellen.

Wählen Sie MetaMCP, wenn Ihr größeres Problem nicht die Konnektivität ist, sondern die Anzahl der Tool-Schemas, die Kontext verbrauchen und lokale Modelle verwirren.

Wählen Sie Kong AI Gateway, wenn MCP zu einer weiteren verwalteten Datenverkehrsklasse innerhalb einer bestehenden Kong-basierten API- und KI-Plattform werden soll.

Wählen Sie Supergateway, wenn Sie einfach eine saubere Brücke zwischen MCP-Transporten über stdio und über das Netzwerk benötigen.

Das beste MCP-Gateway ist daher nicht unbedingt das mit der längsten Funktionsliste. Es ist die kleinste Steuerungsebene, die das Problem löst, an dem Ihr Agenten-Stack tatsächlich angelangt ist.

FAQ

Was ist ein MCP-Gateway?

Ein MCP-Gateway sitzt zwischen KI-Clients und MCP-Servern. Es kann mehrere Server hinter einem einzigen Endpunkt bündeln und Funktionen wie Routing, Authentifizierung, Zugriffskontrolle, Anmeldedatenverwaltung, Tool-Filterung, Protokollierung, Beobachtbarkeit, Isolierung oder Transportkonvertierung hinzufügen.

Brauche ich ein MCP-Gateway für lokale KI?

Nicht immer. Ein einzelner KI-Client, der mit einem oder zwei MCP-Servern verbunden ist, funktioniert normalerweise auch ohne Gateway gut. Gateways werden nützlicher, wenn mehrere Clients mehrere MCP-Server gemeinsam nutzen, Anmeldedaten und Richtlinien verwaltet werden müssen oder Fernzugriff und Audit-Anforderungen hinzukommen.

Welches ist das beste MCP-Gateway für einen Home-Server?

Docker MCP Gateway und MCPJungle sind zwei der stärksten Ausgangspunkte. Docker MCP Gateway eignet sich für Nutzer, die bereits Docker einsetzen, und bietet Container-Isolierung sowie Lebenszyklusverwaltung. MCPJungle ist attraktiv, wenn das Hauptziel darin besteht, mehrere MCP-Server hinter einem einzigen übersichtlichen Endpunkt zu bündeln.

Was ist der Unterschied zwischen einem MCP-Gateway und einem MCP-Proxy?

Ein Proxy leitet in erster Linie Datenverkehr weiter und kann ausgewählte Kontrollen hinzufügen. Ein Gateway fungiert in der Regel als umfassendere Steuerungsebene mit Routing, Identität, Richtlinien, Aggregation, Anmeldeinformationsverwaltung, Erkennung, Beobachtbarkeit oder Lebenszyklusverwaltung. In der Praxis verwenden Projekte die Begriffe jedoch häufig synonym.

Kann ein MCP-Gateway mehrere KI-Clients verbinden?

Ja. Einer der Hauptvorteile eines Gateways besteht darin, Claude, Codex, Cursor, Cline, OpenClaw oder benutzerdefinierten Agenten die gemeinsame Nutzung einer MCP-Infrastruktur zu ermöglichen, anstatt jeden MCP-Server in jedem Client separat zu konfigurieren.

Kann ein MCP-Gateway den Tokenverbrauch reduzieren?

Ja, wenn es Tool-Schemas filtert oder abstrahiert, bevor sie das Modell erreichen. Docker MCP Gateway und ToolHive können kuratierte Tool-Sammlungen bereitstellen, MCPJungle unterstützt Tool Groups, und MetaMCP reduziert einen großen nachgelagerten Tool-Katalog auf eine kleine Anzahl von Meta-Tools.

Welches MCP-Gateway eignet sich am besten für lokale Modelle?

Für allgemeine lokale KI sind Docker MCP Gateway und MCPJungle praktische Optionen. MetaMCP ist besonders interessant, wenn kleinere lokale Modelle Schwierigkeiten mit umfangreichen Tool-Katalogen haben, während agentgateway relevant ist, wenn selbst gehostetes Inference-Routing und MCP-Governance in derselben Infrastrukturebene angesiedelt sein sollen.

Kann ich einen MCP-Server mit stdio über HTTP bereitstellen?

Ja. Supergateway kann MCP-Server mit stdio in Streamable-HTTP-, SSE- oder WebSocket-Transporte umwandeln. Andere Gateways können lokale stdio-Server ebenfalls in netzwerkzugängliche MCP-Endpunkte überbrücken oder weiterleiten.

Wie kann ich sicher auf einen MCP-Server außerhalb meines Heimnetzwerks zugreifen?

Verwende ein authentifiziertes privates Netzwerk oder ein Gateway, das für den Fernzugriff konzipiert ist, statt einfach einen öffentlichen Port weiterzuleiten. OpenZiti MCP Gateway wurde speziell dafür entwickelt, private MCP-Dienste über ein Zero-Trust-Overlay aus der Ferne zugänglich zu machen, ohne den Server direkt unter einer öffentlichen IP-Adresse bereitzustellen.

Ist ein MCP-Gateway eine Sicherheitsgrenze?

Es kann Bestandteil eines solchen Systems sein, aber nur, wenn der privilegierte Tool-Zugriff tatsächlich darüber läuft. Wenn derselbe KI-Agent außerdem uneingeschränkten Shell-Zugriff, Administratorrechte, einen beschreibbaren Docker-Socket oder direkte Verbindungen hat, die das Gateway umgehen, definiert das Gateway nicht die tatsächliche Ausführungsgrenze.

Sollten MCP-Server in Docker ausgeführt werden?

Container eignen sich zur Isolierung von Abhängigkeiten, Dateisystemzugriff, Netzwerkzugriff und Ressourcenverbrauch von MCP-Servern. Docker MCP Gateway und ToolHive machen den containerisierten MCP-Betrieb zu einem zentralen Bestandteil ihres Ansatzes, aber Container ersetzen weder Authentifizierung und Autorisierung noch Tool-Filterung oder Auditing.

Was ist der Unterschied zwischen MetaMCP und einem normalen MCP-Gateway?

Ein herkömmliches Gateway aggregiert und verwaltet in der Regel MCP-Server und stellt deren Tools bereit. MetaMCP geht noch weiter, indem es umfangreiche nachgelagerte Tool-Kataloge hinter einer sehr kleinen Anzahl von Meta-Tools verbirgt und so den Schema-Overhead im Modellkontext reduziert.