MCP-Gateways: So verwalten Sie mehrere MCP-Server in großem Maßstab

Für viele von uns beginnt alles mit einem MCP-Server. Ein Entwickler erstellt eine Verbindung zwischen GitHub und Claude oder Cursor, und es funktioniert. Dann fügt jemand Slack hinzu, dann Jira, dann eine interne Datenbank.

Sechs Monate später hat jeder Entwickler seine eigene Konfigurationsdatei, seine eigenen API-Schlüssel und seine eigene Liste von Servern.

Derzeit wissen Sie nicht, welche Agenten auf Produktionsdaten zugreifen können. Wenn ein Entwickler das Unternehmen verlässt, müssen Sie jedes von ihm erstellte Token verfolgen. Das Hinzufügen eines neuen Servers bedeutet, 15 Client-Konfigurationen manuell zu aktualisieren.

Das Beunruhigende daran: Wenn ein Agent etwas Unerwartetes tut, gibt es kein einziges Protokoll, aus dem hervorgeht, warum es überhaupt dazu gekommen ist.

Token stellen den zweiten Kostenfaktor dar. Jeder verbundene Server lädt seine Tool-Definitionen in das Kontextfenster. In einem Setup mit fünf Servern hat Anthropic etwa 55.000 Token an Tool-Definitionen gemessen, bevor der Agent eine einzige Anfrage gelesen hat.

Die Verwaltung mehrerer MCP-Server läuft also auf zwei Aufgaben hinaus: die Zugriffskontrolle an einem zentralen Ort und die Begrenzung der Liste der Tools jedes Agenten. Ein MCP-Gateway übernimmt die erste Aufgabe im Standard. Die zweite übernimmt es nur, wenn es Tools filtert oder sucht. Wir sehen uns fünf Gateways an, die eine Bewertung wert sind, was sie jeweils kosten und wie man eines einführt, ohne die Arbeit der Agenten zu beeinträchtigen.

Was ist ein MCP-Gateway?

Wenn eine Anfrage eingeht, prüft das Gateway, wer die Anfrage stellt und welche Tools dieser Benutzer oder Agent sehen darf. Es ruft Tool-Definitionen von jedem Upstream-Server ab und versieht die Namen mit einem Präfix, damit „github_create_issue“ und „jira_create_issue“ nicht miteinander kollidieren. Alles, was Sie herausgefiltert haben, wird verworfen, sodass das Modell eine übersichtliche Liste vorfindet.

Wenn das Modell ein Tool auswählt, leitet das Gateway den Aufruf an den Server weiter, der dieses Tool bereitstellt, und fügt den Anhang mit den Anmeldedaten dieses Servers hinzu. Bei den meisten Produkten werden diese Daten niemals vom Agenten gespeichert. Jeder Aufruf läuft über einen einzigen Punkt, sodass das Gateway protokollieren kann, was aufgerufen wurde, von wem und welche Antwort zurückkam.

Die Auswahl des Tools und die Sicherheit des Servers hängen nach wie vor davon ab, wie Sie Filterung und Berechtigungen konfigurieren – darauf gehen wir im folgenden Abschnitt „Anleitung“ ein.

Inwiefern unterscheidet sich ein MCP-Gateway von einer Registry, einem LLM-Gateway oder einem API-Gateway?

Alle vier befinden sich zwischen einem Client und dem, was dieser benötigt – weshalb Teams sie oft miteinander verwechseln.

Der Unterschied liegt im Datenverkehr, den die einzelnen Komponenten verarbeiten. Ein MCP-Gateway entscheidet, ob ein Agent ein tool aufrufen darf, während eine Registry den Clients lediglich mitteilt, welche Server existieren, und niemals eine Anfrage weiterleitet. LLM- und API-Gateways verarbeiten unterschiedlichen Datenverkehr: Ersteres wählt aus, welches Modell auf eine Eingabe reagiert, und Letzteres schützt gewöhnliche HTTP-Aufrufe an Ihre Dienste.

In der Praxis verschwimmen die Grenzen. Als Beispiel leiten Tools wie das Kong AI Gateway LLM- und MCP-Datenverkehr über eine einzige Steuerungsebene weiter, und ContextForge betreibt neben seinem Gateway auch ein Registry. Achten Sie beim Produktvergleich darauf, welche Schichten die einzelnen Lösungen tatsächlich abdecken.

Die offizielle MCP-Registry wurde im September 2025 ins Leben gerufen und wird von Anthropic, GitHub, PulseMCP und Microsoft unterstützt. Ein Jahr später befindet sie sich immer noch in der Preview-Phase. Nutzen Sie sie, um Server zu entdecken, führen Sie aber weiterhin Ihre eigene Liste der zugelassenen Server.

Reduziert ein MCP-Gateway den Token-Verbrauch?

Ja, aber nur, wenn es Tools filtert oder durchsucht. Jeder MCP-Server verfügt über eine Reihe von Tools, und jedes Tool hat eine schriftliche Beschreibung, die die KI lesen muss, bevor sie es nutzen kann. Und diese Beschreibungen verbrauchen Tokens. Ein Gateway bündelt alle Ihre Server an einem Ort. Sofern Sie es nicht so einrichten, dass es filtert, zeigt es der KI weiterhin jedes Tool von jedem Server an, sodass die KI denselben Berg an Beschreibungen wie zuvor lesen muss.

Sie sparen nur dann Token, wenn das Gateway die tools ausblendet, die eine Aufgabe nicht benötigt.

