MCP

MCP Gateway vor der Nutzung: mehrere MCP-Server und REST-APIs zu einer festen Tool-Oberfläche bündeln (nichtkommerzielle Lizenz)

Am besten geeignet, wenn Tool-Definitionen aus vielen MCP-Servern und REST-APIs den Kontext füllen: Ein einzelnes Rust-Binary bündelt alle Backends zu 14 bis 16 festen Meta-Tools, gefunden mit gateway_search_tools, aufgerufen mit gateway_invoke. Die wichtigste Voraussetzung vor der Nutzung: Die Standardlizenz deckt nur persönliche und nichtkommerzielle Nutzung ab, kommerzieller Betrieb erfordert eine kommerzielle Lizenz.

Official source · GitHub - MikkoParkkola/mcp-gateway

Install

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

Wenn Sie mehrere MCP-Server und REST-APIs an denselben KI-Client anschließen, stellen Sie schnell fest, dass die Tool-Definitionen selbst den Kontext füllen. Der Ansatz von MCP Gateway ist ein einzelnes Rust-Binary zwischen Client und allen Tools: Die verschiedenen Backends hängen dahinter, und der Agent sieht eine kompakte Meta-Oberfläche aus 14 bis 16 Tools statt der vollständigen Definition jedes Backends. Je mehr Tool-Definitionen im Kontext liegen, desto weniger Budget bleibt für die eigentliche Aufgabe; sie auf eine kleine feste Oberfläche zu verdichten, ist genau das Problem, das es lösen will. Bevor Sie loslegen, klären Sie eine Voraussetzung: Es wird standardmäßig unter einer nichtkommerziellen Lizenz bereitgestellt — persönliche und nichtkommerzielle Nutzung (einschließlich des Betriebs des vollständigen Gateways) ist kostenlos, der kommerzielle Betrieb erfordert eine kommerzielle Lizenz.

Für wen es geeignet ist

  • Geeignet für alle, die bereits mehrere MCP-Server und REST-APIs anbinden oder die Anbindung planen und wollen, dass die Tool-Liste stabil klein bleibt: Egal wie viele Backends dahinter hängen, der Agent sieht einen festen kleinen Satz von Meta-Tools statt der Summe aller Backend-Definitionen.
  • Geeignet für alle, die einen dauerhaft laufenden Dienst auf dem eigenen Rechner betreiben können: Das Gateway läuft als lokaler HTTP-Dienst, und Clients verbinden sich über einen lokalen Endpunkt.
  • Nicht geeignet für den direkten Einsatz in kommerziellen Umgebungen: Der kommerzielle Betrieb erfordert eine kommerzielle Lizenz, eine Voraussetzung, die vor der Einführung geklärt sein muss; nur ein kleiner MIT-Kern aus generischen Bausteinen ist unter der MIT-Lizenz verfügbar.
  • Bei nur wenigen Backends und einer ohnehin kurzen Tool-Liste ist der Nutzen der Aggregation begrenzt; für konkrete Gewinne in kleinen Szenarien liefert die Evidenz keine Vergleichsdaten.
  • Die Liste der unterstützten Clients, Remote-Deployment und Authentifizierungsverfahren nennt die Evidenz nicht; das bleibt unbelegt — nehmen Sie nichts eigenmächtig an.

Erster Versuch in 3 Minuten

  • Voraussetzung: eine Umgebung mit verfügbarem Homebrew. Der offizielle Installationsweg ist ein Homebrew tap; andere Installationsmethoden nennt die Evidenz nicht.
  • Führen Sie die drei Befehle des offiziellen Hauptwegs der Reihe nach aus:
brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run
  • Der setup wizard im zweiten Schritt importiert Ihre bestehenden Server und verdrahtet die Clients. Beachten Sie: Das ist ein Schreibvorgang in den lokalen Zustand — er überschreibt die lokale Konfiguration von Gateway und Clients und ist nicht schreibgeschützt; genau welche Dateien er schreibt und wie er sie sichert, führt die Evidenz nicht im Einzelnen aus.
  • Nach dem Start im dritten Schritt läuft das Gateway als lokaler HTTP-Dienst. Auf der Client-Seite verbinden Sie sich gemäß dem offiziellen Konfigurationsausschnitt. Der Ausschnitt deklariert einen Dienst namens gateway als Typ http und verweist auf den Pfad /mcp am lokalen Port 39400:
{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}
  • Erfolgssignal: Sobald der Client mit http://localhost:39400/mcp verbunden ist, schrumpft die Tool-Liste auf einen festen kleinen Satz; rufen Sie zu diesem Zeitpunkt einmal gateway_search_tools auf — laut offizieller Beschreibung durchsucht es Backend-Tools. Liefert die Suche Tools Ihrer angebundenen Backends zurück, steht die Strecke vom Client zum Gateway. Ob dieses Tool ein readOnlyHint trägt, sagt die Evidenz nicht; die Read-only-Eigenschaft ist unbelegt. Beschränken Sie den ersten Versuch auf die Suche und führen Sie keine schreibenden Aktionen aus. Zu diesem Zeitpunkt lädt der Agent einen festen kleinen Satz von Meta-Tools statt aller Backend-Definitionen.

Anwendungsfälle

  • Fall 1: Ein Multi-Server-Tool-Stack abspecken. Situation: Der Client ist bereits mit mehreren MCP-Servern verbunden, und die Tool-Definitionen jedes Backends verbrauchen Kontext. Vorgehen: Übergeben Sie die bestehenden Server an den Wizard für den Import und behalten Sie http://localhost:39400/mcp als einzigen Endpunkt des Clients. Erwartung: Die Tool-Oberfläche des Agents bleibt bei rund 14 bis 16 Tools fixiert statt der Summe aller Backend-Definitionen; brauchen Sie eine bestimmte Fähigkeit, lokalisieren Sie sie zuerst mit gateway_search_tools. Beurteilt wird daran, ob die vom Client angezeigte Tool-Anzahl deutlich unter der Gesamtzahl der Tools aller angebundenen Backends liegt.
  • Fall 2: Erst suchen, dann ein echtes Tool einmal aufrufen. Situation: Sie möchten eine Fähigkeit eines verbundenen Backends (MCP-Server oder REST-API) ausführen. Vorgehen: Lokalisieren Sie das Ziel-Tool zuerst mit gateway_search_tools und rufen Sie es dann mit gateway_invoke auf — die offiziell beschriebene Nutzung besteht genau aus diesen beiden Meta-Tools, Suche plus Aufruf. Erwartung: Der Aufruf wird an das entsprechende Backend weitergeleitet und dessen Ergebnis zurückgegeben; die konkrete Ausgabe hängt davon ab, welche Backends Sie angebunden haben, und die Evidenz enthält keine feste Beispielausgabe. Findet die Suche nicht das erwartete Tool, prüfen Sie zuerst, ob das Backend über den Wizard importiert wurde, und suchen Sie erneut.

Nutzungsgrenzen

  • Lizenz und Einschränkungen: Persönliche und nichtkommerzielle Nutzung ist kostenlos, einschließlich des Betriebs des vollständigen Gateways; der kommerzielle Betrieb erfordert eine kommerzielle Lizenz; nur ein kleiner MIT-Kern aus generischen Bausteinen ist unter MIT verfügbar. Dieser Punkt entscheidet, ob und in welchem Umfang Sie es nutzen können, und steht vor allen anderen Abwägungen.
  • Lese-/Schreib-Charakter und Nebenwirkungen: Das Gateway selbst ist ein dauerhaft laufender lokaler Dienst; der Wizard schreibt lokale Konfiguration; gateway_invoke treibt Backend-Tools tatsächlich an, die Nebenwirkungen hängen vom jeweils aufgerufenen Backend ab — klären Sie vor der Ausführung die Natur des Zielvorgangs und dessen Bestätigungspunkte.
  • Abhängigkeiten: Die Installation hängt an Homebrew; das Anbinden bestehender Server läuft über den Import des Wizards.
  • Unbestätigte Punkte: Liste der unterstützten Clients, das konkrete Konfigurationsformat zum Anbinden von REST-APIs, Deployment jenseits von localhost, Authentifizierungsmechanismen und ob jedes Meta-Tool ein readOnlyHint trägt — all das bleibt in der Evidenz unerwähnt. Ob das Gateway selbst Zugriffskontrolle hat und wie es protokolliert, ist ebenfalls unerwähnt. Fehlende Dokumentation ist kein Fehlen von Risiko; vor der Einführung gilt die aktuelle Dokumentation des offiziellen Repositorys.