Was ist ein MCP-Gateway? Ein Praxisleitfaden für Enterprise-KI-Teams

Warum benötigen KI-Agenten eine standardisierte Integrationsschicht?

Die erste Generation von LLM-Systemen war weitgehend passiv. Man sendete einen Prompt und erhielt einen Text. War die Antwort falsch, war das zwar ärgerlich, aber nicht katastrophal. Dieses Modell gilt heute nicht mehr.

Moderne KI-Agenten fragen Datenbanken ab, bearbeiten Tickets, versenden E-Mails und lösen nachgelagerte Automatisierungen aus. Sie generieren nicht nur Sprache. Sie setzen Absichten in die Tat um. Und sobald Ausführung ins Spiel kommt, ist die Architektur wichtiger als Prompt-Engineering.

Die meisten Teams beginnen mit direkten Integrationen. Ein Agent erhält einen GitHub-API-Schlüssel. Ein anderer bekommt Slack-Zugangsdaten. Ein dritter verbindet sich mit dem CRM. Jede Integration wird unabhängig entwickelt, oft innerhalb des Anwendungscodes oder in Wrapper-Skripten. Das fühlt sich schnell an. Und es ist auch schnell. Aber es ist nicht skalierbar.

Jeder Agent verwaltet seine eigenen Anmeldedaten. Zugriffsregeln sind verstreut. Die Beobachtbarkeit wird über verschiedene Systeme hinweg fragmentiert. Das Hinzufügen eines neuen Tools erfordert die Einrichtung einer weiteren direkten Verbindung. Bald hat niemand mehr einen klaren Überblick darüber, welcher Agent auf welches System zugreifen darf.

Das Muster sieht in etwa so aus:

Es gibt keine Steuerungsebene. Kein zentrales Audit-Protokoll. Keine einheitliche Richtliniendurchsetzung.

Mit zunehmender Anzahl an Agenten wird diese Topologie anfällig. Was als Flexibilität beginnt, entwickelt sich allmählich zu einem betrieblichen Risiko. Bei einer standardisierten Integrationsschicht geht es nicht um Eleganz. Es geht um Eindämmung.

Was ist das Model Context Protocol (MCP)?

DieModel Context Protocol, oder MCP, ist ein offenes Protokoll, das definiert, wie KI-Modelle externe Tools entdecken und mit ihnen interagieren. Anstatt dass jedes Modell auf unterschiedliche Weise in jede API integriert werden muss, führt MCP eine gemeinsame Sprache zwischen Agenten und Systemen ein. Es baut auf Konzepten auf, die dem Language Server Protocol ähneln, und wendet dieselbe Idee der standardisierten Fähigkeitsaushandlung auf die Nutzung von KI-Tools an.

Im Kern verwendet MCP JSON-RPC über HTTP. Wenn sich ein MCP-Client mit einem MCP-Server verbindet, führt er einen Erkennungsschritt durch. Das Modell sendet eine tools/list-Anfrage, um zu verstehen, welche Tools verfügbar sind.

{

 "method": "tools/list"

}

Der Server antwortet mit einer strukturierten Liste von MCP-Tools, einschließlich ihrer Namen, Eingabeschemata und erwarteten Ausgaben. Von dort aus kann der Agent ein bestimmtes Tool mithilfe einer call_tool-Methode aufrufen und dabei Argumente übergeben, die dem deklarierten Schema entsprechen.

Dieser Handshake ist entscheidend. Er standardisiert die Erkennung und den Aufruf von Funktionen über verschiedene Anbieter und Systeme hinweg. Ein GitHub-Connector und ein Postgres-Connector stellen Tools im Backend unterschiedlich bereit, aber durch MCP bieten sie dem Modell eine einheitliche Schnittstelle.