Die Kosten sind nur die Hälfte des Problems. Eine häufige Fehlerquelle ist, wenn das Modell das falsche Tool auswählt oder falsche Parameter übergibt. Dies passiert insbesondere dann, wenn Tool-Namen ähnlich klingen, wie beispielsweise „notification-send-user“ und „notification-send-channel“. Laut der Dokumentation von Anthropic verschlechtert sich die Tool-Auswahl ab 30 bis 50 verfügbaren Tools, und schon wenige Server können diese Grenze im Alleingang überschreiten.

Die von Anthropic empfohlene Lösung besteht darin, ein Suchtool im Voraus zu laden und nur die drei bis fünf Tools einzubinden, die für eine Aufgabe benötigt werden. In einem Test mit mehr als 50 MCP-Tools sank der Gesamtkontext von etwa 77.000 Tokens auf etwa 8.700, was Anthropic als eine Reduzierung um 85 % angibt. Auch die Genauigkeit bei den internen MCP-Bewertungen stieg: Opus 4 erreichte bei aktivierter Tool-Suche 74 % (zuvor 49 %), und Opus 4.5 stieg von 79,5 % auf 88,1 %.

Die Erkenntnisse des Unternehmens zur Codeausführung mit MCP gehen sogar noch weiter. Als ein Agent einen Ordner mit Tool-Dateien durchsuchte und nur die benötigten Definitionen las, sank die Anzahl der Token in einem Workflow von Google Drive zu Salesforce von 150.000 auf 2.000. Dieser Ansatz erfordert jedoch eine Sandbox-Umgebung für den vom Agenten geschriebenen Code, was eigene Betriebskosten verursacht.

Gateways bieten Ihnen zwei Möglichkeiten, darauf zu reagieren.

Die erste Möglichkeit ist das manuelle Bereinigen der Tool-Listen. Mit den Profilen von Docker können Sie einzelne Tools pro Server auf eine Whitelist setzen, die virtuellen Server von ContextForge stellen eine handverlesene Auswahl aus mehreren Upstream-Servern bereit, und der Tool Router von Composio kann eine Sitzung an eine feste Liste binden.

Der zweite Punkt ist die Suche zum Zeitpunkt des Aufrufs. Das AgentCore Gateway verfügt über ein integriertes semantisches Suchwerkzeug, das Agenten in natürlicher Sprache abfragen können, und Composio kann Tools auch zur Laufzeit finden.

Anthropic empfiehlt, Maßnahmen zu ergreifen, sobald Definitionen 10.000 Token überschreiten oder Sie 10 oder mehr Tools einsetzen. Die meisten Setups zur Automatisierung von KI-Workflows überschreiten diese Grenze schnell, und Multi-Agent-Workflows erreichen sie noch früher.

Was sind die besten MCP-Gateways?

Zahlreiche Produkte bezeichnen sich selbst als MCP-Gateways, doch manche ähneln eher Serververzeichnissen. Diese Liste beschränkt sich auf tools, die im Zentrum Ihres Setups angesiedelt sind. Ihre Agenten verbinden sich mit einem Endpunkt, das Gateway erreicht die dahinter liegenden Server, und Sie erhalten zumindest eine echte Kontrolle darüber, was durchgelassen wird.

Diese Kontrolle kann eine Anmeldung, eine Whitelist für tools oder ein Audit-Protokoll sein.

Fünf haben es in die engere Auswahl geschafft. Sie alle lösen dasselbe Problem, allerdings auf unterschiedliche Weise. Die richtige Wahl hängt davon ab, wo Ihre Agenten bereits laufen: auf dem Laptop eines Entwicklers, in Ihrer eigenen Infrastruktur, in einem bestehenden Kong-Setup, bei AWS oder in SaaS-Apps.

1. Docker MCP-Gateway (am besten geeignet für die lokale Entwicklung auf Docker Desktop)

Das Docker MCP-Gateway ist die Open-Source-Engine hinter dem MCP-Toolkit in Docker Desktop. Wenn Sie Docker Desktop bereits mit aktiviertem Toolkit nutzen, läuft das Gateway ohne zusätzliches Setup im Hintergrund. Seine Lösung für die Serverflut sind Container. Jeder MCP-Server läuft in einem eigenen Container mit eingeschränkten Berechtigungen, Netzwerkzugriff und Ressourcen, und das Gateway startet ihn nur, wenn ein Agent eines seiner Tools benötigt.

Profile bündeln das Setup an einem Ort. Ein Profil gruppiert die Server, die ein Projekt benötigt, und jeder Client, mit dem Sie sich verbinden – sei es Cursor, VS Code, Claude Desktop oder Claude Code – verwendet dieselbe Konfiguration. Sie können ein Profil in eine OCI-Registry hochladen, damit Teamkollegen es abrufen können. Dadurch werden 15 manuell bearbeitete Konfigurationsdateien durch eine einzige gemeinsame Definition ersetzt.

Innerhalb eines Profils können Sie einzelne Tools wie „github.create_issue“ aktivieren und den Rest des Servers deaktiviert lassen. Auf diese Weise hält Docker die Liste der Tools des Modells kurz.

Anmeldedaten werden nicht in Konfigurationsdateien gespeichert. Das Gateway ruft Geheimnisse aus dem Geheimnisspeicher von Docker Desktop ab und fügt sie beim Start eines Servers hinzu; außerdem übernimmt es die OAuth-Anmeldung für Server, die diese benötigen. Integrierte Protokollierung und Aufrufverfolgung zeigen an, welche Tools ausgeführt wurden. Das Gateway leitet lediglich Aufrufe weiter – die eigentliche Verarbeitung erfolgt in den KI-Agenten, die Sie für die Automatisierung einsetzen. Für den Einstieg listet der Docker MCP-Katalog mehr als 200 Tools und Dienste auf.

