Einblick in das Model Context Protocol (MCP): Architektur, Motivation & interne Nutzung

Einführung

LLM-gestützte Anwendungen haben den dringenden Bedarf erzeugt, dass Modelle auf aktuelle, domänenspezifische Daten aus verschiedenen Quellen zugreifen müssen. MCP adressiert dies durch ein einheitliches Protokoll, das standardisiert, wie Anwendungen Daten und Funktionen dynamisch für jede beliebige LLM-gestützte Anwendung bereitstellen können.

MCP-Überblick

Im Kern folgt das Model Context Protocol (MCP) einer JSON-RPC-basierten Client-Server-Architektur, bei der sich eine Host-Anwendung mit mehreren Servern verbinden kann:

• MCP-Hosts sind LLM-gestützte Anwendungen wie Claude Desktop, IDEs oder AI-Tools, die über MCP auf Daten zugreifen möchten.
• MCP-Clients implementieren das clientseitige MCP-Protokoll in verschiedenen Programmiersprachen. Sie bilden die Brücke, über die die MCP-Hosts mit den MCP-Servern verknüpft werden.
• MCP-Server stellen spezifische Daten und Funktionen über das MCP-Protokoll bereit. Sie können drei Haupttypen von Funktionen bieten:
  • Ressourcen sind Daten, die die MCP-Server für die Anwendungen zum Lesen bereitstellen. Dies kann Dateiinhalte, API-Antworten usw. umfassen. Ressourcen werden von der Anwendung gesteuert; die Anwendungen entscheiden, wie sie in den Benutzerfluss eingebunden werden.
  • Tools sind Funktionen und Daten, die von den MCP-Servern bereitgestellt werden. Ein Kubernetes-MCP-Server kann beispielsweise Tools zum Abrufen aller Pods und zum Löschen eines Pods bereitstellen. Tools werden vom Modell gesteuert. LLMs entscheiden basierend auf dem gegebenen Kontext, diese aufzurufen.
  • Prompts sind vorlagenbasierte Benutzerinteraktionen oder Workflows, die vom MCP-Server bereitgestellt werden. Sie werden vom Benutzer gesteuert. LLM-Anwendungen entscheiden, wie sie diese anzeigen, damit der Benutzer den passenden Prompt auswählen kann.

Transport

Transporte definieren, wie ein MCP-Client und ein MCP-Server miteinander kommunizieren.

STDIO

In diesem Setup ist der MCP-Client innerhalb des MCP-Hosts dafür verantwortlich, den MCP-Server auf derselben Maschine zu starten. Die Kommunikation zwischen dem MCP-Client und dem MCP-Server erfolgt über STDIN und STDOUT. Hierbei kommuniziert ein MCP-Server nur mit einem einzelnen MCP-Client.

Eine typische Konfiguration sieht folgendermaßen aus:

Beispiel: Sie können den MCP-Server von GitHub lokal mit Docker und einem Personal Access Token (PAT) ausführen

GitHub - github/github-mcp-server: Der offizielle MCP-Server von GitHub  

Autorisierung

Typischerweise kann die Autorisierung auf zwei Arten erfolgen:

1. Benutzer können Umgebungsvariablen verwenden, um ihr Token an den MCP-Server-Prozess zu übergeben. Dies ist die am weitesten verbreitete Methode.
2. Der MCP-Server kann den OAuth2 Device Flow implementieren. Die offizielle MCP-Spezifikation macht hierzu jedoch keine Vorgaben.

Einschränkungen

• Auf dem Gerät des Benutzers, auf dem die LLM-gestützte Anwendung läuft, muss Docker oder Node/Python installiert sein. Obwohl dies für Entwickler kein Problem darstellt, reduziert es die Anzahl der Personen, die den MCP-Server nutzen können, drastisch.
• Da der MCP-Server auf dem Gerät des Benutzers vorhanden ist und läuft, werden Upgrades umständlich und schnelle Iterationen beeinträchtigt.
• Web-Apps, die im Browser laufen, können dies nicht nutzen.
• Ohne den OAuth2 Device Flow müssen Benutzer ihre Token für jeden MCP-Server einzeln konfigurieren. Token werden auf dem Gerät oft nicht sicher gespeichert, und eine Rotation ist umständlich.

Aufgrund dieser Einschränkungen ist der STDIO-Transport ungeeignet für die Erstellung benutzerdefinierter MCP-Server auf Basis von Unternehmensdiensten und -datenquellen oder SaaS-Abonnements wie GitHub oder Slack. Für Anwendungsfälle von Entwickler-Tools in IDEs ist er jedoch nützlich.