Effektiv beseitigt MCP die kombinatorische Explosion benutzerdefinierter Integrationen. Anstatt für jede Modell-Tool-Paarung maßgeschneiderten Verbindungscode zu schreiben, implementieren Teams MCP-Servern einmalig und ermöglichen es Modellen, über ein einheitliches Protokoll zu interagieren. Dies hat sich zum MCP-Standard dafür entwickelt, wie KI-Modelle über das gesamte MCP-Ökosystem hinweg mit Backend-Diensten und Datenquellen kommunizieren.

Doch Protokollstandardisierung ist nicht dasselbe wie Governance. Diese Unterscheidung wird wichtig.

Was ist ein MCP-Gateway?

Wenn MCP definiert, wie Modelle mit Tools kommunizieren, definiert ein MCP-Gateway, wer sprechen darf und unter welchen Bedingungen.

Ein MCP-Gateway steht zwischen KI-Agenten und einem oder mehreren MCP-Servern. Anstatt dass Agenten direkte Verbindungen zu GitHub-Servern, Datenbank-Connectors oder Workflow-Engines herstellen, verbinden sie sich mit dem Gateway. Das Gateway wird zum einzigen Endpunkt: einem zentralen Eingangspunkt für die Tool-Erkennung und den Aufruf. Es fungiert als zentralisierter Proxy für den gesamten MCP-Datenverkehr.

Aus Sicht des Agenten ändert sich strukturell nichts. Er führt weiterhin einen tools/list-Handshake durch. Er sendet weiterhin call_tool-Anfragen. Doch diese Anfragen werden vom Gateway abgefangen, bewertet und weitergeleitet, bevor ein Backend-System sie ausführt.

Ein MCP-Gateway übernimmt mindestens vier Rollen.

Erstens: Steuerung der Erkennung. Es filtert, welche Tools für welche Agenten sichtbar sind.

Zweitens: Routing. Es leitet Anfragen an den entsprechenden MCP-Server weiter.

Drittens: Authentifizierung. Sie validiert die Identität und kann Anmeldeinformationen im Namen eines Benutzers weiterleiten.

Viertens: Richtliniendurchsetzung. Sie kann Ratenbegrenzungen, Bereichseinschränkungen oder Ausführungsbeschränkungen anwenden, bevor der Datenverkehr weitergeleitet wird.

Architektonisch ist der Unterschied einfach, aber tiefgreifend:

Das MCP-Gateway zentralisiert die Kontrolle, ohne einzelne Server zu verändern. MCP bleibt das Protokoll. Das Gateway wird zur Management-Ebene, die den Einsatz des Protokolls in der Produktion sicher macht.

Wo MCP allein in Unternehmensumgebungen an seine Grenzen stößt

MCP standardisiert die Interaktion. Es standardisiert nicht die Kontrolle.

Von Haus aus definiert MCP keine rollenbasierte Zugriffskontrolle. Wenn ein Agent eine Verbindung zu einem Server herstellen kann, kann er jedes Tool entdecken, das dieser Server bereitstellt. Es gibt kein natives Konzept für die Bereichseinschränkung der Sichtbarkeit pro Team, pro Workload oder pro Benutzer. Der Zugriff wird zu einem Infrastrukturproblem außerhalb des Protokolls selbst.

Es gibt zudem keine zentralisierte Audit-Ebene. Jeder MCP-Server protokolliert zwar seine eigenen Aktivitäten, aber es gibt keinen inhärenten Aggregationspunkt, der zeigt, welcher Agent welches Tool in wessen Namen und in welcher Reihenfolge aufgerufen hat. Die Rekonstruktion der Absicht über verschiedene MCP-Server hinweg wird zu einer manuellen Aufgabe.

Die Kostensteuerung weist eine ähnliche Lücke auf. MCP verfolgt weder den Token-Verbrauch noch erzwingt es Nutzungsbegrenzungen. Ein Agent kann Tools wiederholt aufrufen und so Modellabfragen oder Datenbankabfragen auslösen, ohne dass integrierte Budgetbeschränkungen greifen.