Wo es an seine Grenzen stößt: Das Gateway ist für Entwickler konzipiert, die Server auf ihren eigenen Rechnern betreiben. Die Governance-Version, die als Teil von Docker KI Governance vertrieben wird, ist nur auf Einladung über den Docker-Vertrieb erhältlich, sodass Sie sich nicht selbst für teamweite Richtlinienkontrollen anmelden können. Sie können das Gateway ohne Docker Desktop durch eine manuelle Installation ausführen, doch die Verwaltung von Geheimnissen hängt weiterhin von Docker Desktop ab.

Was sagen echte Benutzer über das Docker MCP Gateway?

In einer Bewertung eines Benutzers heißt es:

Das MCP-Gateway von Docker eignet sich wirklich gut für die lokale Entwicklung – Containerisolierung pro Server, in Docker Desktop integrierte Verwaltung von Anmeldedaten –, ist jedoch nicht wirklich für die team- und regionenübergreifende Governance des Unternehmens ausgelegt.

2. IBM ContextForge (Am besten geeignet für selbst gehostete, teambezogene Tool-Sets)

IBM ContextForge ist ein Open-Source-Gateway und eine Registry, die Sie auf Ihrer eigenen Infrastruktur betreiben. Es bündelt MCP-Server, Agent-to-Agent-Dienste (A2A) sowie gewöhnliche REST- oder gRPC-APIs hinter einem einzigen Endpunkt. Sie können es über PyPI installieren, als Container ausführen oder mithilfe des Helm-Charts des Projekts in Kubernetes bereitstellen.

Was es auszeichnet, ist der virtuelle Server. Sie wählen Tools aus allem, was im Gateway registriert ist, bündeln sie unter einem einzigen Namen und leiten einen Client auf den Endpunkt dieses Bundles weiter. Ein Finanzmitarbeiter erhält die Finanz-Tools, ein Support-Mitarbeiter erhält einen anderen Satz, und keiner von beiden lädt die Definitionen des anderen. Jeder virtuelle Server kann privat sein, mit einem Team geteilt werden oder öffentlich sein.

Außerdem verwandelt es Ihre bereits vorhandenen APIs in MCP-Tools. Richten Sie es auf einen REST-Endpunkt aus, und es ruft das JSON-Schema automatisch ab. Das tool übersetzt zudem gRPC-Dienste mittels Server-Reflection. Das erspart Ihnen das Schreiben eines Wrapper-Servers für jede interne API.

Jeder Upstream-Server verwaltet seine eigenen OAuth-Einstellungen, und ContextForge speichert Tokens pro Benutzer, sodass zwei Server unterschiedliche Anbieter nutzen können. Die Oberfläche für Administratoren umfasst einen Live-Log-Viewer, und Traces werden über OpenTelemetry an Backends wie Jaeger, Zipkin und Datadog gesendet. Mehr als 40 Plugins bieten zusätzliche Transportmöglichkeiten und Integrationen.

Wo es an seine Grenzen stößt: Sie müssen es selbst betreiben, patchen und skalieren. Das Gateway startet erst, wenn Sie sichere geheime Schlüssel generiert haben. Das Projekt empfiehlt PostgreSQL für den Produktiveinsatz, und der Support erfolgt über GitHub-Issues und -Diskussionen.

Was sagen echte Benutzer über IBM ContextForge?

In einer Bewertung eines Benutzers heißt es:

Unter Apache-Lizenz, entwickelt für Nutzer, die bereits eine professionelle Kubernetes-Infrastruktur betreiben. Es hat sich zu einer wirklich leistungsfähigen Lösung entwickelt – echte Governance, Überwachung, Verwaltung von MCP neben den anderen APIs Ihres Unternehmens. Die Einrichtung ist jedoch aufwendiger als bei den kleineren Alternativen; dies ist kein Wochenendprojekt.

3. Kong KI Gateway (Am besten geeignet für Teams, die bereits Kong einsetzen)

Kong behandelt MCP-Datenverkehr als eine weitere Art von API-Datenverkehr. Wenn Ihr Team bereits Kong Gateway oder Kong Konnect einsetzt, wird die MCP-Unterstützung als Plugins für das von Ihnen bereits betriebene Gateway bereitgestellt. Dabei kommen dieselben Funktionen für Authentifizierung, Ratenlimit und Protokollierung zum Einsatz, die Sie auch für Ihre APIs verwenden.

Das Herzstück ist das AI MCP Proxy-Plugin. Es kann vor einem bereits von Ihnen betriebenen MCP-Server eingesetzt werden oder jede API mit einem OpenAPI-Schema ohne benutzerdefinierten Code in MCP-Tools umwandeln. Sie können außerdem Tools aus mehreren APIs in einem einzigen MCP-Endpunkt zusammenfassen, sodass sich Agenten nur einmal verbinden müssen statt einmal pro Dienst.

Die Zugriffskontrolle erfolgt auf Tool-Ebene. Sie legen Zulassungs- und Sperrlisten nach Verbraucher oder Verbrauchergruppe fest, und wenn ein Agent seine Tool-Liste anfordert, gibt Kong nur die Tools zurück, die dieser bestimmte Aufrufer nutzen darf. Jeder zugelassene oder abgelehnte Versuch wird im Audit-Protokoll des Plugins erfasst. Da ein Agent niemals Tools lädt, die er nicht aufrufen kann, sorgt die gefilterte Liste zudem dafür, dass der Kontext überschaubar bleibt.

Die Authentifizierung erfolgt über die Authentifizierungs-Plugins von Kong, darunter OpenID Connect und das AI MCP OAuth2-Plugin. MCP-Traffic-Logs erfassen Sitzungs-IDs, JSON-RPC-Methoden, Nutzdaten, Latenzen und Fehler, und Sie können Traces an OpenTelemetry senden. Wenn Sie zudem den LLM-Traffic über das AI Gateway von Kong leiten, teilen sich Modell- und Tool-Traffic eine gemeinsame Steuerungsebene.