Streamable HTTP

Streamable HTTP ermöglicht es MCP-Servern, mehrere MCP-Clients zu verwalten, die sich über das HTTP-Protokoll verbinden und kommunizieren. Dies beseitigt viele Einschränkungen des STDIO-Transports. Vor allem:

1. Der MCP-Server muss nicht mehr auf dem Gerät des Benutzers gehostet werden; er kann überall gehostet werden.
2. Neue Funktionen, die dem MCP-Server hinzugefügt werden, stehen allen Benutzern sofort zur Verfügung.
3. Web-Apps, die im Browser laufen, können dies nutzen.

Autorisierung

Die Autorisierung in diesem Transport wird derzeit aktiv entwickelt. Die neueste Spezifikation vom 26.03.2025 besagt:

1. Die MCP-Auth-Implementierung muss OAuth 2.1 folgen.
2. Die MCP-Auth-Implementierung sollte der Dynamic Client Registration folgen.

Ein typischer Auth-Ablauf sieht ungefähr so aus:

Im obigen Ablauf fungiert der MCP-Server, der Token ausstellt, als Ressource und als Authorisation Server. Dies ist unpraktisch für MCP-Server für Slack, GitHub usw., bei denen der Anbieter bereits seinen eigenen OAuth2 Authorisation Server implementiert hat. Intern gehostete Dienste eines Unternehmens hinter IDP-bereitgestellten Authorisation Servern leiden unter demselben Problem (z. B. eine ArgoCD-Installation hinter einem von Okta bereitgestellten Authorisation Server).

Die Spezifikation erlaubt die Delegierung an einen Authorisation Server eines Drittanbieters, jedoch muss der MCP-Server sein eigenes Token ausstellen und die Beziehung zum Token des Drittanbieters verwalten. Dies zunichtemacht alle Vorteile eines Drittanbieter-Authorisation-Servers, da der MCP-Server ein sicheres Token-Management und die OAuth2-Routen selbst implementieren muss.

Einschränkung

• MCP-Server mit Authentifizierung erfordern Infrastruktur wie eine Datenbank zur sicheren Speicherung und Verwaltung des Lebenszyklus ihrer Token. Jeder MCP-Server würde effektiv zu seinem eigenen Authorisation Server werden, was redundant und innerhalb eines Unternehmens unmöglich zu warten ist. Die Community arbeitet aktiv an einer Überarbeitung der Autorisierungsspezifikation, um dies zu verbessern.
• Anbieter wie Atlassian, Sentry, Slack, GitHub usw. unterstützen weder Dynamic Client Registration (DCR) noch OAuth2 Public Clients. Das Erstellen von MCP-Servern auf Basis dieser Anbieter wird für die Community schwieriger und bedeutet mehr Aufwand für die Anbieter. Atlassian hat kürzlich seinen eigenen MCP-Server veröffentlicht, aber dessen DCR-Implementierung erlaubt nur localhost und einige wenige ausgewählte Redirect-URIs wie Claude etc.

Der Ansatz von TrueFoundry

Bei TrueFoundry möchten wir, dass unsere Kollegen ihre Atlassian-, Sentry-, Slack-, GitHub- und weiteren Konten aktiv als zusätzlichen Kontext mit dem LLM verbinden können. Wir möchten außerdem sicherstellen, dass jeder Mitarbeiter über LLMs nur auf Ressourcen zugreifen oder Aktionen ausführen kann, für die er autorisiert ist. MCP + OAuth2 scheint der perfekte Weg zu sein, dies bereitzustellen.

• Wir möchten uns auf das Schreiben qualitativ hochwertiger MCP-Server konzentrieren, um die Daten und Funktionen effizienter für LLMs bereitzustellen. Wir möchten dies sicher tun und uns an die im Provider definierten RBAC-Grenzen halten.
• Wir möchten keine zusätzlichen Authorisation Server für verschiedene MCP-Server verwalten. Wir möchten die OAuth2-Funktionen der Anbieter wiederverwenden.
• Anbieter unterstützen in der Regel nur vertrauliche OAuth2-Clients. DCR und Public Clients sind oft keine Option.
• Die MCP-Autorisierungsspezifikation ändert sich derzeit noch aktiv und befindet sich in der Entwicklung. Wir können nicht warten, bis sie sich stabilisiert hat, bevor wir daran arbeiten.

Vor diesem Hintergrund haben wir die folgende Architektur entwickelt.

Hier gibt es einige Komponenten.

MCP-Server

Wir haben HTTP-MCP-Server für Anbieter wie Slack, Sentry, Atlassian, GitHub usw. unter Verwendung des Streamable-HTTP-Transports geschrieben.