Hinzu kommt das Problem der Tool-Explosion. Wenn Unternehmen Connectors hinzufügen – GitHub, Slack, interne Dienste, Observability-Systeme –, wächst die Liste der entdeckbaren Tools. Ohne Sichtbarkeitskontrollen sind Agenten Funktionen ausgesetzt, die sie möglicherweise nicht benötigen, was die logische Schlussfolgerung erschwert und den Schadensradius vergrößert. In Echtzeit verwandelt das Fehlen von Sicherheitsrichtlinien eine Governance-Lücke in ein aktives Haftungsrisiko.

MCP ist notwendig. Es ist jedoch nicht ausreichend. Der Einsatz im Unternehmen erfordert eine zusätzliche Kontrollebene.

Was ist ein MCP-Gateway und welche Rolle spielt es in KI-Produktionssystemen?

Wie ist ein MCP-Gateway in Produktionsumgebungen am besten zu verstehen? Es ist nicht nur ein Routing-Proxy, sondern fungiert eher als eine Steuerungsebene (Control Plane), die über mehreren Ausführungsebenen (Execution Planes) liegt.

Die Ausführungsebene besteht aus MCP-Servern. Sie verbinden sich mit GitHub, Postgres, Slack, internen APIs und Altsystemen. Sie führen Aktionen aus. Sie liefern Ergebnisse zurück.

Die Steuerungsebene befindet sich am Gateway. Sie entscheidet, welcher Agent welche Tools sehen darf, unter welcher Identität und mit welchen Einschränkungen. Diese Trennung ist subtil, verändert aber die Art und Weise, wie Risiken verwaltet werden. Ein MCP-Gateway ist ein Reverse-Proxy, der speziell für MCP-Datenverkehr entwickelt wurde und Sicherheitsfunktionen bietet, die Standard-Proxys nicht bereitstellen.

Eine entscheidende Fähigkeit ist die Identitätsweiterleitung. In vielen realen Systemen handelt ein KI-Agent im Namen eines menschlichen Benutzers. Ohne Weiterleitung arbeitet der Agent oft mit einem gemeinsamen Dienstkonto. Mit einem Gateway kann die Identität des authentifizierten Benutzers über OAuth- oder OIDC-Token nachgelagert injiziert werden.

Der Ablauf sieht in etwa so aus:

Das Gateway validiert das JWT, ordnet es den Berechtigungen von Alice zu und leitet die Anfrage unter Verwendung ihrer bereichsspezifischen Anmeldeinformationen weiter. Wenn Alice kein Repository löschen darf, kann dies auch der Agent nicht, der in ihrem Namen handelt. Die Autorisierung wird auf Protokollebene durchgesetzt und nicht in Prompts vorausgesetzt.

Tool-Slicing ist eine weitere Kernfunktion. Das Gateway filtert die Antworten von tools/list und legt nur eine Teilmenge offen, die für ein bestimmtes Team oder einen bestimmten Workload relevant ist. Gefährliche Funktionen erscheinen erst gar nicht im Kontext des Agenten. Sensible Daten und Endpunkte mit hohen Privilegien bleiben für Agenten unsichtbar, die keinen Zugriff darauf haben sollten.

Schließlich erfolgt die Richtliniendurchsetzung auf Protokollebene. Bevor eine call_tool-Anfrage einen Server erreicht, kann das Gateway Argumente prüfen, Kontingente anwenden oder Vorgänge vollständig blockieren.

Bei KI-Systemen in der Produktion ist diese Vermittlungsschicht der entscheidende Unterschied zwischen Experimenten und einer steuerbaren Infrastruktur.

Sicherheits- und Betriebsrisiken ohne MCP-Gateway

Direkte Verbindungen zwischen Modell und Tool wirken effizient, bis man sich die Fehlerquellen ansieht.

Das erste Problem ist die unkontrollierte Verbreitung von Zugangsdaten. Jeder Agent führt oft seine eigenen API-Schlüssel oder Dienstkonten mit sich. Diese Schlüssel liegen in Umgebungsvariablen, Konfigurationsdateien oder geheimen Speichern, die über verschiedene Dienste verstreut sind. Das Rotieren von Zugangsdaten wird mühsam. Den direkten Zugriff für einen kompromittierten Workflow zu widerrufen, ist noch schlimmer. Es gibt keinen zentralen Kontrollpunkt.