Einschränkungen: SSO und Plattform-Audit-Protokolle sind bei Konnect nur in der Enterprise-Version verfügbar. Das AI MCP Proxy-Plugin unterstützt keine WebSocket- oder gRPC-Upstreams, und KI-Sicherheitsmaßnahmen gelten nicht für MCP-Anfragen. Für die REST-Konvertierung ist für jede API ein gültiges OpenAPI-Schema erforderlich, und für toolbezogene ACLs ist Kong Gateway 3.13 oder höher erforderlich. Pings von MCP-Clients werden ebenfalls auf Ihre monatliche Anfragensumme angerechnet.

Was sagen echte Benutzer über das Kong KI Gateway?

In einer Bewertung eines Benutzers heißt es:

Das ist sinnvoll, wenn Sie bereits Kong einsetzen. Es handelt sich hier nicht mehr nur um ein einfach angehängtes MCP, sondern um echte, zweckgebundene Support-Funktionen, einschließlich des Datenverkehrs von Agent zu Agent, und Mitte Juli ist eine Partnerschaft mit einem auf KI-Governance spezialisierten Unternehmen eingegangen worden, um Richtlinienprüfungen direkt in das Gateway zu integrieren. Für einige der fortgeschritteneren Features ist jedoch wahrscheinlich ein kostenpflichtiges Abonnement erforderlich.

4. Amazon Bedrock AgentCore Gateway (Am besten geeignet für Agenten, die auf AWS laufen)

Das Amazon Bedrock AgentCore Gateway ist die vollständig verwaltete Lösung von AWS, sodass kein Hosting und keine Skalierung erforderlich sind. Es bietet Agenten einen zentralen Endpunkt für ihre Tools. AgentCore wandelt zudem OpenAPI- und Smithy-Spezifikationen, Lambda-Funktionen und bestehende MCP-Server ohne benutzerdefinierten Code in MCP-Tools um. Es umfasst Ein-Klick-Integrationen für Salesforce, Slack, Jira, Asana und Zendesk.

Die Tool-Suche ist integriert. Wenn Sie bei der Erstellung eines Gateways die semantische Suche aktivieren, erhalten Agenten ein Such-Tool (x_amz_bedrock_agentcore_search), das sie in natürlicher Sprache für Abfragen verwenden können. Auf diese Weise laden sie nur die Tools, die für eine Aufgabe benötigt werden, anstatt den gesamten Katalog zu laden. Es handelt sich um dasselbe On-Demand-Muster, das Anthropic beschreibt, das jedoch am Gateway statt auf dem Client ausgeführt wird.

Die Authentifizierung erfolgt in beide Richtungen. Beim eingehenden Datenverkehr überprüft das Gateway anhand von AWS IAM oder eines JWT Ihres Identitätsanbieters, wer den Aufruf tätigt. Beim ausgehenden Datenverkehr meldet es sich bei jedem Tool mit OAuth, einem API-Schlüssel oder einer IAM-Rolle an und fügt diese Anmeldedaten selbst hinzu, sodass Agenten diese niemals speichern. AgentCore Identity verursacht keine zusätzlichen Kosten, wenn Sie es über das Gateway nutzen, und AgentCore Policy kann jeden Tool-Aufruf anhand von in Cedar geschriebenen Regeln überprüfen.

Das Gateway funktioniert mit Open-Source-Frameworks wie CrewAI, LangGraph, LlamaIndex und Strands Agents sowie mit beliebigen Modellen. Ein Update vom Juni 2026 fügte MCP-Prompts und -Ressourcen, Streaming und Verwaltung der Sitzungen, die Einholung von Genehmigungen während der Ausführung der Aufgaben sowie den Austausch von OAuth-„On-Behalf-Of“-Tokens hinzu.

Wo es an seine Grenzen stößt: Es läuft ausschließlich auf AWS, sodass Sie es nicht selbst hosten können. Die Preisgestaltung erfolgt nutzungsabhängig über mehrere AgentCore-Dienste hinweg, wodurch die monatlichen Kosten schwerer vorhersehbar sind als bei einer Pauschalgebühr. In einem Beispiel von AWS kostet ein Agent, der monatlich 50 Millionen Interaktionen mit jeweils einer Suche und vier Tool-Aufrufen verarbeitet, etwa 2.250 US-Dollar pro Monat, wobei mehr als die Hälfte davon auf die Suche entfällt. Die semantische Suche ist in 18 AWS-Regionen verfügbar. Jedes Gateway akzeptiert nur die von Ihnen konfigurierten MCP-Versionen, und die Observability erfolgt über CloudWatch gegen separate Kosten.

Was sagen echte Benutzer über das Amazon Bedrock AgentCore Gateway?

In einer Bewertung eines Benutzers heißt es:

Die Komplexität ergibt sich aus mehreren Aspekten: 1) Benutzer müssen AWS-Anmeldedaten und -Umgebungen einrichten; 2) Entwickler müssen ihren Agent-Code vollständig schreiben und mit Anmerkungen versehen, um AgentCore nutzen zu können; und 3) das Kontextmanagement erfordert spezifische Programmiermodelle, die möglicherweise nicht mit jedem Framework kompatibel sind.

5. Composio (Am besten geeignet, um Agenten mit SaaS-Apps zu verbinden, ohne Server betreiben zu müssen)

Composio ist eine verwaltete Plattform, die Agenten mit mehr als 1.500 Apps verbindet, darunter Gmail, Slack, GitHub, HubSpot und Salesforce. Es müssen keine Server betrieben werden. Ihr Agent oder KI-Client verbindet sich mit einer einzigen MCP-URL, und Composio übernimmt die Anmeldung für jede App – von OAuth-Flows über API-Schlüssel bis hin zur Aktualisierung des Tokens.

