Einblick in das Model Context Protocol (MCP): Architektur, Motivation und interner Gebrauch

Einführung

LLM-gestützte Anwendungen haben dazu geführt, dass Modelle dringend auf aktuelle, domänenspezifische Daten aus verschiedenen Quellen zugreifen müssen. MCP begegnet diesem Problem durch die Bereitstellung eines einheitlichen Protokolls, das standardisiert, wie Anwendungen Daten und Funktionen dynamisch für jede LLM-gestützte Anwendung bereitstellen können.

MCP im Überblick

Im Kern folgt MCP einer JSON-RPC-basierten Client-Server-Architektur, bei der eine Host-Anwendung eine Verbindung zu mehreren Servern herstellen kann:

• MCP-Hosts sind LLM-gestützte Anwendungen wie Claude Desktop, IDEs oder KI-Tools, die über MCP auf Daten zugreifen möchten.
• MCP-Kunden implementieren Sie das clientseitige MCP-Protokoll in verschiedenen Programmiersprachen. Sie sind die Brücke, über die sich die MCP-Hosts mit den MCP Servern verbinden.
• MCP-Server Stellen Sie bestimmte Daten und Funktionen über das MCP-Protokoll zur Verfügung. Es kann drei Haupttypen von Funktionen bereitstellen:
  • Ressourcen sind Daten, die die MCP-Server den Anwendungen zum Lesen zur Verfügung stellen. Sie können Dateiinhalte, API-Antworten usw. enthalten. Die Ressourcen werden von der Anwendung gesteuert; die Anwendungen entscheiden, wie sie in den Benutzerfluss aufgenommen werden.
  • Werkzeuge 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. Die Tools werden modellgesteuert. LLMs entscheiden, sie auf der Grundlage des gegebenen Kontextes aufzurufen.
  • Aufforderungen sind vorlagenfähige Benutzerinteraktionen oder Workflows, die vom MCP-Server bereitgestellt werden. Sie werden vom Benutzer gesteuert. LLM-Anwendungen entscheiden, wie sie verfügbar gemacht werden, sodass der Benutzer die entsprechende Aufforderung auswählen kann.

Verkehr

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

STUDIO

In diesem Setup ist der MCP-Client innerhalb des MCP-Hosts dafür verantwortlich, den MCP-Server auf demselben Computer hochzufahren. Die Kommunikation zwischen dem MCP-Client und dem MCP-Server erfolgt über STDIN und STDOUT. Hier kommuniziert ein MCP-Server nur mit einem einzigen MCP-Client.

Eine typische Konfiguration sieht so aus:

Beispiel: Du kannst den MCP Server von GitHub lokal mit Docker und einem Personal Access Token (PAT) ausführen

GitHub - github/github-mcp-server: GitHubs offizieller MCP-Server

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Autorisierung

In der Regel 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 weit verbreitete Methode.
2. MCP Server kann den OAuth2-Gerätefluss implementieren. Die offizielle MCP-Spezifikation beschreibt jedoch nichts.

Einschränkungen

• Das Gerät des Benutzers, auf dem die LLM-gestützte Anwendung ausgeführt wird, muss Docker oder Node/Python installieren. Dies ist zwar kein Problem für einen Entwickler, reduziert jedoch die Anzahl der Personen, die den MCP-Server verwenden können, drastisch.
• Da der MCP-Server vorhanden ist und auf dem Gerät des Benutzers ausgeführt wird, werden Upgrades umständlich und die schnelle Iteration wird beeinträchtigt.
• Web-Apps, die im Browser ausgeführt werden, können dies nicht verwenden.
• Ohne OAuth2-Gerätefluss müssen Benutzer ihre Token für jeden MCP-Server konfigurieren. Tokens werden oft nicht sicher auf dem Gerät gespeichert, und die Rotation ist umständlich.

Angesichts der Einschränkungen ist der STDIO-Transport nicht geeignet, um benutzerdefinierte MCP-Server zusätzlich zu den Diensten und der Datenquelle eines Unternehmens oder SaaS-Abonnements wie GitHub oder Slack zu erstellen. Es wird jedoch für Anwendungsfälle mit Entwicklertools in IDEs hilfreich sein.

Streambares HTTP

Streamable HTTP ermöglicht es MCP-Servern, mehrere MCP-Clients zu handhaben, die sich über das HTTP-Protokoll verbinden und kommunizieren. Dadurch werden viele Einschränkungen des STDIO-Transports beseitigt. Hauptsächlich:

1. Wir müssen den MCP-Server nicht mehr auf dem Gerät des Benutzers hosten; er kann überall gehostet werden.
2. Neue Funktionen, die dem MCP-Server hinzugefügt wurden, sind sofort für alle Benutzer verfügbar.
3. Web-Apps, die im Browser ausgeführt werden, können dies nutzen.

Autorisierung

Die Zulassung für diesen Transport wird aktiv entwickelt. In der neuesten Spezifikation, die am 26.03.2025 veröffentlicht wurde, wird Folgendes erwähnt:

1. Die MCP Auth-Implementierung muss OAuth 2.1 folgen.
2. Die MCP Auth-Implementierung sollte der dynamischen Kundenregistrierung folgen.

Ein typischer Auth-Flow würde ungefähr so aussehen:

Im obigen Ablauf fungiert der MCP-Server, der Tokens ausstellt, als Ressourcen- und Autorisierungsserver. Dies ist unpraktisch für MCP-Server für Slack, GitHub usw., bei denen der Anbieter seinen OAuth2-Autorisierungsserver bereits implementiert. Die intern gehosteten Dienste eines Unternehmens hinter von IdP bereitgestellten Autorisierungsservern leiden unter demselben Problem (z. B. bei der Installation von ArgoCD hinter einem von Okta bereitgestellten Autorisierungsserver).

Die Spezifikation erlaubt es, dies an einen Autorisierungsserver eines Drittanbieters zu delegieren, aber der MCP-Server muss sein Token ausstellen und die Beziehung zum Drittanbieter-Token verwalten. Dadurch werden alle Vorteile eines Autorisierungsservers eines Drittanbieters zunichte gemacht, da der MCP-Server die sichere Tokenverwaltung und die OAuth2-Routen implementieren muss.

Limitierung

• MCP-Server mit Authentifizierung benötigen eine Infrastruktur wie eine Datenbank, um den Lebenszyklus ihrer Token sicher zu speichern und zu verwalten. Jeder MCP-Server würde praktisch zu einem eigenen Autorisierungsserver werden, der überflüssig ist und innerhalb eines Unternehmens nicht gewartet werden kann. Die Community arbeitet aktiv daran, die Zulassungsspezifikation zu ändern, um dies zu verbessern.
• Anbieter wie Atlassian, Sentry, Slack, Github usw. unterstützen weder Dynamic Client Registration (DCR) noch unterstützen sie den öffentlichen OAuth2-Client. Der Aufbau von MCP-Servern auf der Grundlage dieser Anbieter wird für die Community schwieriger und für den Anbieter bedeutet mehr Arbeit. Atlassian hat kürzlich seinen eigenen MCP Server veröffentlicht, aber seine DCR-Implementierung ermöglicht nur localhost und einige wenige Umleitungs-URIs wie Claude usw.

Der Ansatz von TrueFoundry

Bei TrueFoundry möchten wir, dass unsere Kollegen aktiv in der Lage sind, ihre Atlassian-, Sentry-, Slack-, GitHub- usw. Konten als zusätzlichen Kontext mit LLM zu verbinden. Wir möchten auch sicherstellen, dass jeder Mitarbeiter über LLMs nur auf Ressourcen zugreifen oder Maßnahmen in Bezug auf Ressourcen ergreifen kann, für die er autorisiert ist. MCP + OAuth2 scheint der perfekte Weg zu sein, dies aufzudecken.

• Wir wollen uns darauf konzentrieren, qualitativ hochwertige MCP-Server zu schreiben, um die Daten und Funktionen effizienter für LLMs verfügbar zu machen. Wir wollen dies auf sichere Weise tun und dabei die innerhalb des Anbieters definierten RBAC-Grenzen einhalten.
• Wir möchten keine zusätzlichen Autorisierungsserver 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 Client sind nicht einmal eine Option.
• Die MCP-Autorisierungsspezifikation ändert sich immer noch aktiv und es wird daran gearbeitet. Wir können es kaum erwarten, dass es sich stabilisiert, bevor wir daran arbeiten.

Vor diesem Hintergrund haben wir uns die folgende Architektur ausgedacht.

Hier gibt es ein paar Komponenten.

MCP-Server