Hinzu kommt eine übermäßige Bereitstellung von Tools. Wenn Agenten einen umfassenden direkten Zugriff auf alle verfügbaren MCP-Server erhalten, kann die Antwort auf tools/list unübersichtlich werden. Modelle arbeiten besser, wenn der Handlungsspielraum eingeschränkt ist. Das Offenlegen Dutzender lose zusammenhängender externer Tools erhöht die Komplexität der Schlussfolgerungen und steigert die Wahrscheinlichkeit einer falschen Tool-Auswahl. Mit anderen Worten: Sicherheitslage und Modellleistung verschlechtern sich gleichermaßen.

Auch die Beobachtbarkeit leidet. Ohne ein Gateway, das den MCP-Datenverkehr bündelt, erfordert die Nachverfolgung des Agentenverhaltens das Durchsuchen von Protokollen über mehrere MCP-Server hinweg. Es gibt keine einheitliche Ausführungs-Timeline. Das Debugging wird zum Ratespiel.

Schließlich gibt es noch den Schadensradius. Wenn ein Agent direkt mit Produktionssystemen und hochprivilegierten Zugangsdaten verbunden ist, verbreiten sich Fehler sofort. Eine falsch interpretierte Anweisung kann irreversible Vorgänge auslösen.

Das Fehlen einer Steuerungsschicht reduziert nicht nur die Eleganz des Systems. Es erhöht das Betriebsrisiko auf eine Weise, die sich mit der Zeit schleichend verschärft.

MCP-Gateway vs. Server

Die Terminologie kann verwirrend sein, zumal beide Komponenten MCP sprechen.

Ein MCP-Server ist ein Ausführungsorgan. Er verbindet sich mit einem spezifischen System – etwa GitHub, Slack, Postgres oder einer internen API – und stellt Tools bereit, die konkrete Aktionen ausführen. Er weiß, wie eine call_tool-Anfrage in eine Datenbankabfrage oder einen API-Aufruf übersetzt wird. Er erledigt die Arbeit.

Ein MCP-Gateway hingegen ist ein Orchestrator. Es führt keine Geschäftslogik aus. Es steuert die Zugriffskontrolle für Backend-Server. Es filtert Discovery-Antworten, erzwingt Authentifizierung, überträgt Identitäten, wendet Sicherheitsrichtlinien an und leitet Anfragen an den korrekten Ausführungsendpunkt weiter.

Der Unterschied ist struktureller Natur:

Ohne Server gibt es keine Tools. Ohne Gateways gibt es keine zentrale Steuerung. In Produktionsarchitekturen koexistieren beide Rollen normalerweise, wobei jede auf einer anderen Verantwortungsebene arbeitet. Das Hinzufügen neuer MCP-Server ist unkompliziert, wenn sie sich über ein Gateway registrieren; neue Server werden einmalig eingebunden, und ihre Tools werden selektiv statt universell verfügbar gemacht.

Ist MCP besser als ein API-Gateway?

MCP ist kein Ersatz für APIs und auch kein Ersatz für ein API-Gateway.

APIs bleiben die grundlegende Schnittstelle zwischen Systemen. Sie definieren Verträge, erzwingen Schemata und stellen Geschäftsfunktionen strukturiert bereit. API-Gateways sind diesen Schnittstellen vorgeschaltet und übernehmen Authentifizierung, Ratenbegrenzung, Verkehrsmanagement und gelegentlich Transformationen.

MCP arbeitet auf einer anderen Ebene. Es ersetzt weder REST-Endpunkte noch GraphQL. Stattdessen macht es diese APIs für KI-Modelle nutzbar. Durch standardisierte Tool-Erkennung und -Aufrufe übersetzt MCP strukturierte API-Funktionen in ein Format, das Modelle verarbeiten können. Diese Unterscheidung ist besonders wichtig für die Systemintegration, bei der sowohl traditionelle Dienste als auch KI-gesteuerte Workflows involviert sind.

