MCP Server zentral verwalten: Wann sich ein Gateway lohnt

Wenn mehrere Agenten-Clients gemeinsame Zugriffsregeln für MCP Server benötigen, wird ein Gateway sinnvoll. Sechs Entwickler mit vier Clients und acht MCP-Servern können sonst auf 192 einzelne Konfigurationseinträge zwischen Clients und Servern kommen. Der eigentliche Nutzen liegt in einer zentralen Stelle für Zugriffssteuerung und die Untersuchung von Tool-Aufrufen – mit klarer Verantwortung für die laufenden Kosten.

Was übernimmt ein MCP-Gateway?

Ein MCP-Gateway ist eine zentrale Kontrollstelle zwischen Agenten und MCP-Servern für Authentifizierung, Listen zulässiger Tools, Protokollierung und Aufruflimits. Das Model Context Protocol, kurz MCP, ist die gemeinsame Schnittstelle, über die eine KI-Anwendung verfügbare Tools ermittelt und Aktionen anfordert. Ein Gateway bündelt die Verwaltung dieser Verbindungen. Welche Kontrollen es tatsächlich bietet, hängt von der Implementierung ab. Kongs Erklärung zu MCP-Gateways beschreibt diese Rolle als Proxy und Instanz zur Durchsetzung von Richtlinien.

Ein Beispiel: Ein Assistent für den Betrieb sucht einen Kunden heraus und aktualisiert anschließend ein Support-Ticket. Die MCP-Server stellen diese Aktionen bereit. Das Gateway sollte feststellen, wer den Aufruf ausführt, welche Aktionen diese Identität nutzen darf und was bei der Ausführung passiert ist.

Für Entwickler, die Claude, ChatGPT, Codex und Cursor einsetzen, liegt der Vorteil im einheitlichen Tool-Zugriff über alle im Unternehmen zugelassenen Clients. Die Client-Tarife, unterstützten Authentifizierungsverfahren und Verbindungsmethoden müssen trotzdem einzeln geprüft werden.

Die einzelnen Kontrollen erfüllen unterschiedliche Aufgaben:

• Authentifizierung: Sie stellt fest, welche Person oder welcher Workload die Anfrage sendet. Die Autorisierung entscheidet anschließend, was diese Identität tun darf. Ein gemeinsam genutzter API-Schlüssel kann verschleiern, wer für eine Aktion verantwortlich ist.
• Listen zulässiger Tools: Sie machen eine bewusst ausgewählte Menge von Aktionen sichtbar und nutzbar. Ein Support-Assistent darf etwa Kundendaten abrufen, aber kein Tool zum Löschen verwenden. Die Regel muss beim Aufruf eines Tools ebenso greifen wie beim Auflisten der verfügbaren Tools.
• Protokollierung: Sie hält Akteur, Server, Tool, Richtlinienentscheidung und Ergebnis fest, damit sich eine Aktion nachvollziehen lässt. Dabei muss entschieden werden, welche Argumente protokolliert werden dürfen und wie sensible Werte behandelt werden.
• Aufruflimits: Sie begrenzen Aufrufe nach Identität, Tool oder dem vorgelagerten Dienst, der geschützt werden soll. Ein Agent in einer Wiederholungsschleife sollte an ein kontrolliertes Limit stoßen, bevor er ein Backend überlastet.

Diese Anforderungen müssen geprüft werden. Die Bezeichnung Gateway garantiert kein festes Funktionspaket. Ein lokaler Tool-Aggregator kann nützlich sein, während die Integration der Unternehmensidentitäten oder die Begrenzung von Aufrufen selbst umgesetzt werden muss.

MCP-Gateway und MCP-Server: Was ist der Unterschied?

Ein MCP-Server stellt Funktionen bereit; ein MCP-Gateway steuert den Zugriff auf einen oder mehrere Server. Ein Server kann etwa eine Datenbankabfrage oder das Anlegen eines Tickets anbieten. Das Gateway stellt Clients die freigegebenen Funktionen zur Verfügung, leitet Aufrufe weiter und wendet die konfigurierten Kontrollen an.

In der MCP-Architektur ermittelt ein Client verfügbare Tools mit tools/list und ruft sie mit tools/call auf. Gegenüber dem Agenten kann ein Gateway als Server auftreten, gegenüber den dahinterliegenden Servern als Client. Welche Datensätze der Aufrufer lesen oder ändern darf, entscheidet weiterhin die zugrunde liegende Anwendung.