Der Großteil der Gateway-Arbeit findet im Tool Router statt. Sie erstellen für jeden Benutzer eine Sitzung mit den benötigten Toolkits, und Composio gibt einen bereichsbezogenen MCP-Endpunkt zurück. Innerhalb einer Sitzung können Sie eine genaue Liste von Tools festlegen, bestimmte Tools blockieren oder nach MCP-Hinweisen wie „schreibgeschützt“ oder „destruktiv“ filtern. Das Tool kann außerdem zur Laufzeit seinen Katalog durchsuchen und nur die für eine Aufgabe benötigten Tools laden, wodurch der Kontext des Agenten klein gehalten wird.

Berechtigungen können vorsehen, dass eine Person Tool-Aufrufe bei jedem Aufruf oder einmal pro Sitzung genehmigen muss, wobei pro Tool Übersteuerungen wie „immer zulassen“ oder „immer ablehnen“ möglich sind. Sitzungen werden pro Benutzer erstellt, sodass die verbundenen Konten jeder Person getrennt bleiben und eine Person mehr als ein Konto für dieselbe App verbinden kann. Wenn eine App nicht im Katalog enthalten ist, aber über einen MCP-Server verfügt, können Sie sie kostenlos als benutzerdefinierten Server hinzufügen.

Es funktioniert mit Claude, ChatGPT, Cursor, Claude Code und jedem anderen MCP-Client sowie mit Frameworks wie LangChain, LlamaIndex, CrewAI und dem OpenAI Agents SDK. Für mehrstufige Aufgaben bietet Composio eine Remote-Laufzeitumgebung, in der jede Ausführung in einer eigenen, isolierten Sandbox läuft. Das Unternehmen gibt an, SOC 2 Typ II-konform zu sein und über eine Zertifizierung nach ISO 27001:2022 zu verfügen.

Herausragende Features

Preise

Bewertungen

Wo es an seine Grenzen stößt: Es handelt sich um einen Managed Service, sodass Ihre Tool-Aufrufe und die gespeicherten Anmeldedaten Ihrer Benutzer über die Cloud von Composio laufen, es sei denn, Sie richten eine „Bring-Your-Own-Cloud“-Bereitstellung ein. Wenn Sie eine Verbindung über MCP herstellen, werden die Tool-Call-Hooks und Schemaänderungen des SDK nicht ausgeführt, und in Ihrem eigenen Code definierte benutzerdefinierte Tools sind am MCP-Endpunkt nicht verfügbar. Im Mai 2026 gab Composio einen Sicherheitsvorfall bekannt, bei dem etwa 0,3 % der aktiven Verbindungen – die meisten davon zu GitHub – offengelegt wurden und Kunden ihre API-Schlüssel ändern mussten. Beziehen Sie diesen Bericht in Ihre Sicherheitsüberprüfung ein.

Was sagen echte Benutzer über Composio?

In einer Bewertung eines Benutzers heißt es:

Eine verwaltete MCP-Plattform mit einer riesigen Bibliothek von fast 1.000+ Apps wie Gmail und Slack. Der große Vorteil besteht darin, dass Sie nicht jede Integration selbst erstellen und warten müssen. Außerdem unterstützt Composio das Self-Hosting in einer VPC sowie ein eingebettetes SDK für flexible Bereitstellungsoptionen.

Wie viel kostet ein MCP-Gateway?

Der Preis hängt davon ab, ob Sie für die verwaltete Nutzung bezahlen oder die Infrastruktur selbst betreiben.

Open-Source-Gateways sind lizenzgebührenfrei, aber Sie zahlen dennoch für Hosting, Wartung und Sicherheit. Bei verwalteten Gateways fallen Gebühren für Tool-Aufrufe, Suchvorgänge, Control-Planes oder sonstige Nutzung an.

Welches Gateway kostengünstiger ist, hängt davon ab, was Sie bereits einsetzen. Composio und das Amazon Bedrock AgentCore Gateway verlagern einen größeren Teil der Infrastrukturarbeit auf den Anbieter und berechnen die Kosten nutzungsabhängig. Das Docker MCP Gateway und IBM ContextForge erheben keine Lizenzgebühren, jedoch tragen Sie die Kosten für das Hosting und die Wartung. Kong ist finanziell am sinnvollsten, wenn Ihr Team Kong bereits einsetzt, da die Einführung nur für MCP eine neue Plattform und zusätzliche Lizenzkosten mit sich bringt.

So wählen Sie ein MCP-Gateway aus

Die Preisgestaltung grenzt die Liste ein, trifft aber selten die Entscheidung für Sie.

Ein besserer Ausgangspunkt ist das Problem, das Sie auf die Suche gebracht hat. Die meisten Teams stehen vor einem von zwei Problemen: Entweder können sie nicht erkennen oder kontrollieren, wer welches tool aufruft, oder ihre Agenten laden so viele tool-Definitionen, dass sie anfangen, die falschen auszuwählen. Manche haben sogar beide Probleme.

Sobald Sie wissen, welches Problem am meisten schmerzt, wissen Sie auch, was das Gateway zu erledigen hat und auf welche Features Sie verzichten können.

Beginnen Sie dort, wo Ihre Agenten bereits laufen

Die fünf Gateways in diesem Leitfaden decken dieselben Grundlagen ab, daher ist der entscheidende Faktor in der Regel der Stack, über den Sie bereits verfügen.