In modernen Unternehmensarchitekturen koexistieren beide oft. APIs bedienen App-Dienste und Integrationen. API-Gateways steuern den traditionellen HTTP-Verkehr. MCP-Server stellen ausgewählte Funktionen für Agenten bereit. Ein MCP-Gateway regelt dann die Zugriffskontrolle für die Agenten.

Die Beziehung ist komplementär, nicht konkurrierend. Würde man APIs entfernen, bräche die Systemintegration zusammen. Würde man MCP entfernen, wären diese APIs für Modelle unsichtbar. KI-Systeme in der Produktion erfordern in der Regel das Zusammenspiel beider Schichten.

Kernfunktionen eines Enterprise-MCP-Gateways

Nicht jedes Gateway, das JSON-RPC-Datenverkehr weiterleitet, ist für den Unternehmenseinsatz geeignet. Produktionsumgebungen erfordern mehr als nur Routing. Sie benötigen Identitätsmanagement, Transparenz und eine gezielte Eingrenzung der Anwendungsbereiche – vom Kundensupport bis hin zu komplexen, mehrstufigen Workflows.

Einheitliche Authentifizierung (On-Behalf-Of-Zugriff)

In professionellen Umgebungen agieren Agenten selten allein; sie handeln im Auftrag von Benutzern. Ein Enterprise-MCP-Gateway validiert den eingehenden Benutzerkontext, in der Regel über JWT oder OIDC, und überträgt diese Identität an nachgelagerte Systeme. Anstatt einen gemeinsamen Dienstschlüssel zu verwenden, werden Anfragen im Namen eines spezifischen Benutzers ausgeführt.

Dies verhindert das Problem des „generischen Agenten“. Wenn ein Benutzer keinen Zugriff auf ein Produktions-Repository hat, kann dies auch der Agent nicht. Die Identität wird auf Protokollebene durchgesetzt und nicht erst in den Prompts vorausgesetzt.

Zentrales Tool-Verzeichnis

Ein Enterprise-MCP-Gateway verwaltet ein Verzeichnis der verfügbaren MCP-Server und -Tools. Anstatt dass jeder Agent standardmäßig alles entdeckt, wird die Sichtbarkeit zentral gesteuert. Neue Funktionen von neuen Servern werden einmalig registriert und selektiv freigegeben. Diese Konfiguration beseitigt die Dokumentationslücken, die typischerweise entstehen, wenn Teams den Überblick darüber verlieren, welche Tools existieren und wer sie nutzen darf.

Audit-Logging

Jeder Aufruf von tools/list und call_tool kann mit Metadaten protokolliert werden: Agentenidentität, Benutzerkontext, Argumente und Antwortstatus. Dies schafft einen konsistenten Audit-Trail über alle Systeme hinweg. Fehlerbehebung und Compliance-Prüfungen werden dadurch nachvollziehbar, anstatt forensische Ermittlungen zu erfordern.

Logische Gruppierung von Tools

Produktionssysteme erfordern häufig eine begrenzte Freigabe von Funktionen. Ein Support-Agent benötigt keine Datenbank-Verwaltungstools. Ein Finanz-Workflow benötigt keine Bereitstellungssteuerung. Diese Art der Eingrenzung verbessert die Benutzererfahrung direkt; Agenten verhalten sich vorhersehbarer, wenn ihr Handlungsspielraum gezielt eingeschränkt ist.

Eine einfache Konfiguration könnte wie folgt aussehen:

virtual_server:

 name: support-scope

 allow_tools:

   - github.list_issues

   - github.get_comments

   - crm.update_ticket

Das Gateway filtert Discovery-Antworten entsprechend. Agenten sehen nur das, was sie sehen sollen.