Die Freigabe eines Tools zum Aktualisieren von Tickets bedeutet beispielsweise nicht, dass damit jedes Kundenkonto zugänglich ist. Berechtigungen auf Datensatzebene und die Trennung von Mandanten bleiben Aufgabe der Anwendung und ihrer Serverintegration.

Worin unterscheidet es sich von einem KI- oder LLM-Gateway?

Ein KI- oder LLM-Gateway steuert Anfragen an Modelle. LLM steht für Large Language Model, also großes Sprachmodell. Ein MCP-Gateway steuert dagegen Anfragen an Tools. Dieser Unterschied bestimmt, welches Problem die jeweilige Variante lösen kann.

Cloudflare AI Gateway dokumentiert Protokollierung, Caching, Aufruflimits, Wiederholungsversuche und Ausweichoptionen für Modellanfragen. Diese Kontrollen helfen bei Inferenzkosten und der Zuverlässigkeit von Anbietern. Die Tool-Richtlinie eines MCP-Gateways kann hingegen entscheiden, ob ein Agent eine freigegebene Aktion in einem Kundensystem ausführen darf.

Manche Produkte decken beide Wege ab. Sie sollten getrennt bewertet werden: Ein Modellbudget belegt keine Tool-Berechtigung, und eine Liste zulässiger Tools begrenzt nicht jede Modellanfrage. Wenn das zu lösende Problem die Weiterleitung von Modellanfragen, Inferenzkosten oder Anbieterausfälle betrifft, hilft der Vergleich von KI-Gateways für Coding-Agenten.

Auch ein gewöhnliches API-Gateway kann HTTP-Anfragen authentifizieren und begrenzen. Eine MCP-spezifische Steuerung berücksichtigt zusätzlich, was in diesen Anfragen steckt: Tool-Erkennung, Tool-Namen und Aufrufargumente. Mehrere Aktionen können dieselbe URL /mcp nutzen. Eine Regel, die lediglich diese URL freigibt, kann deshalb wesentlich mehr erlauben als die beabsichtigte Tool-Richtlinie.

Was hat sich am 24. September 2026 tatsächlich geändert?

Cloudflare hat MCP Server Portals am 24. September 2026 für alle Cloudflare-Kunden allgemein verfügbar gemacht. Die Ankündigung des Anbieters beschreibt einen gemeinsamen Endpunkt für freigegebene Server sowie Access-Protokolle für Tool-, Prompt- und Ressourcenaktivitäten.

Die Veröffentlichung nennt außerdem die Authentifizierung autonomer Agenten über Service-Tokens, die Weiterleitung über Gateway für umfangreichere HTTP-Protokollierung und Data Loss Prevention sowie Logpush zum Export von Aktivitäten. Data Loss Prevention, kurz DLP, prüft Inhalte anhand von Regeln für sensible Informationen.

Damit gibt es eine verwaltete Möglichkeit, den Zugriff auf entfernte MCP-Server zu zentralisieren, ohne den Gateway-Prozess selbst zu betreiben. Die Verfügbarkeit lässt allerdings zwei Fragen offen: Sind die eigenen Server und Clients kompatibel, und enthält der Tarif die benötigten Audit-Funktionen?

MCP-Gateways gab es bereits als Architekturmuster. Die Veröffentlichung verändert die Verfügbarkeit einer verwalteten Lösung. Sie macht ein Gateway nicht zur Pflicht für jede MCP-Verbindung.

Wann brauchen kleine Teams ein Gateway für MCP Server?

Ein Gateway wird nötig, wenn Zugriffsentscheidungen unabhängig vom verwendeten Client, von Personalwechseln oder von der Serververantwortung Bestand haben müssen. Mehr als eine Handvoll Server ist ein brauchbares Warnsignal. Stärker wiegt jedoch, dass Richtlinien an verschiedenen Stellen auseinanderlaufen.

Handlungsbedarf entsteht, wenn derselbe Entwickler mehrere Clients nutzt und jeder Client dieselben eingeschränkten Tools benötigt. Er entsteht auch, wenn der Betrieb Zugriffe entziehen, eine Aktion rekonstruieren oder gemeinsame Regeln für sensible Tools und Tools mit Schreibzugriff durchsetzen muss. Eine kleine Umgebung mit einer folgenreichen Schreibaktion kann diesen Aufwand früher rechtfertigen als eine große Sammlung von Tools für öffentliche Dokumentation.

