Was ist das Model Context Protocol (MCP) und wie funktioniert es?

TL;DR: Das MCP (Model Context Protocol) ist ein offener Standard von Anthropic, der es KI-Agenten ermöglicht, eine Verbindung zu externen Tools, APIs und Datenquellen herzustellen – ohne benutzerdefinierte Integrationen. Es nutzt eine Host-Client-Server-Architektur über JSON-RPC, damit Modelle Tools zur Laufzeit entdecken und aufrufen können. Drei Primitiven treiben es an: Tools (Aktionen), Resources (Daten) und Prompts (Vorlagen).

Was wäre, wenn Ihr KI-System tatsächlich Dinge erledigen könnte: Daten aus einem CRM abrufen, ein Dashboard aktualisieren oder eine E-Mail senden, ohne dass ein Team von Ingenieuren alles verkabeln muss? Genau hier kommt das Model Context Protocol, kurz MCP, ins Spiel. Es ist ein offener Standard, der KI-Agenten hilft, sich mit deutlich weniger Aufwand sicher mit Tools, Systemen und Datenquellen zu verbinden.

Da KI immer leistungsfähiger wird, liegt die eigentliche Herausforderung nicht mehr im Modell selbst, sondern darin, ihm Zugriff auf den richtigen Kontext und die richtigen Aktionen zu gewähren. MCP löst dies mit einem strukturierten Protokoll, das jedes Tool und jeder Agent sprechen kann. Wenn Sie sehen möchten, wie sich dies auf der Infrastrukturebene auswirkt, baut Was ist ein MCP-Gateway direkt auf diesen Grundlagen auf. Und wenn Sie Optionen für Ihren Stack vergleichen, stellt der Leitfaden für die besten MCP-Gateways führende Implementierungen Seite an Seite vor.

Wie löst MCP also das Problem des Tool-Zugriffs? Wie sieht es unter der Haube aus? Und warum setzen Unternehmen wie Anthropic und Microsoft darauf? Schauen wir es uns genauer an.

Was ist das Model Context Protocol?

MCP, kurz für Model Context Protocol, ist ein offener Standard, der entwickelt wurde, um KI-Agenten die Interaktion mit externen Tools, Daten und Diensten auf strukturierte, sichere Weise zu ermöglichen. Stellen Sie es sich wie einen universellen Stecker vor, mit dem sich Ihr KI-Modell in reale Systeme „einstecken“ lässt – genauso wie ein USB-Anschluss Geräte mit Ihrem Computer verbindet. Anstatt sich auf fest codierte APIs oder proprietäre Integrationen zu verlassen, bietet MCP eine gemeinsame Sprache, über die Tools und Agenten miteinander kommunizieren können. Dies ist der wesentliche Unterschied bei MCP vs. API: Traditionelle APIs stellen vordefinierte Endpunkte bereit, während MCP ein strukturiertes Protokoll hinzufügt, das es KI-Systemen ermöglicht, Tools, Ressourcen und Prompts zur Laufzeit dynamisch zu entdecken.

Das Protokoll wurde von Anthropic im Rahmen ihrer umfassenderen Vision eingeführt, KI-Agenten fähiger, sicherer und autonomer zu machen. Es verwendet eine einfache, aber leistungsstarke Architektur: Clients (wie ein KI-Modell) senden Anfragen an Server (die Tools oder Datenquellen kapseln) und erhalten strukturierte Antworten, die als Kontext in das Modell zurückgeführt werden können.

Einer der größten Vorteile von MCP ist seine Modularität. Unabhängig davon, ob es sich bei Ihrem Tool um eine Datenbank, eine interne Anwendung, ein SaaS-Produkt oder sogar ein Dateisystem handelt, können Sie es als MCP-Server bereitstellen. Das bedeutet, dass Ihre Agenten nicht jedes Mal neu trainiert oder integriert werden müssen, wenn ein neues System hinzugefügt wird – sie folgen einfach dem Protokoll.