Enterprise-Fähigkeit bedeutet nicht, mehr Tools hinzuzufügen. Es geht darum, die unkontrollierte Angriffsfläche zu reduzieren.

Wie hilft das MCP-Gateway von TrueFoundry Unternehmen?

Das MCP-Gateway von TrueFoundry ist für den Betrieb dort konzipiert, wo sich Enterprise-Workloads tatsächlich befinden: innerhalb der Cloud-Umgebung des Kunden. Es kann in einer dedizierten VPC mittels Docker-Containern bereitgestellt werden, was bedeutet, dass Tool-Traffic, Anmeldedaten und Modellinteraktionen keine externe, gemeinsam genutzte Infrastruktur durchlaufen müssen. Für regulierte Branchen reduziert allein dieses Bereitstellungsmodell den Aufwand erheblich.

Die Zugriffskontrolle erfolgt über eine fein abgestufte rollenbasierte Zugriffskontrolle (RBAC) für Agenten, MCP-Tools und Teams. Anstatt Anmeldedaten fest in Agenten-Runtimes zu kodieren, integriert sich das Gateway in zentralisierte Identitätsanbieter und verknüpft Rollen mit einer bereichsspezifischen Tool-Sichtbarkeit. Sicherheitsrichtlinien sind deklarativ. Die Autorisierung erfolgt vor der Ausführung.

Die Verwaltung von Anmeldedaten ist ein weiterer praktischer Aspekt. API-Schlüssel und Service-Token werden zentral gespeichert und verwaltet, anstatt sie in Code oder Umgebungsdateien einzubetten. Rotationsrichtlinien können einmalig auf Ebene des MCP-Gateways angewendet werden, anstatt sie über Dutzende von Agenten hinweg zu pflegen.

Sichere Testumgebungen sind ebenso wichtig. Teams können isolierte Tool-Bereiche für Staging-Agenten definieren, um einen versehentlichen direkten Zugriff auf Produktionssysteme zu verhindern. Diese Trennung wird strukturell durchgesetzt, nicht nur durch Konventionen.

Observability verbindet das System. Tool-Aufrufe, Identitätsweitergabe, Telemetrie und Richtlinienentscheidungen sind vollständig nachvollziehbar. Metriken zu Nutzungsmustern, Latenz und MCP-Traffic werden in einem einzigen Dashboard angezeigt. Wenn etwas nicht wie erwartet funktioniert, können Sie die Ausführungskette untersuchen, ohne Ereignisse über mehrere Systeme hinweg rekonstruieren zu müssen.

Das Ziel ist nicht Abstraktion um ihrer selbst willen. Es geht um Eindämmung, Klarheit und kontrollierte Ausführung über MCP-Automatisierungsplattformen innerhalb einer Infrastruktur, die Sie bereits kontrollieren.

MCP-Gateway vs. traditionelle Ansätze

Wenn Teams MCP-Gateways bewerten, findet der eigentliche Vergleich nicht nur mit anderen Gateways statt. Er findet mit den Alternativen statt, die sie bereits nutzen.

Ein detaillierter Vergleich zur Positionierung von TrueFoundry.

Direkte Zugriffskontrolle maximiert zwar die Geschwindigkeit, lässt die Kontrolle jedoch verteilt und anfällig. Ein API-Gateway verbessert zwar die Sicherheit am Perimeter, versteht jedoch weder die Absicht des Agenten noch den Umfang der Tools. Das beste MCP-Gateway führt eine Management-Ebene ein, die speziell auf modellgesteuerte Ausführung und MCP-Datenverkehr ausgelegt ist.

Der Unterschied ist subtil, entscheidet aber darüber, ob KI-Systeme Experimente bleiben oder zu einer echten Infrastruktur werden.

Demo buchen um mehr darüber zu erfahren, wie das TrueFoundry MCP-Gateway in Unternehmensumgebungen funktioniert.

Abschließende Gedanken zu MCP-Gateways