Als Beispiel dient eine Umgebung mit sechs Entwicklern, vier Agenten-Clients und acht MCP-Servern, in der jeder Entwickler jeden Server in jedem Client konfiguriert:

• Direkte Konfiguration: 6 × 4 × 8 = 192 Client-Server-Einträge.
• Ein gemeinsames Gateway: 6 × 4 = 24 Client-Gateway-Einträge, dazu 8 Definitionen vorgelagerter Endpunkte.
• Endpunktreferenzen insgesamt: 32.

Das ist unsere Konfigurationsrechnung, kein beobachtetes Deployment und kein Leistungsergebnis. Möglicherweise werden Einstellungen bereits zentral verteilt, und verschiedene Rollen können unterschiedliche Gateways oder Profile benötigen. Auch OAuth-Freigaben für vorgelagerte Dienste – also die Berechtigungen, die einzelne Nutzer einem Dienst erteilen – bleiben von den Endpunktdefinitionen getrennt.

Der Nutzen liegt darin, dass sich eine freigegebene Serveradresse oder eine Tool-Richtlinie zentral ändern lässt. Auch zentral können Fehler passieren. Deshalb sollten Richtlinien versioniert und Änderungsberechtigungen festgelegt werden.

Abwarten ist sinnvoll, wenn eine verantwortliche Person eine kleine, risikoarme Tool-Sammlung bereits mit vorhandenen Identitätskontrollen und einer gemeinsamen Konfiguration verwalten kann. Ein Gateway bringt einen weiteren Dienst, eine zusätzliche Abhängigkeit und eine weitere Ausfallmöglichkeit mit. Es sollte ein konkret benanntes Betriebsproblem lösen.

Kein Handlungsbedarf besteht, wenn die Agenten keine MCP-Tools nutzen. Geht es ausschließlich um die Kontrolle von Modellanfragen, beginnt die Entscheidung auf der LLM-Seite. Setzt die Anwendung die benötigte Tool-Richtlinie und Protokollierung bereits durch, ist ein Gateway erst dann sinnvoll, wenn es diese Kontrolle verbessert.

Was Entwicklung, Betrieb und Einkauf beachten müssen

Entwicklung: Zuerst den Transport klären

Das Gateway muss die eingesetzten Server erreichen können. Bei stdio kommuniziert ein Client über Ein- und Ausgabeströme mit einem lokalen Prozess. Streamable HTTP transportiert MCP-Verkehr zu einem entfernten Endpunkt. Die Protokollarchitektur beschreibt beide Varianten.

Ein verwaltetes Gateway für entfernte Server kann nicht automatisch einen stdio-Prozess auf einem Laptop starten. Diesen Prozess als gehosteten HTTP-Dienst bereitzustellen, verursacht Aufwand für Deployment und Zugangsdaten. Die Transportkompatibilität muss feststehen, bevor Client-Einstellungen ersetzt werden.

Betrieb: Den tatsächlichen Zugriffsweg kontrollieren

Eine gemeinsame Richtlinie hilft nur, wenn die relevanten Aufrufe auch durch sie laufen. Neben Gateway-Verbindungen gehören deshalb direkte Zugangsdaten und Endpunkte ins Inventar. Es muss festgelegt werden, wie zugelassene Clients Tools erreichen, wo Vorfälle protokolliert werden und wer bei einem Gateway-Ausfall für die Wiederherstellung verantwortlich ist.

Bei einem Support-Workflow muss sich nachvollziehen lassen, welche Identität mit welcher Aktion ein Ticket verändert hat. Ein Protokoll über eine erfolgreiche Verbindung allein beantwortet diese Frage nicht. Die vom gewählten Produkt erzeugten Einträge müssen geprüft werden; verschiedene Protokollierungsfunktionen liefern nicht automatisch dieselben Nachweise.

Einkauf: Die benötigten Kontrollen finanzieren

Ins Budget gehören das Gateway, die dahinterliegenden Server und die Person, die für beides verantwortlich ist. Ein Free-Tarif kann für die Nutzerzahl ausreichen und trotzdem die geforderte Aufbewahrungsdauer verfehlen. Open-Source-Software kann zum Deployment passen und dennoch eine zusätzliche Identitätsintegration erfordern.