Wenn Ihre Agenten hauptsächlich innerhalb von SaaS-Apps im Auftrag einzelner Benutzer agieren, spart Composio am meisten Arbeit, da es die OAuth-Verbindungen jedes Benutzers für Sie verwaltet. Der Nachteil dabei ist, dass diese Anmeldedaten in der Composio-Cloud gespeichert werden, was Ihr Team für Sicherheit wahrscheinlich überprüfen möchte.

Für Teams, die mit unzusammenhängenden Workflows zu kämpfen haben, die über die Laptops der Entwickler verteilt sind, ist das Docker MCP Gateway der naheliegende erste Schritt. Es eignet sich für Teams, die bereits Docker Desktop nutzen, lässt jeden Server in einem eigenen Container laufen und ermöglicht es dem gesamten Team, ein gemeinsames Profil zu nutzen. Wenn Sie später teamweite Governance benötigen, müssen Sie sich separat in einer Unterhaltung mit dem Docker-Vertrieb unterhalten.

Plattformteams, die ihre Infrastruktur lieber selbst verwalten möchten, werden sich eher für IBM ContextForge entscheiden. Seine virtuellen Server bieten jedem Team ein eigenes Toolset, und es kann interne REST- und gRPC-Dienste in MCP-Tools umwandeln. Sie übernehmen dabei auch die mit dem Eigenbetrieb verbundenen Aufgaben wie Patching, Skalierung und Bereitschaftsdienst.

Das Kong AI Gateway unterwirft den MCP-Datenverkehr denselben Richtlinien, die Ihr Team bereits für seine APIs anwendet. Wenn Sie SSO oder Plattform-Auditprotokolle benötigen, sollten Sie die Enterprise-Version einplanen, da beide Funktionen nur in der Enterprise-Version verfügbar sind.

Für Teams, die auf AWS entwickeln, sorgt das Amazon Bedrock AgentCore Gateway für eine zentrale Verwaltung und bietet zusätzlich eine semantische Toolsuche direkt am Gateway. Planen Sie die nutzungsabhängige Abrechnung frühzeitig ein, da Suchaufrufe, Toolaufrufe und CloudWatch jeweils separat abgerechnet werden.

Wenn Sie eine Handvoll stabiler Server für ein kleines Team betreiben, benötigen Sie möglicherweise noch kein Gateway. Eine gemeinsam genutzte Konfiguration in der Versionskontrolle in Verbindung mit einem Secret-Manager kann denselben Zweck erfüllen, bis Sie teambezogene Berechtigungen oder zentrale Protokolle benötigen.

Was sollten Sie vor dem Committen überprüfen?

Sobald Sie einen Favoriten gefunden haben, testen Sie diesen in Ihrem eigenen Setup, bevor Sie einen Vertrag unterzeichnen. Auf Features werden oft Details ausgelassen, die später wichtig werden. Besprechen Sie daher einige konkrete Fragen mit Ihren Verantwortlichen für Sicherheit und Plattform:

Die Antworten geben in der Regel Aufschluss. Wenn ein Gateway lediglich Änderungen an den Einstellungen protokolliert und Ihnen nicht anzeigen kann, welche Tools Ihre Agenten tatsächlich verwendet haben, wird es bei einem Audit nicht bestehen. Und wenn es Ihre Server verbindet, ohne deren Tool-Listen zu bereinigen, laden Ihre Agenten weiterhin jede Tool-Definition, sodass Ihr Token-Verbrauch unverändert bleibt.

Wie migriert man bestehende MCP-Server auf ein Gateway?

Die sicherste Vorgehensweise besteht darin, zunächst einen Server mit geringem Risiko umzustellen und den alten Pfad so lange in Betrieb zu halten, bis sich der neue als zuverlässig erwiesen hat.

Beginnen Sie mit einer Bestandsaufnahme

Notieren Sie für jeden Server, wem er gehört, welche Tools er bietet, auf welche Daten er zugreifen kann und wie viele Token seine Tool-Definitionen ungefähr kosten. Dies ist auch der richtige Zeitpunkt, um zu entrümpeln. Die meisten Kataloge enthalten Tools, die seit Monaten niemand mehr aufgerufen hat, und wenn Sie diese vor der Migration entfernen, verringert sich der Umfang dessen, was Sie verwalten müssen.

Server nach Vertrauensgrenzen gruppieren

Ordnen Sie Server, die private Daten auslesen, Server, die nicht vertrauenswürdige Inhalte verarbeiten, und Server, die Daten nach außen senden können, separaten Toolsets zu, sodass kein einzelner Agent jemals alle drei Funktionen vereint. Diese Kombination hat die GitHub-MCP-Prompteinjektions-Demo von Invariant Labs erst möglich gemacht. Vergewissern Sie sich außerdem, dass jeder Server weiterhin gepflegt wird. Einige der ursprünglichen MCP-Referenzserver, darunter GitHub und Slack, befinden sich mittlerweile im Archiv und erhalten keine Updates mehr.

Sobald die Gruppen eingerichtet sind, führen Sie ein kurzes Pilotprojekt durch.

Sobald der Pilotversuch erfolgreich abgeschlossen ist, migrieren Sie die schreibfähigen Server nacheinander. Legen Sie vor jeder Migration Rollback-Kriterien fest, damit Sie nicht mitten in einem Incident entscheiden müssen, ob eine Rücknahme erforderlich ist. Behalten Sie die direkte Konfiguration bei, bis der Gateway-Pfad einige Wochen lang reibungslos funktioniert hat, und widerrufen Sie dann die alten Anmeldedaten und Client-Verbindungen.

Eine Regel gilt unabhängig davon, für welches Gateway Sie sich entscheiden: Die MCP-Spezifikation verbietet das Weiterleiten von Tokens. Das Gateway sollte nur Tokens akzeptieren, die für es ausgestellt wurden, und es sollte nachgelagerte Server mit deren eigenen, separat autorisierten Anmeldedaten aufrufen, anstatt das Token des Clients weiterzuleiten. Überprüfen Sie, ob die Konfiguration Ihres Gateways dieser Regel entspricht, bevor Sie den Produktionsdatenverkehr umleiten.