MCP bietet eine gemeinsame Sprache zwischen Modellen und Tools. Das allein ist ein bedeutender Fortschritt. Es reduziert die unkontrollierte Ausbreitung von Integrationen und standardisiert, wie Agenten externe Systeme entdecken und aufrufen. Doch Standardisierung ist nicht gleich Governance.

Je näher KI-Agenten an operative Systeme heranrücken, desto entscheidender wird die Architektur um sie herum. Wer darf welche Tools sehen? Unter wessen Identität werden Aktionen ausgeführt? Wo werden Audit-Protokolle gespeichert? Wie wird das Risiko eingedämmt? Diese Fragen liegen oberhalb der Protokollebene.

Ein MCP-Gateway beantwortet diese Fragen, indem es Kontrolle einführt, ohne die Interoperabilität zu beeinträchtigen.

Für Unternehmen findet der eigentliche Wandel im Denken statt. Agenten sind keine Experimente mehr, die an APIs hängen. Sie sind Akteure innerhalb der Produktionsinfrastruktur. Sobald man das akzeptiert, wird die Notwendigkeit einer Steuerungsebene weniger optional und mehr strukturell.

Häufig gestellte Fragen

Was macht ein MCP-Gateway?

Ein MCP-Gateway fungiert als Schnittstelle zwischen KI-Agenten und MCP-Servern. Es steuert, welche Tools ein Agent sehen darf, erzwingt Authentifizierung, leitet Anfragen weiter und protokolliert Aktivitäten. Anstatt dass Agenten direkt eine Verbindung zu Systemen wie GitHub oder Datenbanken herstellen, verbinden sie sich mit dem Gateway, das als Steuerungsebene dient. TrueFoundry operationalisiert dies durch eine einheitliche Schnittstelle, die diese Verbindungen über Ihr gesamtes KI-Ökosystem hinweg verwaltet.

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

Ein MCP-Gateway regelt den Zugriff auf diese Server. Es kümmert sich um Identität, Sichtbarkeit und die Durchsetzung von Richtlinien, bevor ein Tool aufgerufen wird. Ein MCP-Server führt Aktionen aus. Er verbindet sich mit einem spezifischen Tool oder einer Datenquelle und führt Operationen durch. Die TrueFoundry MCP-Registry ermöglicht es Ihnen, diese Server zur besseren administrativen Kontrolle in verwalteten Gruppen zu organisieren.

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

Ein MCP-Gateway ist für agentengesteuerte Workflows konzipiert. Es steuert die Entdeckung und Ausführung von MCP-Tools innerhalb des MCP-Protokolls und fügt Autorisierung sowie Beobachtbarkeit hinzu, die API-Gateways nicht bieten. Ein API-Gateway verwaltet den klassischen Anwendungsdatenverkehr. Es versteht HTTP-Routen, Authentifizierung und Ratenbegrenzungen. TrueFoundry schließt diese Lücke durch eine spezialisierte KI-Steuerungsebene, die den einzigartigen Kontext von LLM-zu-Tool-Interaktionen versteht.

Ist MCP besser als eine API?

Nein, MCP und APIs dienen unterschiedlichen Zwecken: APIs definieren Systemschnittstellen und REST-Endpunkte, während MCP diese Schnittstellen für KI-Modelle nutzbar und auffindbar macht. In den meisten Unternehmenssystemen müssen beide Ebenen zusammenarbeiten, um eine nahtlose Integration zu gewährleisten. Die TrueFoundry-Plattform unterstützt dieses Zusammenspiel durch standardisierte Connectorschnittstellen, die keine SDK-Änderungen an bestehenden Tools erfordern.

Wie hilft das TrueFoundry MCP-Gateway Unternehmen?

TrueFoundry bietet ein verwaltetes MCP-Gateway, das in Ihrer Cloud läuft. Es zentralisiert die Anmeldedatenverwaltung, erzwingt eine fein abgestufte Zugriffskontrolle und bietet Beobachtbarkeit über alle Agenten-Workflows hinweg.