Geht der Bedarf über diese Aufgaben hinaus und umfasst die Erkennung nicht freigegebener Server, detaillierte Prüfungen zur Laufzeit oder die Reaktion auf Sicherheitsvorfälle im Unternehmen, behandelt der Vergleich von MCP-Sicherheitsplattformen diese umfassendere Beschaffung.

Drei MCP-Gateways im Vergleich: geprüft am 4. Oktober 2026

Cloudflare eignet sich für die verwaltete Kontrolle entfernter Zugriffe, Docker für den Betrieb containerisierter Server und Lasso für eine Orchestrierung mit Plugins. Entscheidend sind Transport, Zugriffssteuerung, Protokollierung und die Frage, wer den Dienst betreibt.

Die folgenden Preise und Lizenzen wurden am 4. Oktober 2026 anhand der öffentlichen Seiten und Repositories der Anbieter geprüft. Die späteren Kostenszenarien sind Berechnungen mit ausdrücklich genannten Annahmen.

Quellen: Cloudflare-Tarife, Docker-Lizenz und Lasso-Lizenz.

Cloudflare MCP Server Portals

Cloudflare MCP Server Portals ist die verwaltete Lösung für freigegebene entfernte MCP-Server, wenn Cloudflare One zu den Anforderungen an Identität und Betrieb passt. Die Lösung bündelt Server hinter einem HTTP-Endpunkt, nutzt Cloudflare Access zur Authentifizierung und lässt Administratoren festlegen, welche Tools und Prompts ein Portal bereitstellt.

Die aktuelle Tarifübersicht führt Free für $0 mit einem Limit von 50 Nutzern, Pay-as-you-go für $7 pro Nutzer/Monat und einen Contract-Tarif mit einem individuell vereinbarten Jahrespreis pro Nutzer auf. Als reguläre Aufbewahrungsdauer für Protokolle nennt sie bis zu 24 Stunden bei Free und bis zu 30 Tage bei Pay-as-you-go; die Dauer hängt vom verwendeten Dienst ab.

Die Grenzen liegen bei der Kompatibilität und den Audit-Berechtigungen. Laut Cloudflares Portal-Dokumentation werden entfernte HTTP-MCP-Server unterstützt, mit bis zu 80 Servern pro Portal. Ein Server, der ausschließlich stdio unterstützt, muss zunächst hinter einem authentifizierten HTTP-Endpunkt gehostet werden. Manche vorgelagerten Server lehnen Clients ab, die über einen Proxy zugreifen.

Auch Portal-Protokollierung und externer Protokollexport sind getrennte Beschaffungsfragen: Cloudflares Logpush-Integration ist nur für Enterprise verfügbar. Diese Berechtigung sollte geklärt sein, bevor für ein Audit ein externes Archiv zugesagt wird.

Cloudflare kommt für kompatible entfernte Tools infrage, wenn eine gemeinsame Kontrollstelle benötigt wird, ohne selbst die Rechenressourcen für das Gateway zu betreiben. Der Artikel Ist Cloudflare MCP Portals kostenlos? behandelt die getrennten Kosten für Nutzerzahl, Hosting und Audit.

Docker MCP Gateway

Docker MCP Gateway ist die Open-Source-Option, wenn auch der Betrieb der MCP-Server gelöst werden muss. Es startet Server in isolierten Containern, verwaltet ihren Lebenszyklus, übernimmt Zugangsdaten und Weiterleitung und fasst verfügbare Server in Profilen zusammen. Ein Profil ist eine gespeicherte Serverauswahl, die einem Client zur Verfügung gestellt wird.

Der eigenständig nutzbare Gateway-Code steht unter der MIT-Lizenz. Docker dokumentiert die manuelle Installation mit Docker Engine ebenso wie die Variante mit Docker Desktop. Host, Updates, Zugangsdaten und Deployment-Konzept bleiben in eigener Verantwortung.

Für Docker Desktop gelten gesonderte kommerzielle Bedingungen. Laut Dockers Lizenzseite müssen berechtigte kleine Unternehmen weniger als 250 Beschäftigte und weniger als $10 Millionen Jahresumsatz haben, um Desktop kostenlos kommerziell nutzen zu dürfen. Größere Organisationen und staatliche Einrichtungen benötigen ein kostenpflichtiges Abonnement. Docker Pro kostet $11 pro Nutzer/Monat bei monatlicher Abrechnung oder $9 pro Nutzer/Monat im Jahresabo. Das sind Kosten des Desktop-Abonnements, keine Gebühren für den Gateway-Code.