Wie funktioniert ClickUp mit einem MCP-Gateway?

ClickUp stellt von beiden Seiten des Gateways eine Verbindung zu MCP her.

KI-Apps außerhalb von ClickUp, wie Claude, Cursor und ChatGPT, erreichen Ihren Workspace über den ClickUp-MCP-Server, der wie jeder andere Server hinter Ihrem Gateway sitzt. Innerhalb von ClickUp können Super Agents und Brain² Tools von externen MCP-Servern nutzen, mit denen Sie eine Verbindung herstellen, und Ihr Gateway kann einer davon sein.

Stellen Sie den ClickUp-MCP-Server hinter Ihr Gateway

Der ClickUp-MCP-Server läuft unter https://mcp.clickup.com/mcp und ist in jedem Plan verfügbar, einschließlich „Free Forever“. Er akzeptiert ausschließlich OAuth, sodass Ihr Gateway niemals persönliche API-Schlüssel speichern oder diese bei Ausscheiden eines Nutzers aktualisieren muss. Wenn Sie einen eigenen Client entwickeln, muss dieser OAuth 2.1 mit PKCE unterstützen. ClickUp führt eine Whitelist mit zugelassenen Clients, sodass jeder Client, der nicht auf dieser Liste steht, zunächst zur Überprüfung eingereicht werden muss.

Sobald die Verbindung hergestellt ist, können Ihre Mitarbeiter Aufgaben erstellen und weiterleiten, Statusaktualisierungen aus Aufgaben und Dokumenten zusammenstellen, Arbeitszeiten erfassen, nach Aufgaben, Dokumenten und Kommentaren suchen sowie Chat-Threads zusammenfassen. Auf diese Weise kann ein Mitarbeiter den Projektkontext selbst abrufen, anstatt ihn in jede Eingabeaufforderung einzufügen.

Ratenlimits sollten hinter einem Gateway genauer unter die Lupe genommen werden. Das Ratenlimit gilt für Ihren gesamten Arbeitsbereich, und jeder verbundene Client verbraucht denselben gemeinsamen Kontingentanteil. Ohne das „Everything KI“-Add-On begrenzt ClickUp die Anzahl der MCP-Aufrufe pro rollierendem 24-Stunden-Zeitraum – von 100 im „Free Forever“-Tarif bis zu 5.000 im „Enterprise“-Tarif.

Mit dem Add-On unterliegen MCP-Anfragen stattdessen den Minutenlimits der öffentlichen API. Diese reichen von 100 Anfragen pro Minute bei den Tarifen „Free Forever“, „Unlimited“ und „Business“ bis zu 10.000 bei „Enterprise“. ClickUp zeigt die MCP-Nutzung derzeit noch nicht an. Wenn mehrere Teams über ein einziges Gateway auf ClickUp zugreifen, legen Sie am Gateway Limits pro Team fest, damit ein besonders aktiver Mitarbeiter nicht das Kontingent für alle anderen aufbraucht.

Verbinden Sie Super-Agenten mit Ihren MCP-Servern

Umgekehrt können Sie externe MCP-Server über das ClickUp-App-Center verbinden – entweder für den gesamten Arbeitsbereich oder nur für sich selbst. Administratoren legen fest, wer die einzelnen Verbindungstypen hinzufügen darf. Nachdem ein Server verbunden wurde, wählen Sie aus, welche seiner Tools die einzelnen Super-Agenten erhalten: alle oder nur bestimmte. Das entspricht dem gleichen Prinzip wie das Kürzen der Tool-Listen weiter oben in diesem Leitfaden, nur dass es hier auf die Agenten in Ihrem Workspace angewendet wird.

Wenn der Server, mit dem Sie sich verbinden, Ihr Gateway ist, überprüfen Sie zunächst zwei Details. ClickUp stellt Verbindungen von wechselnden Cloud-IP-Adressen her, sodass eine IP-Whitelist den Zugriff nicht zulässt. Ihr Gateway benötigt außerdem eine öffentliche URL, die mit OAuth oder einem API-Schlüssel gesichert ist. Die Audit-Protokolle der ClickUp-Workspaces zeichnen auf, wer sich mit einem Server verbunden, ihn aktualisiert oder die Verbindung getrennt hat. Um festzuhalten, welche Tools jeder Agent tatsächlich aufgerufen hat, benötigen Sie die Protokolle Ihres Gateways.

Führen Sie die Nachverfolgung der Einführung in ClickUp durch

Die oben genannten Schritte zur Bestandsaufnahme und zum Pilotprojekt führen zu vielen kleinen Entscheidungen, bei denen man leicht den Überblick verlieren kann. Fügen Sie jeden Server als Aufgabe in eine Liste ein, mit benutzerdefinierten Feldern für Eigentümer, Datenzugriff, Vertrauensgruppe und Token-Kosten. Schreiben Sie dann die Rollback-Kriterien in ein Dokument, das mit jeder Migrationsaufgabe verknüpft ist. Wenn ein Pilotprojekt fehlschlägt oder ein vorgelagerter Server archiviert wird, sind der Eigentümer und der vollständige Verlauf an einem Ort zusammengefasst.

Wählen Sie das Gateway, das zu Ihrem Problem passt

Jeder Abschnitt dieses Leitfadens kommt immer wieder auf dieselben beiden Aufgaben zurück.