Wir haben HTTP-MCP-Server für Anbieter wie Slack, Sentry, Atlasian, Github usw. geschrieben, die dem Streamable HTTP-Transport folgen.

Diese MCP-Server stellen einen Proxy zwischen dem LLM und den HTTP-APIs des Anbieters her. Beachten Sie, dass dies keine 1:1 -Übersetzung ist. Die HTTP-APIs dieser Anbieter enthalten eine Menge unnötiger Inhalte, die das LLM leicht zum Scheitern bringen und das Kontextfenster füllen können. Beispielsweise weist ein List-Pod-Tool auf einem Kubernetes-MCP-Server viele doppelte Inhalte auf, da sich die Pod-Spezifikation über mehrere Pods hinweg wiederholt. Große Felder, wie Verwaltete Felder, wird für die meisten Benutzeranfragen nicht benötigt. Andere SaaS-Anbieter verfügen über verschachtelte übergeordnete Entitäten, Felder, die nicht funktionieren, wie Avatar-URL usw. Dort wollen wir die meiste Zeit unserer Entwicklungszeit verbringen. Schließlich benötigen wir ein System in MCP, das LLMs dabei helfen kann, das Datenmodell eines Systems zu erkennen und dann dynamisch nach bestimmten Ressourcenfeldern abzufragen.

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

Registrierung von MCP-Servern auf TrueFoundry

Nach der Bereitstellung der MCP-Server erstellen wir OAuth2-Apps oder vertrauliche Clients für jeden Anbieter. So sieht es für Slack aus.

Oben können Sie auch feststellen, dass der Authorizer-Redirect-URI konfiguriert ist. Es sieht normalerweise ungefähr so aus https://base-url/mcp-integrations/oauth2/callback.

Dann integrieren wir den MCP-Server zusammen mit der URL.

Wir können die Bereiche verwenden, um die gesamte Integration schreibgeschützt zu machen, wenn wir die Erlaubnis für bestimmte Ressourcentypen wünschen oder erteilen. Selbst wenn der MCP-Server über Tools zum „Schreiben“ von Ressourcen verfügt und der Benutzer über „Schreibrechte“ verfügt, können LLMs nicht dieselben Rechte erhalten.

Auswahl des MCP-Servers auf dem TrueFoundry Gateway und Autorisierung

Nach der Integration können wir den MCP-Server auf dem 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-Autorisierungscode-Ablauf. Am Ende des Vorgangs speichert TrueFoundry die Zugriffs- und Aktualisierungstoken sicher (sofern unterstützt und aktiviert).

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

Fangen Sie an, es zu benutzen!

Nach der Autorisierung können Sie den Kontext von den MCP-Servern direkt auf unserem Playground verwenden.

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

curl -X POST "https://base-url/api/llm/agent/responses" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-main/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "what are the issues in my app"
      }
    ],
    "tools": [
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:sentry",
        "tools": ["list_projects", "list_issues"]
      },
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:slack"
      }
    ]
  }'

‍

LLM Gateway implementiert die „agentische“ Schleife und sendet die ersten Nachrichten und die Toolbeschreibungen des MCP-Servers an das LLM. Der Benutzer kann auch die Tools filtern, die dem LLM zur Verfügung stehen. Basierend auf der Antwort des LLM kann das LLM Gateway mit den MCP-Servern kommunizieren und die Anmeldeinformationen der Anrufer weitergeben. Wir aktualisieren automatisch alle kurzlebigen Anmeldeinformationen. Die Updates werden mit SSE an das Frontend gesendet.

Fazit

Dieser MCP + OAuth2-Flow ermöglichte es unseren Kollegen, Daten von Anbietern wie Slack, GitHub, Sentry usw. sicher in ihren LLM-zentrierten Workflow zu integrieren.

Ein paar Anwendungsfälle,

• LLMs können über MCP auf Sentry zugreifen, um Fehlerdetails abzurufen und mit zugehörigen Codeänderungen von GitHub zu korrelieren, um das Debuggen zu beschleunigen.
• LLMs erstellen, aktualisieren und fragen Jira-Tickets über MCP ab und optimieren so die Arbeitsabläufe der Entwickler.
• LLMs können über MCP auf Slack-Konversationen zugreifen, um lange Diskussionsfäden zu analysieren und zusammenzufassen. So können Teams Entscheidungen und Aktionspunkte schnell nachvollziehen, ohne ganze Chat-Logs lesen zu müssen.