Daneben führt Dockers aktuelle Gateway-Dokumentation MCP Gateway als Teil von Docker AI Governance als separates, nur auf Einladung zugängliches Angebot auf; der Zugang erfolgt über den Vertrieb. Das öffentliche MIT-Repository bleibt die Option für den eigenständigen Code. Der Lizenzpreis des Repositories darf daher nicht als Preis des kommerziellen Governance-Angebots angesetzt werden.

Docker passt, wenn Container-Isolation und Serverbetrieb wichtig sind und jemand die Laufzeitumgebung verantwortet. Ein Gateway auf jedem Laptop kann lokale Tools bündeln. Gemeinsame Unternehmensrichtlinien und der Zugriff entfernter Clients erfordern weiterhin ein bewusst geplantes Deployment.

Lasso MCP Gateway

Lasso MCP Gateway vermittelt mit Plugins zwischen MCP-Anfragen und -Antworten. Es liest Serverkonfigurationen, verwaltet die konfigurierten Server und stellt ihre Funktionen über eine einheitliche Schnittstelle bereit. Das Repository enthält Beispiele für Cursor und Claude Desktop.

Der Gateway-Code steht unter der MIT-Lizenz. Das Plugin basic maskiert Tokens und Secrets. Das optionale Plugin presidio maskiert personenbezogene Informationen. xetrack ergänzt Tracing mit Ereignissen in SQLite und erfordert eine eigene Installation.

Entscheidend ist, wo das jeweilige Plugin arbeitet. Das Plugin lasso benötigt einen Lasso-API-Schlüssel und übermittelt Inhalte zur Prüfung an die API von Lasso. Aus der MIT-Lizenz des Gateways lassen sich weder Preis noch Nutzungsbedingungen dieser gehosteten API ableiten; auch die README nennt keinen Preis dafür. Bei der Budgetplanung und der Entscheidung, wohin Inhalte übertragen werden dürfen, ist sie als eigenständige Dienstabhängigkeit zu berücksichtigen.

Lasso passt, wenn die Verarbeitung von Anfragen und Antworten erweitert werden soll und der umgebende Betrieb selbst verantwortet werden kann. Die README belegt keinen schlüsselfertigen Dienst für gemeinsame Identitäten, nutzerspezifische Tool-Berechtigungen und Aufruflimits. Sind diese Kontrollen der Grund für die Einführung eines Gateways, müssen sie ausdrücklich eingefordert werden.

Was kostet der Betrieb eines MCP-Gateways?

Die Softwarelizenz ist nur ein Posten im Budget. Getrennt zu betrachten sind Gebühren für Gateway-Software oder Abonnements, Rechenressourcen und Protokolle, der Betriebsaufwand sowie die Modelle und vorgelagerten Anwendungen des Workflows.

Bei einem verwalteten Dienst zählen die Abrechnung nach Nutzerplätzen oder Nutzung sowie benötigte Zusatzoptionen für Export oder Sicherheit dazu. Beim Eigenbetrieb kommen Rechenressourcen für Gateway und Server, Protokollaufbewahrung, Updates, Verwaltung der Zugangsdaten und Wiederherstellung hinzu. Hinter einem kostenlosen Gateway können ein kostenpflichtiges SaaS-Konto und ein kostenpflichtiges Modell stehen.

Ein Planungsbeispiel für ein kleines Team: Angenommen wird ein interner Vollkostensatz für Personal von $100/Stunde, der auch Gemeinkosten umfasst. Für zusätzliche Rechenressourcen und Protokolle im Eigenbetrieb werden $20/Monat angesetzt. Das sind gewählte Budgetannahmen, keine Anbieterangebote und keine gemessenen Hosting-Anforderungen.

Unter diesen Annahmen spart der Eigenbetrieb $180/Monat gegenüber dem Betreuungsaufwand für die direkte Konfiguration. Er kostet $220/Monat, obwohl die Lizenzgebühr für den Gateway-Code $0 beträgt. Nimmt die Einführung acht Personalstunden in Anspruch, kommen $800 hinzu. Die Schätzung für das erste Jahr lautet 12 × $220 + $800 = $3,440, gegenüber $4,800 für den genannten Betreuungsaufwand direkter Verbindungen.