An erster Stelle steht die Kontrolle: ein Endpunkt, ein Ort für Anmeldedaten und eine Aufzeichnung darüber, welcher Agent welches Tool aufgerufen hat. Alle fünf Gateways in diesem Leitfaden decken dies in irgendeiner Form ab, und der größte Unterschied besteht darin, wie viel von der Infrastruktur Sie selbst betreiben. Die zweite Aufgabe besteht darin, die Liste der Tools jedes Agenten klein zu halten, und ein Gateway hilft dabei nur, wenn Sie Filter oder Suchfunktionen einrichten.

Bevor Sie etwas unterschreiben, zählen Sie Ihre Tools und ermitteln Sie, wie viele Tokens deren Definitionen verwenden.

Entfernen Sie diejenigen, die niemand aufruft, gruppieren Sie den Rest nach Vertrauensgrenzen und leiten Sie zunächst einen schreibgeschützten Server durch das Gateway. Wenn ClickUp zu diesen Servern gehört, verbinden Sie es über den ClickUp-MCP-Server und sehen Sie, wie ein Agent Ihre Aufgaben, Dokumente und den Chat im vollständigen Projektkontext verarbeitet.

Häufig gestellte Fragen zu MCP-Gateways

Was ist das beste MCP-Gateway?

Welches MCP-Gateway am besten geeignet ist, hängt davon ab, wo Ihre Agenten bereits ausgeführt werden. Das Docker MCP Gateway eignet sich für die lokale Entwicklung. IBM ContextForge eignet sich für Teams, die eine Eigenhosting-Lösung wünschen. Das Kong AI Gateway eignet sich für Teams, die bereits Kong nutzen, und das Amazon Bedrock AgentCore Gateway eignet sich für Agenten auf AWS. Composio eignet sich für Agenten, die in vielen SaaS-Anwendungen eingesetzt werden. Für regulierte Branchen sollten Sie auf Eigenhosting oder eine private Bereitstellungsoption, Zugriffskontrollen pro Tool sowie Protokolle einzelner Tool-Aufrufe achten.

Ist MCP ein API-Gateway?

Nein. Das Model Context Protocol ist eine Spezifikation, die definiert, wie KI-Apps eine Verbindung zu Tools und Daten herstellen. Ein MCP-Gateway ist eine auf dieser Spezifikation basierende Software. Es befindet sich zwischen Agenten und MCP-Servern und verwaltet den Zugriff, Anmeldedaten und die Protokollierung. Es funktioniert ähnlich wie HTTP und ein API-Gateway: HTTP legt die Regeln für Anfragen fest, und das Gateway entscheidet, welche Anfragen durchgelassen werden.

Benötigen Sie ein MCP-Gateway?

Sie benötigen ein MCP-Gateway, wenn Sie steuern möchten, wer welche Tools auf mehreren Servern aufrufen darf, oder wenn Sie zentral protokollieren möchten, welche Aktionen die Agenten durchgeführt haben. Wenn ein kleines Team eine Handvoll stabiler Server betreibt, deckt eine gemeinsam genutzte Konfiguration in der Versionskontrolle zusammen mit einem Secret-Manager den Großteil dieser Anforderungen ab. Ein Gateway zahlt sich erst dann aus, wenn Sie teambezogenen Zugriff auf Tools benötigen oder einen zentralen Ort zur Verwaltung von Anmeldedaten suchen.

Sind MCP-Server hinter einem Gateway sicher in Bezug auf die Sicherheit?

Ein Gateway erleichtert die Sicherheit von MCP-Servern. Es macht sie jedoch nicht von sich aus sicher. Es verwahrt Anmeldedaten an einem zentralen Ort, schränkt die Tools ein, die jeder Aufrufer nutzen darf, und protokolliert Aufrufe zentral. Prompt-Injektionen können weiterhin über einen vertrauenswürdigen Server erfolgen, wie Invariant Labs am MCP-Server von GitHub gezeigt hat. Tools, die private Daten auslesen, nicht vertrauenswürdige Inhalte verarbeiten oder Daten nach außen senden, sollten in separaten Tool-Sets untergebracht werden. Stellen Sie sicher, dass das Gateway niemals das Token eines Clients weiterleitet. Und verzichten Sie auf die Nutzung von Servern, für die keine Updates mehr bereitgestellt werden.

Ersetzt die Toolsuche die Zugriffskontrolle?

Nein. Die Tool-Suche entscheidet, welche Tools einem Agenten für eine Aufgabe angezeigt werden. Die Zugriffskontrolle entscheidet, ob dieser Agent sie aufrufen darf. Das Amazon Bedrock AgentCore Gateway behandelt beispielsweise die semantische Suche und die Authentifizierung als separate Features. Führen Sie die Suche nur unter den Tools durch, die ein Aufrufer verwenden darf, und überprüfen Sie die Berechtigungen erneut, wenn das Tool tatsächlich ausgeführt wird. Wenn das Ausblenden eines Tools aus der Suche dessen einziger Schutz ist, ist es nicht geschützt.

Was sollten die Audit-Protokolle eines MCP-Gateways erfassen?

Die Audit-Protokolle eines MCP-Gateways sollten aufzeichnen, wer den jeweiligen Aufruf getätigt hat, welcher Agent und welches Tool beteiligt waren, welcher Server den Aufruf bearbeitet hat, ob der Aufruf zugelassen oder abgelehnt wurde, wann er stattfand und welche Antwort zurückkam. Das KI-MCP-Proxy-Plugin von Kong protokolliert beispielsweise jeden zugelassenen und abgelehnten Zugriffsversuch eines Tools. Vergewissern Sie sich vor dem Kauf, dass die Protokolle einzelne Tool-Aufrufe und nicht nur Konto- und Konfigurationsänderungen erfassen, und prüfen Sie anschließend, wie lange sie aufbewahrt werden und ob Sie sie exportieren können.