Diese MCP-Server fungieren als Proxy zwischen dem LLM und den HTTP-APIs des Anbieters. Beachten Sie, dass dies keine 1:1-Übersetzung ist. Die HTTP-APIs dieser Anbieter enthalten viele unnötige Inhalte, die das LLM leicht verwirren und das Kontextfenster füllen können. Beispielsweise enthält ein Tool zum Auflisten von Pods auf einem Kubernetes-MCP-Server viele doppelte Inhalte, da sich die Pod-Spezifikation über mehrere Pods hinweg wiederholt. Große Felder wie managedFields werden für die Anfragen der meisten Benutzer nicht benötigt. Andere SaaS-Anbieter haben verschachtelte übergeordnete Entitäten, nicht-funktionale Felder wie die Avatar-URL usw. Hier möchten wir den Großteil unserer Entwicklungszeit investieren. Letztendlich benötigen wir ein System in MCP, das LLMs dabei helfen kann, das Datenmodell eines Systems zu ermitteln und dann dynamisch bestimmte Felder von Ressourcen abzufragen.

Diese MCP-Server erwarten einen HTTP-Autorisierungs-Header und leiten diesen direkt an die HTTP-API des Anbieters weiter.

Registrierung von MCP-Servern auf TrueFoundry

Nach dem Deployment der MCP-Server erstellen wir OAuth2-Apps oder vertrauliche Clients für jeden Anbieter. So sieht das für Slack aus:

Oben können Sie auch sehen, dass die Redirect-URI des Authorizers konfiguriert ist. Sie sieht gewöhnlich etwa so aus: https://base-url/mcp-integrations/oauth2/callback.

Anschließend integrieren wir den MCP-Server zusammen mit der URL.

Wir können die Scopes nutzen, um diese gesamte Integration bei Bedarf schreibgeschützt zu machen oder Berechtigungen für bestimmte Ressourcentypen zu erteilen. Selbst wenn der MCP-Server über Tools zum „Schreiben“ von Ressourcen verfügt und der Benutzer Schreibrechte hat, erhalten LLMs nicht dieselben Privilegien.

Auswahl des MCP-Servers auf dem TrueFoundry Gateway und Autorisierung

Nach der Integration können wir den MCP-Server in der Gateway Playground auswählen.

Wenn der Benutzer nicht autorisiert ist, verwenden wir die OAuth2-Client-Informationen in der Integration und führen den Benutzer durch den OAuth2 Authorization Code Flow. Am Ende des Prozesses speichert TrueFoundry die Access und Refresh Tokens sicher (sofern unterstützt und aktiviert).

Wir können unsere Anmeldeinformationen aus TrueFoundry entfernen oder sie sogar direkt beim Anbieter widerrufen.

Starten Sie mit der Nutzung!

Nach der Autorisierung können Sie den Kontext von den MCP-Servern direkt in unserer Playground nutzen.

Beachten Sie, dass wir keine OAuth2-Anmeldeinformationen an das Frontend übergeben. Das Frontend ruft eine API auf:

‍

Das LLM Gateway implementiert die „agentische“ Schleife und sendet die anfänglichen Nachrichten und die Tool-Beschreibungen des MCP-Servers an das LLM. Der Benutzer kann die für das LLM bereitgestellten Tools auch filtern. Basierend auf der Antwort des LLM kann das LLM Gateway mit den MCP-Servern kommunizieren und die Anmeldeinformationen des Anrufers weitergeben. Wir aktualisieren kurzlebige Anmeldeinformationen automatisch. Die Aktualisierungen werden mittels SSE an das Frontend gesendet.

Fazit

Dieser Ablauf aus MCP + OAuth2 hat es unseren Kollegen ermöglicht, Daten von Anbietern wie Slack, GitHub, Sentry etc. sicher in ihren LLM-zentrierten Workflow einzubinden.

Einige Anwendungsfälle:

• LLMs können über MCP auf Sentry zugreifen, um Fehlerdetails abzurufen und sie mit zugehörigen Codeänderungen von GitHub für ein schnelleres Debugging zu korrelieren.
• LLMs erstellen, aktualisieren und fragen Jira-Tickets über MCP ab, was die Workflows von Entwicklern optimiert.
• LLMs können über MCP auf Slack-Unterhaltungen zugreifen, um lange Diskussionsthreads zu analysieren und zusammenzufassen. Das hilft Teams, Entscheidungen und Aufgaben schnell zu verstehen, ohne die gesamten Chat-Protokolle lesen zu müssen.