Diese Einsparungen hängen vollständig davon ab, ob das Gateway den Betreuungsaufwand wie angenommen senkt. Die bisherigen Zeiten sollten gemessen und die Annahmen durch eigene Werte ersetzt werden. Eine direkte Anbindung, die sich mit einer einfachen gemeinsamen Konfiguration pflegen lässt, kann deutlich weniger kosten.

Anbieterpreise auf die eigene Umgebung übertragen

Bei sechs aktiven Cloudflare-Nutzern kann Free innerhalb des Kontingents von 50 Nutzern $0 Cloudflare-Tarifkosten bedeuten. Im Szenario mit einem kompatiblen verwalteten Gateway aus der Tabelle lägen die angenommenen internen Personalkosten für Richtlinien trotzdem bei $50/Monat. Gehostete vorgelagerte Server, Modellnutzung, Abonnements und Zusatzoptionen sind darin nicht enthalten.

Für 60 gekaufte Pay-as-you-go-Nutzerplätze ergibt der veröffentlichte Preis von $7 60 × $7 = $420/Monat beziehungsweise $5,040/Jahr. Diese Rechnung berücksichtigt alle 60 bezahlten Plätze. Das Limit von 50 Nutzern gehört zum eigenständigen Free-Tarif; in dieser Berechnung werden keine 50 Plätze abgezogen. Laut Cloudflares Dokumentation zur Platzverwaltung richtet sich die Zahl verfügbarer Plätze nach den gekauften Nutzern. Eine Identität belegt einen Platz, unabhängig von den genutzten Anwendungen.

Für sechs neue monatliche Docker-Pro-Abonnements, sofern sie für die gewählte Desktop-Variante erforderlich sind, ergeben sich anhand von Dockers eigenem Preis 6 × $11 = $66/Monat. Sind passende Abonnements bereits vorhanden, können die zusätzlichen Abonnementkosten $0 betragen. Ein Deployment mit Docker Engine hat ein eigenes Infrastrukturbudget.

Bei Lasso bildet der MIT-Gateway-Code den Ausgangspunkt; hinzu kommen die Budgets für Host und Protokollierung. Wird das Plugin mit API-Abhängigkeit aktiviert, müssen die Bedingungen des gehosteten Dienstes separat eingeholt werden. Eine Abhängigkeit ohne bekannten Preis lässt sich nicht seriös mit $0 budgetieren.

Direkte Verbindung, Eigenbetrieb oder verwaltetes Gateway?

Direkte Verbindungen bleiben sinnvoll, solange die vorhandenen Kontrollen den Workflow abdecken. Das passt zu einer kleinen, kontrollierten Tool-Sammlung mit klarer Verantwortung und einem praktikablen Verfahren für Zugriffsentzug und Audit. Die Entscheidung sollte überprüft werden, sobald ein weiterer Client, eine neue Rolle oder eine sensible Aktion die Richtlinien auseinanderlaufen lässt.

Selbst betriebene Open-Source-Software passt, wenn die Verantwortung für die Laufzeitumgebung klar benannt werden kann. Für containerisierte MCP-Server ist Docker der naheliegendere Ausgangspunkt. Lasso ist das passendere Beispiel, wenn Anfragen mit Plugins abgefangen und verarbeitet werden sollen. Identitätsintegration, Hosting und Protokolle gehören separat ins Budget; die benötigten Kontrollen müssen nachgewiesen werden.

Eine verwaltete Lösung passt, wenn kompatible entfernte Tools gemeinsame Richtlinien benötigen und der Gateway-Betrieb nicht selbst übernommen werden soll. Für eine kleine Cloudflare-One-Umgebung ist Cloudflare ein praktischer erster Prüfpunkt. Vor einer breiten Einführung müssen Transport, Autorisierung der vorgelagerten Dienste, Tool-Richtlinien und der erforderliche Audit-Tarif geprüft werden.

Eine einzige Anforderung kann die Entscheidung verändern: Erreicht die verwaltete Lösung die eigenen Server nicht oder bietet sie die erforderlichen Kontrollen nicht, muss jemand den Eigenbetrieb übernehmen oder die kontrollierte direkte Anbindung bestehen bleiben. Eine lange Funktionsliste gleicht fehlende Eignung für den eigenen Betrieb nicht aus.

Welche Erwartungen an MCP-Gateways zu weit gehen