MCP ist zudem sprachenunabhängig und transportflexibel. Es unterstützt mehrere SDKs (Python, TypeScript, Java, C#) und kann über verschiedene Kommunikationsschichten wie HTTP und WebSockets arbeiten. Dies erleichtert den plattformübergreifenden Einsatz, unabhängig davon, ob Sie KI-Workflows in der Cloud, am Edge oder in Enterprise-IT-Umgebungen ausführen.

Im Kern verlagert MCP die Diskussion rund um KI von „Was kann das Modell sagen?“ zu „Was kann das Modell tun?“. Und genau das ist der Sprung, den Agenten machen müssen, um sich von passiven Assistenten zu echten entscheidungstragenden Partnern zu entwickeln.

Architektur von MCP

Das Model Context Protocol wurde entwickelt, um KI-Agenten eine sichere Interaktion mit externen Tools und Datenquellen über eine standardisierte Schnittstelle zu ermöglichen. Seine Architektur trennt die Verantwortlichkeiten klar über drei Schichten: den Host, den Client und den Server. Jede Schicht spielt eine spezifische Rolle bei der Verwaltung des Zugriffs, der Gewährleistung der Isolation und dem Austausch von Kontext.

Im Mittelpunkt steht ein strukturiertes, zustandsbehaftetes Kommunikationsprotokoll auf Basis von JSON-RPC 2.0, das die Request-Response-Abläufe zwischen Agenten und Tool-Schnittstellen steuert. Das Ergebnis ist ein modulares System, das es Entwicklern ermöglicht, einmal zu bauen und ohne erneute Implementierung über Agenten, Tools und Domänen hinweg zu skalieren. Die Architektur unterstützt sowohl lokale als auch verteilte Deployments.

Host

Der Host ist die primäre Ausführungsumgebung für den KI-Agenten oder das Modell. Er koordiniert alles von den Sicherheitsrichtlinien und der Sampling-Strategie bis hin zu den Tool-Aufruf-Workflows. Hosts sind für die Erstellung und Verwaltung von Client-Instanzen verantwortlich und spielen eine zentrale Rolle bei der Interaktion einer KI-Anwendung mit dem MCP-Ökosystem.

Hosts setzen Zugriffskontrollen, Benutzereinwilligungen und Sitzungsgrenzen über alle Tools hinweg durch. Sie übernehmen die Kontextaggregation und bestimmen, wie Daten von mehreren Clients zusammengeführt und an das Modell übergeben werden.

In einem System wie Claude Desktop verwaltet der Host beispielsweise mehrere Client-Verbindungen, von denen jede mit einem anderen externen Dienst interagiert, während gleichzeitig ein einheitlicher Kontext für die Argumentationsschleife des Modells aufrechterhalten wird.

Client

Jeder Client dient als dedizierte Kommunikationsbrücke zwischen dem Host und einem einzelnen MCP-Server. Er handelt Funktionen mit dem Server aus, verwaltet die RPC-Sitzung und leitet Daten in beide Richtungen weiter. Clients sind so konzipiert, dass sie isoliert und über den Rahmen einer einzelnen Sitzung hinaus zustandslos sind.

Ein Client verbindet sich mit genau einem Server, was eine strikte Isolation wahrt und Risiken minimiert. Clients verwalten die Ermittlung (Tools, Ressourcen, Prompts) und setzen die Nachrichtenvalidierung sowie Typsicherheit durch.

Clients fungieren als Abstraktionsschicht, die es dem KI-Modell ermöglicht, Tools aufzurufen oder Daten abzurufen, ohne direkt mit den Implementierungsdetails des Systems gekoppelt zu sein.

Server

Ein MCP-Server ist eine Kapselung (Wrapper) um ein externes Tool, eine API oder ein System. Er stellt Funktionalitäten und Daten in einem standardisierten Format bereit und macht sie so für jeden MCP-kompatiblen Client zugänglich. Server arbeiten unabhängig und sind dafür verantwortlich, ihren eigenen Funktionsumfang zu definieren.

Server stellen drei Kernprimitiven bereit: Tools (Aktionen), Resources (Daten) und Prompts (vorlagenbasierte Abläufe). Sie beachten Zugriffsbeschränkungen und können je nach Systemarchitektur lokal oder über das Netzwerk bereitgestellt werden.

Beispielsweise kann ein Server eine Postgres-Datenbank als abfragbare Ressource bereitstellen oder die API von GitHub als eine Reihe aufrufbarer Tools kapseln. Einmal erstellt, kann derselbe Server mehrere Client-Typen auf verschiedenen Hosts bedienen.

Hinweis: Das Host-Client-Server-Design von MCP setzt eine strikte Trennung der Verantwortlichkeiten durch. Der Host steuert den Zugriff und den Kontext, jeder Client verwaltet eine isolierte Sitzung und Server stellen Tool-Funktionen über ein Standardprotokoll bereit. Diese Struktur ist entscheidend für den Aufbau sicherer, modularer und skalierbarer KI-Agenten-Systeme über unterschiedliche Toolchains hinweg.

Kernkomponenten von MCP

MCP-Interaktionen werden von vier Schlüsselprimitiven angetrieben: Tools, Resources, Prompts und der Session Layer. Diese Komponenten abstrahieren komplexe Low-Level-Details und bieten eine saubere Schnittstelle für Modelle, um auf modulare und vorhersagbare Weise zu schlussfolgern, zu handeln und mit realen Systemen zu interagieren.

Tools

Tools sind ausführbare Funktionen, die vom Server bereitgestellt werden und vom Modell über den Client aufgerufen werden können. Jedes Tool ist mit Eingabeparametern, einem Ausgabeschema und einer Beschreibung seines Zwecks definiert. Diese Metadaten werden vom Modell verwendet, um zu bestimmen, wann und wie ein Tool eingesetzt wird. Beispiele hierfür sind das Erstellen von Support-Tickets, das Senden von Slack-Nachrichten oder das Starten von Workflows. Tools können je nach Backend-Implementierung synchron oder asynchron sein. Das Modell entscheidet über den Zeitpunkt des Tool-Aufrufs auf der Grundlage des aktuellen Kontexts und der Aufgabenstellung.

Resources

Resources (Ressourcen) sind schreibgeschützte Daten, die Server bereitstellen, um dem Modell Kontext zu liefern. Dabei kann es sich um Datenbankeinträge, Dokumente, Protokolleinträge oder Suchergebnisse handeln. Clients fordern Ressourcen an, wenn das Modell Daten nachschlagen oder abrufen muss, bevor es eine Aktion ausführt. Server definieren, was verfügbar ist, und der Client kümmert sich um die Formatierung für die Aufnahme in den Prompt des Modells. Ressourcen sind entscheidend, um Agentenantworten auf aktuellen und relevanten Informationen zu begründen.

Prompts

Prompts sind vordefinierte Vorlagen oder Interaktionsabläufe, die vom Server registriert werden. Sie dienen als strukturierte Gerüste, die das Verhalten des Modells in spezifischen Kontexten steuern können. Ein Prompt könnte beispielsweise das Layout für einen Fehlerbericht, eine Eskalations-E-Mail oder einen Onboarding-Leitfaden definieren. Prompts können vom Benutzer ausgelöst oder programmatisch aufgerufen werden. Ihre Rolle besteht darin, Konsistenz zu gewährleisten, Halluzinationen zu reduzieren und die strukturierte Generierung in kritischen Workflows zu beschleunigen.

Session Layer (JSON-RPC)

Die gesamte Kommunikation zwischen Clients und Servern erfolgt über JSON-RPC 2.0. Dieses Protokoll unterstützt zustandsbehaftetes, bidirektionales Messaging und ist transportflexibel. Es funktioniert über STDIO, HTTP/SSE oder WebSockets. Der Session Layer ermöglicht Request-Response-Aufrufe, Ereignisbenachrichtigungen, Funktionsregistrierungen und lang laufende Operationen. Durch die Einhaltung von JSON-RPC gewährleistet MCP eine starke Typisierung, vorhersagbare Kommunikationsmuster und Kompatibilität über Sprachen und Plattformen hinweg. Dieses Sitzungsmodell ist es, was die dynamische Tool-Ermittlung und Interaktion zur Laufzeit erst möglich macht.

Hinweis: Tools, Resources, Prompts und der Session Layer bilden das Fundament jeder MCP-Interaktion. Sie ermöglichen es Modellen, unter Verwendung strukturierter, vorhersagbarer Primitiven zu schlussfolgern, zu handeln und Kontext abzurufen – was eine Echtzeitintegration mit externen Systemen erlaubt, ohne Sicherheit oder Flexibilität zu opfern.

Sicherheitsüberlegungen bei MCP

Die gesamte Kommunikation zwischen Clients und Servern erfolgt über JSON-RPC 2.0. Dieses Protokoll unterstützt zustandsbehaftetes, bidirektionales Messaging und ist transportflexibel; es funktioniert über STDIO, HTTP/SSE oder WebSockets. Der Session Layer ermöglicht Request-Response-Aufrufe, Ereignisbenachrichtigungen, Funktionsregistrierungen und lang laufende Operationen. Durch die Einhaltung von JSON-RPC gewährleistet MCP eine starke Typisierung, vorhersagbare Kommunikationsmuster und Kompatibilität über Sprachen und Plattformen hinweg. Dieses Sitzungsmodell ist es, was die dynamische Tool-Ermittlung und Interaktion zur Laufzeit erst möglich macht.

Hinweis: Tools, Resources, Prompts und der Session Layer bilden das Fundament jeder MCP-Interaktion. Sie ermöglichen es Modellen, unter Verwendung strukturierter, vorhersagbarer Primitiven zu schlussfolgern, zu handeln und Kontext abzurufen – was eine Echtzeitintegration mit externen Systemen erlaubt, ohne Sicherheit oder Flexibilität zu opfern.

Wie funktioniert MCP? 

MCP arbeitet über einen strukturierten Fünf-Schritte-Ablauf, der es Sprachmodellen ermöglicht, Tools und Datenquellen in Echtzeit zu entdecken, aufzurufen und mit ihnen zu interagieren. So funktioniert das Protokoll unter der Haube:

Schritt 1: Host initialisiert Clients

Die Host-Anwendung startet den Prozess, indem sie einen oder mehrere MCP-Clients startet, die jeweils so konfiguriert sind, dass sie sich mit einem bestimmten MCP-Server verbinden. Der Host ist auch dafür verantwortlich, die Benutzerautorisierung zu verwalten, Zugriffskontrollrichtlinien durchzusetzen und den Kontext über mehrere Tool-Interaktionen hinweg aufrechtzuerhalten.

Schritt 2: Clients entdecken Server-Funktionen

Jeder Client leitet einen Handshake mit seinem zugewiesenen Server ein. Während dieses Austauschs kündigt der Server seine unterstützten Tools, Resources und Prompts an – komplett mit Beschreibungen, Eingabeparametern und Rückgabetypen. Der Client verpackt diese Metadaten dann in den Kontext des Modells, damit das Modell weiß, was es verwenden kann.

Schritt 3: Modell trifft Entscheidungen

Mit den nun im Prompt eingebetteten Funktionsdaten zieht das Modell Rückschlüsse auf die verfügbaren Tools und die aktuelle Benutzereingabe. Wenn die Aufgabe eine Aktion oder das Abrufen von Informationen erfordert, entscheidet das Modell, welches Tool oder welche Resource aufgerufen werden soll, formuliert die entsprechenden Parameter und sendet die Anfrage an den Client.

Schritt 4: Client und Server tauschen Daten aus

Der Client leitet die Anfrage des Modells über JSON-RPC an den Server weiter. Der Server führt die Funktion aus oder ruft die Daten ab und gibt dann eine strukturierte Antwort zurück. Der Client liefert das Ergebnis an das Modell zurück, das es verwendet, um die Verarbeitung fortzusetzen oder weitere Entscheidungen zu treffen.

Schritt 5: Host verwaltet Feedback und Sitzungsablauf

Die Host-Anwendung überwacht den gesamten Ablauf, verwaltet den laufenden Sitzungszustand, protokolliert die Tool-Nutzung, setzt Rate Limits durch und stellt sicher, dass der Agent in seinem vorgesehenen Rahmen bleibt. Dieser Schritt gewährleistet Sicherheit, Nachvollziehbarkeit und Beobachtbarkeit KI-gesteuerter Aktionen.

Wie bearbeitet ein KI-Agent ein Support-Ticket mit MCP?

Dieses Diagramm zeigt, wie ein KI-Agent MCP verwendet, um Tools zu entdecken, Aktionen auszuführen und Tickets über mehrere Server hinweg in Echtzeit zu bearbeiten. Es veranschaulicht den gesamten Durchgängigkeitsprozess von der Benutzereingabe bis zur Systemantwort.

Stellen Sie sich einen KI-Support-Agenten vor, der in eine Helpdesk-Anwendung eingebettet ist. Wenn die Host-Anwendung startet, initialisiert sie zwei MCP-Clients: einen, der mit einem Zendesk-MCP-Server verbunden ist, und einen anderen, der mit einem internen Eskalationssystem verknüpft ist. Jeder Client führt einen Funktions-Handshake mit seinem jeweiligen Server durch. Der Zendesk-Server bietet Tools wie getTicketById und updateTicketStatus an, während der Eskalationsserver escalateTicket bereitstellt.

Diese Metadaten werden in den Kontext des Modells übergeben. Wenn ein Benutzer die Anweisung eingibt: „Eskaliere Ticket #1289, wenn es als dringend markiert ist“, interpretiert das Modell die Anfrage und stellt fest, dass es zuerst das Ticket abrufen muss. Es ruft getTicketById("1289") über den Zendesk-Client auf. Der Server antwortet mit den Ticketdetails, die zeigen, dass die Priorität „dringend“ ist. Daraufhin entscheidet das Modell, das Problem zu eskalieren, und ruft escalateTicket("1289") über den zweiten Client auf.

Beide Aufrufe werden über JSON-RPC ausgeführt. Die Clients leiten die Anfragen an ihre jeweiligen Server weiter, die die Funktionen verarbeiten und strukturierte Antworten zurückgeben. Diese Antworten, Ticket-Metadaten und die Eskalationsbestätigung werden an das Modell zurückgeleitet und in seinen Kontext integriert. Der Host schließt die Schleife ab, indem er die Interaktionen protokolliert, Zugriffsrichtlinien validiert und die Benutzeroberfläche mit der Ausgabe aktualisiert: „Ticket #1289 erfolgreich eskaliert.“

MCP vs. RAG: Warum das Verständnis des Unterschieds wichtig ist

Vor der Integration von KI-Systemen ist es wichtig zu verstehen, wie MCP (Model Context Protocol) und RAG (Retrieval-Augmented Generation) unterschiedliche Zwecke erfüllen. Während beide die LLM-Funktionalität erweitern, konzentriert sich MCP auf die Verbindung von Modellen mit Tools und APIs, wohingegen RAG Modellantworten mit externem Wissen anreichert.

Lesen Sie auch: MCP vs. RAG

Warum brauchen wir MCP?

Da KI-Agenten immer leistungsfähiger werden, liegt ihre größte Einschränkung nicht im logischen Denken – sondern im Zugriff. Die meisten Sprachmodelle arbeiten isoliert, ohne eine strukturierte Möglichkeit, mit externen Tools oder Datenquellen zu interagieren. Entwickler verbringen Zeit damit, API-Aufrufe fest zu codieren, anfällige Wrapper zu bauen oder einmalige Integrationen zu verwalten, die sich schlecht skalieren lassen. Dies verlangsamt nicht nur die Entwicklung, sondern bringt auch Sicherheits- und Wartbarkeitsprobleme mit sich.

MCP löst dieses Problem, indem es standardisiert, wie KI-Agenten Tools entdecken, bewerten und aufrufen. Es definiert ein sauberes Protokoll, das es Systemen ermöglicht, ihre Funktionen – wie APIs, Datenbanken oder Dateisysteme – auf eine strukturierte, modellfreundliche Weise bereitzustellen. Agenten wiederum können dynamisch lernen, welche Aktionen verfügbar sind, entscheiden, wann sie diese verwenden, und sie mithilfe von JSON-RPC sicher auslösen.

Praxisnaher Anwendungsfall

Stellen Sie sich einen KI-Assistenten vor, der in eine HR-Plattform eines Unternehmens eingebettet ist. Über MCP kann sich der Assistent mit einem Abrechnungsserver, einer internen Wissensdatenbank und einem Mitarbeiterverzeichnis verbinden – jeweils als MCP-Server. Wenn ein Manager eingibt: „Gewähre Rahul fünf Tage Urlaub und benachrichtige die HR“, ruft das Modell dynamisch die passenden Tools auf, die von diesen Servern bereitgestellt werden: eines zum Aktualisieren des Urlaubsstatus, ein anderes zum Senden einer Slack-Nachricht an die HR und ein drittes zum Protokollieren der Anfrage im internen System – alles in Echtzeit und ohne benutzerdefinierten Code im Modell.

Diese Art der Orchestrierung manuell zu bauen, wäre anfällig und teuer. Mit MCP wird sie modular, wiederholbar und sicher über MCP-Automatisierungsplattformen hinweg. Mit MCP wird sie modular, wiederholbar und sicher. Wenn Unternehmen mehr Tools und Dienste bereitstellen, stellt MCP sicher, dass KI-Agenten sicher und intelligent mit ihnen interagieren können – ohne dass für jede Änderung neue Integrationen erforderlich sind.

Warum ist MCP mehr als nur Function Calling?

Function Calling hat es Sprachmodellen ermöglicht, auf strukturierte Weise mit Tools zu interagieren. Sie definieren ein Tool, seine Parameter und seinen Zweck, und das Modell kann es aufrufen, indem es ein JSON-Objekt zurückgibt. Dies funktioniert gut für einfache Anwendungsfälle, insbesondere wenn die Anzahl der Tools gering und statisch ist. Function Calling hat jedoch kritische Einschränkungen: Es setzt voraus, dass Sie alle Tools im Voraus kennen, dass jedes Modell eng an sie gekoppelt ist und dass die Infrastruktur um sie herum entweder fest codiert oder anfällig ist.

MCP schließt diese Lücken durch die Einführung eines vollständigen Protokolls – nicht nur eines Formats. Für Teams, die MCP vs. A2A evaluieren, ist dieser Unterschied von Bedeutung, da MCP die Interaktion zwischen Modell und Tool standardisiert, während sich A2A auf die Kommunikation zwischen autonomen Agenten konzentriert. Es formalisiert die Interaktion zwischen KI-Agenten und externen Systemen mithilfe einer Host-Client-Server-Architektur und strukturierter Kommunikation über JSON-RPC. Anstatt Tool-Definitionen direkt im Prompt des Modells einzubetten, ermöglicht MCP den Modellen, zur Laufzeit dynamisch zu entdecken, welche Tools verfügbar sind, sie sicher aufzurufen und strukturierte Antworten zu erhalten – alles über eine einheitliche Schnittstelle.

Praxisbeispiel

Stellen Sie sich einen KI-Assistenten vor, der in ein Dashboard für den Einzelhandel eingebettet ist. Beim Function Calling müsste das Modell manuell mit Zugriff auf Tools wie getInventory, updatePrice und notifyWarehouse konfiguriert werden. Jedes Tool muss fest in den System-Prompt des Agenten verdrahtet sein. Mit MCP können Sie sich jedoch mit verschiedenen Servern verbinden – einem für den Bestand, einem für die Preisgestaltung, einem für die Logistik – und der Agent entdeckt alle bereitgestellten Tools automatisch. Kein Festcodieren, kein erneutes Deployment.

Warum das wichtig ist

• Trennungsprinzip (Separation of Concerns): Entwickler können Server einmal bauen und über Modelle und Teams hinweg teilen
  
• Dynamische Orchestrierung: Modelle können verfügbare Funktionen bewerten und Workflows spontan anpassen
  

Function Calling war ein notwendiger erster Schritt. MCP baut auf diesem Fundament auf und bietet die Infrastruktur, das Protokoll und die Flexibilität, die für den Aufbau robuster, produktionsreifer Agentensysteme erforderlich sind.

Wie implementiert das TrueFoundry Gateway den MCP-Server? 

Zentrale MCP-Server-Registry

TrueFoundrys MCP Gateway bietet ein einzelnes Portal zur Ermittlung und Registrierung all Ihrer MCP Server – ob intern, on-premises, hybrid oder von Drittanbietern – unter organisierten „MCP Server Groups“, die Umgebungen (z. B. dev gegenüber prod) isolieren und RBAC-gesteuerte Freigabe-Workflows für Governance und Transparenz erzwingen. Out-of-the-box enthält das Gateway vorgefertigte Konnektoren für Enterprise-Tools wie Slack, Confluence, Datadog, Sentry und GitHub, was eine Zero-Code-Integration in LLM-Agent-Workflows ermöglicht. Für individuelle Anforderungen können Sie jede interne oder proprietäre API in wenigen Minuten registrieren, um sie für LLM-gestützte Agenten sofort auffindbar und nutzbar zu machen, ohne Ihren SDK anzupassen.

Sichere Authentifizierung und SDK-Integration

Das Gateway unterstützt mehrere Authentifizierungsschemata, darunter keine Authentifizierung, Header-basierte Token und OAuth2-Client-Credentials, mit föderiertem SSO über Identity Provider wie Okta und Azure AD. OAuth2-Anmeldedaten werden sicher im integrierten Secrets Manager von TrueFoundry gespeichert und bei Proxy-Anfragen automatisch injiziert, was das Anmeldedaten-Management zentralisiert und Risiken reduziert.

Entwickler können programmgesteuert mit registrierten MCP Servern interagieren, indem sie die offiziellen Python- und TypeScript-SDKs verwenden, die MCP-Autorisierung durchgehend verwalten, oder über den AI Gateway Playground – eine intuitive Benutzeroberfläche, in der Sie MCP Server hinzufügen, Tools auswählen und Prompts in natürlicher Sprache ausführen, die Remote-Dienste in Echtzeit aufrufen. Sowohl der Playground als auch das SDK bieten „API Code Snippet“-Schaltflächen, um einsatzbereiten Integrations-Boilerplate-Code in Ihrer bevorzugten Sprache zu generieren.

Observability und Load Balancing

Das AI Gateway von TrueFoundry bietet integrierte Observability und Load Balancing auf Enterprise-Niveau. Anfragen werden basierend auf Gewichtung oder Latenz an die gesündesten Endpunkte geroutet, während alle MCP-Aufrufe trace-geloggt und in Governance-Dashboards auditiert werden, um Compliance und Performance-Monitoring zu gewährleisten. In einem aktuellen Blog-Beitrag beschreibt das Team, wie das Gateway als zentrale Control Plane für moderne generative AI-Infrastruktur agiert und LLMs, MCP Server sowie Agent-to-Agent-Protokolle unter einer Oberfläche für geringe Latenz, hohe Zuverlässigkeit und nahtlose Skalierbarkeit vereint. Dieser Ansatz ermöglicht die Orchestrierung in natürlicher Sprache über Unternehmenssysteme hinweg und erlaubt eine Durchgängige Automatisierung – wie das Erstellen von Jira-Issues aus Slack-Alerts –, ohne Integrationscode zu schreiben.