Eine gemeinsame URL schafft nicht automatisch ein verlässliches Berechtigungssystem. Das größte Missverständnis ist die Annahme, mit der Anbindung an ein Gateway seien Autorisierung, Audit und Sicherheit in einem Schritt erledigt.

Auf eine Portal-Anmeldung kann weiterhin eine OAuth-Autorisierung beim vorgelagerten Dienst folgen. Sowohl die Gateway-Richtlinie als auch die Datensatzberechtigungen der dahinterliegenden Anwendung zählen. Die Sicherheitsempfehlungen von MCP warnen ausdrücklich davor, Tokens für andere Ressourcen anzunehmen und unverändert weiterzureichen.

Ebenso ist die Freigabe eines Tools nur ein Teil der Kontrolle seiner Nutzung. Eine erlaubte Aktion kann trotzdem unsichere Argumente erhalten oder den falschen Mandanten betreffen, wenn die Serverintegration das zulässt. Das Maskieren von Antworten ersetzt weder Anwendungsberechtigungen noch die menschliche Freigabe folgenreicher Aktionen.

Cloudflare liefert ein konkretes Beispiel für eine Richtliniengrenze. Laut Portal-Dokumentation werden separate MFA, Zweckbegründung und temporäre Authentifizierung nicht durchgesetzt, wenn ein Server über ein Portal autorisiert wird. Auswahlkriterien wie Gruppen und Gerätezustand gelten dagegen weiterhin. MFA bezeichnet einen zusätzlichen Authentifizierungsfaktor. Diese Richtlinieneinschränkung sollte bekannt sein, bevor das Portal als Freigabeprozess eingeplant wird.

Schließlich kann ein Gateway keinen Tool-Verkehr protokollieren, der an ihm vorbeiläuft. Der freigegebene Zugriffsweg muss festgelegt werden, die Berechtigungen der vorgelagerten Dienste müssen erhalten bleiben und die Serverwartung gehört weiterhin zum Aufgabenbereich. Das Produkt ergänzt eine nützliche Kontrollstelle. Wie vollständig sie absichert, bestimmt die verantwortliche Person.

Der nächste Schritt am Montag

Einen Workflow pilotieren und die benötigte Kontrolle nachweisen. Dafür werden aus diesem Workflow ein risikoarmes Tool und ein Tool mit folgenreichen Aktionen gewählt. Getestet wird mit den Agenten-Clients, auf die sich der Betrieb bereits verlässt.

1. 1

   Bestehende Verbindungen erfassen

   Für jede Verbindung Client, Serverendpunkt, Transport, Verantwortung für Zugangsdaten, bereitgestellte Tools und Protokollziel festhalten. Die wiederkehrende Richtlinienänderung benennen, die zentralisiert werden soll. Die bestehende Client-Konfiguration für eine Rückkehr zum bisherigen Stand sichern.

2. 2

   Den Betriebsweg auswählen

   Direkte Verbindungen verwenden, wenn die vorhandenen Kontrollen ausreichen. Einen Pilotversuch im Eigenbetrieb nur mit klarer Verantwortung für die Laufzeitumgebung beginnen. Für einen Cloudflare-Pilotversuch unter Zero Trust > Access controls > MCP Portals kompatible HTTP-Server hinzufügen, Access-Richtlinien für Server und Portal zuweisen und die zulässigen Tools und Prompts auswählen.

3. 3

   Tool-Erkennung und Aufrufe prüfen

   Jeden ausgewählten Client mit der von ihm unterstützten Methode verbinden. Prüfen, ob die risikoarme Aktion verfügbar und aufrufbar ist und eine verbotene Aktion auch bei ausdrücklicher Anforderung abgewiesen wird. Neben der Tool-Liste des Gateways auch die Datenberechtigungen der vorgelagerten Dienste prüfen.

4. 4

   Zugriff entziehen und Protokolle nachvollziehen

   Der Pilotidentität die Berechtigung entziehen und bestätigen, dass der nächste Aktionsversuch scheitert. Die erlaubten und abgewiesenen Anfragen in den vom Produkt bereitgestellten Aufzeichnungen finden. Prüfen, ob Protokollziel und Aufbewahrungsdauer die Anforderungen erfüllen.

5. 5

   Kosten erfassen und Verantwortung festhalten

   Abonnementgebühren, vorgelagertes Hosting, Protokollierung und Personalaufwand erfassen. Erst ausweiten, wenn Richtlinie und Wiederherstellungsweg funktionieren. Dokumentieren, wie die Rückkehr zur vorherigen kontrollierten Konfiguration gelingt, ohne einen unkontrollierten Umweg zu schaffen.

Häufige Fragen

Was ist ein MCP-Gateway?

Ein MCP-Gateway ist eine Kontrollstelle zwischen KI-Clients und MCP-Servern. Es kann Authentifizierung, Listen zulässiger Tools, Protokollierung, Aufruflimits und Weiterleitung zentralisieren. Jede Kontrolle muss in der konkreten Implementierung geprüft werden; nicht jeder Aggregator bietet sie automatisch.

Was unterscheidet ein MCP-Gateway von einem MCP-Server?

Ein MCP-Server stellt Tools, Ressourcen und Prompts bereit. Ein Gateway steuert den Zugriff auf einen oder mehrere Server und kann freigegebene Funktionen über eine gemeinsame Schnittstelle anbieten. Die eigentliche Arbeit wird weiterhin vom dahinterliegenden Server und der Anwendung ausgeführt und autorisiert.

Wann brauchen wir ein MCP-Gateway?

Wenn mehrere Clients oder Rollen eine gemeinsame Tool-Richtlinie, einen einheitlichen Zugriffsentzug oder einen gemeinsamen Audit-Weg benötigen. Direkte Verbindungen können weiterhin passen, wenn eine verantwortliche Person diese Anforderungen bereits erfüllt. Das Protokoll schreibt kein Gateway ab einer bestimmten Serverzahl vor.

Was unterscheidet einen MCP Proxy von einem MCP-Gateway?

Ein einfacher Proxy leitet Verkehr weiter. Ein MCP-fähiges Gateway kann Tool-Erkennung und Tool-Aufrufe verstehen, Funktionen bündeln und toolspezifische Richtlinien anwenden. Da MCP-Aktionen denselben HTTP-Endpunkt nutzen können, reichen URL-Berechtigungen allein möglicherweise nicht aus, um die gewünschten Aktionen einzuschränken.

Funktioniert MCP wie ein API-Gateway?

MCP selbst ist ein Protokoll. Ein MCP-Gateway übernimmt eine ähnliche Rolle wie ein API-Gateway, steuert aber MCP-Funktionen und -Aufrufe. In derselben Architektur kann weiterhin ein API-Gateway für HTTP-Authentifizierung, Netzwerkkontrollen oder die Begrenzung von Anfragen eingesetzt werden.

Sind MCP und HTTP dasselbe?

Nein. MCP definiert Nachrichten und Funktionen; HTTP ist ein Weg, diese Nachrichten zu entfernten Servern zu transportieren. Für lokale Prozesse unterstützt MCP außerdem stdio. Dieser Transportunterschied erklärt, warum ein verwaltetes HTTP-Gateway nicht jeden ausschließlich lokal nutzbaren Server direkt einbinden kann.

Warum MCP statt REST verwenden?

MCP bietet kompatiblen KI-Clients einen gemeinsamen Weg, Tools zu ermitteln und aufzurufen. Ein Server kann eine vorhandene REST-API einbinden, sodass REST darunter bestehen bleiben kann. Entscheidend ist die Schnittstelle, die die tatsächlich eingesetzten Clients benötigen. Die Ergänzung um MCP erfordert keine Neuentwicklung jeder Anwendungs-API.

Basiert MCP auf JSON?

Ja. MCP verwendet JSON-RPC 2.0 für Anfragen, Antworten und Benachrichtigungen. Das Protokoll legt die Bedeutung dieser Nachrichten fest, einschließlich Tool-Erkennung und -Aufrufen. Es ist damit mehr als ein allgemeiner JSON-Endpunkt.

Was unterscheidet MCP von RAG?

MCP ist ein Integrationsprotokoll für Tools und Daten. RAG, kurz für Retrieval-Augmented Generation, ruft Informationen ab, die in die Antwort eines Modells einfließen. Ein Abruf-Tool kann über MCP bereitgestellt werden; beides lässt sich also kombinieren. Ein Gateway allein verbessert die Qualität des Informationsabrufs nicht.

Weitere praktische Infrastrukturentscheidungen und Preisprüfungen mit Datumsangabe gibt es im Newsletter.