Entwicklung von MCP-Servern: Agentische KI als „Customer Zero“ Ihrer APIs

Die Engineering-Teams von Red Hat Trusted Profile Analyzer (TPA) und Trustify haben sich dafür entschieden, mit Model Context Protocol (MCP) zu experimentieren. In diesem Artikel berichten wir über die Herausforderungen, mit denen wir konfrontiert waren, und hoffen, dass unsere Erfahrungen anderen bei ähnlichen Projekten helfen können.

Red Hat Trusted Profile Analyzer (TPA) ist ein Produkt von Red Hat für das SBOM-Management (Software Bill of Materials). Es speichert SBOMs und korreliert die Pakete innerhalb der SBOMs mit bekannten öffentlichen Schwachstellen. Es basiert auf dem Upstream-Projekt Trustify.

Die Architektur ist im Allgemeinen eher „traditionell“:

• Das Frontend wird mit Komponenten von React und PatternFly (trustify-ui) entwickelt.
• Das mit Rust entwickelte Backend stellt eine Verbindung zu einer Datenbankinstanz her und speichert die SBOMs in S3-kompatiblem Storage.

Dies waren im Wesentlichen unsere Arbeitsschritte:

1. Entwurf der MCP-Serverintegration mit TPA/Trustify
2. Definition der Tool-Beschreibungen des MCP-Servers
3. Entwurf der Tool-Parameter des MCP-Servers

Im Folgenden geht es um die Aspekte, die in den einzelnen Phasen zu berücksichtigen sind. Das Endergebnis ist der MCP-Server, der auf GitHub verfügbar ist. 

Entwurf der MCP-Serverintegration mit TPA/Trustify

Noch bevor wir uns mit der Definition der Integration zwischen dem MCP-Server und Trustify befassten, standen wir vor einem typischen Dilemma im Leben eines Software Engineers: Welche Library soll ich für dieses Projekt verwenden? Soll ich ganz von vorne anfangen und alles selbst entwickeln?

Als überzeugte Nutzende von Open Source nahmen wir die aktuellen Rust-Libraries (Trustify wird hauptsächlich in Rust entwickelt, daher war eine Rust-Library unsere bevorzugte Option) für die Implementierung eines MCP-Servers unter die Lupe.

Wir fanden schnell heraus, dass MCP einige offizielle Libraries in ihrer GitHub-Organisation bereitstellt, darunter auch eine, die mit Rust entwickelt wurde.

Diese Library enthält nicht nur den Code, der für die Entwicklung eines MCP-Servers erforderlich ist, sondern auch eine Vielzahl von Beispielen für den Einstieg.

Schnell wurde klar, dass wir neben den Library-spezifischen Details für die Ausführung des MCP-Servers und die Definition der verfügbaren Tools mit ihren Parametern auch entscheiden mussten, wie der MCP-Server auf die „Backend“-Daten zugreifen sollte.

Wir haben dafür 2 verschiedene Optionen geprüft. Der MCP-Server kann die Daten folgendermaßen abrufen:

• Über eine direkte Verbindung zur Datenbank (DB), in der das Backend von Trustify die Daten speichert
• Über Aufrufen der vom Trustify-Backend bereitgestellten REST-Endpunkte

Beide Ansätze haben natürlich Vor- und Nachteile, was zu einer lebhaften Diskussion führte, die ich hier zusammenfassen möchte.

Vorteile einer direkten Verbindung zur DB:

1. Gut funktionierender Zugriff auf die Daten
2. Möglichkeit, einen Text to SQL-Ansatz zu verfolgen

Nachteile:

1. Der MCP-Server muss sich auf derselben Architekturebene wie das Backend befinden.
2. Zur Verwaltung des Datenzugriffs müsste Code dupliziert werden, im Vergleich zum Code im Backend.
3. Ein Datenformatmanagement ist erforderlich, um die Ausgaben der MCP-Tools-Aufrufe zu definieren.

Vorteile des Aufrufens der REST-Endpunkte:

1. Aufrufe unterliegen der Authentifizierung und Autorisierung, die bereits für die Backend-APIs vorhanden ist.
2. Die vom MCP-Server verfügbaren Daten stimmen vollständig mit den in der Benutzeroberfläche verfügbaren Daten überein, da sie dieselbe Datenquelle verwenden.
3. Die JSON-Ausgabe ist kostenlos verfügbar, indem Sie einfach die von den Backend-APIs zurückgegebene Ausgabe senden.

Nachteile:

1. Langsame Performance, da mehrere Architekturebenen durchlaufen werden müssen

Letztendlich haben wir uns dafür entschieden, die REST-Endpunkte über die Tools des MCP-Servers aufzurufen, da der Nachteil, den MCP-Server neben dem Backend und „nah genug“ an der Datenbank platzieren zu müssen, ein echtes Hindernis darstellte, insbesondere bei einem MCP-Server, bei dem der stdio-Transport lokal auf den Entwicklungshosts ausgeführt wird.

Ein weiterer Vorteil in dieser ersten Entwicklungsphase war, dass alle Daten „kostenlos“ in JSON-Antworten formatiert wurden.

Definition der Tool-Beschreibungen des MCP-Servers

Nachdem wir beschlossen hatten, dass die Tools des MCP-Servers die Backend-APIs aufrufen sollen, mussten wir entscheiden, wie wir die verschiedenen Tools beschreiben wollten. Wir wollten, dass in der ersten Iteration die einzelnen MCP-Tools jeweils einen einzelnen Backend-API-Endpunkt aufrufen.

Da Trustify die verfügbaren Endpunkte mithilfe der OpenAPI-Datei openapi.yaml dokumentiert, haben wir uns entschieden, die Beschreibung und Definitionen der OpenAPI-Endpunkte als Beschreibung für das MCP-Tool zu verwenden, um beurteilen zu können, wie gut die Dokumentation dieser Endpunkte für unsere Nutzenden ist. Damit wurde unsere agentische KI (Agentic AI) effektiv zum „Customer Zero“ unserer eigenen APIs.

Unser Ziel ist es, uns immer weiter zu verbessern. Wenn die Beschreibungen der APIs von Trustify gut genug sind, dass ein LLM damit umgehen kann, sollten unsere Nutzenden diese Dokumentation auch verstehen können.

Mit diesem Ansatz können wir die einzelnen Endpunkte verbessern, was uns zu unserer nächsten Entwurfsentscheidung führte.

Entwurf der Tool-Parameter des MCP-Servers

Nun standen wir vor dem Problem der Eingabeparameter für den Aufruf des Tools, und um es zu verstehen, mussten wir wieder etwas weitreichender denken. Der Endpunkt von Trustify zum Abrufen einer Liste von Entitäten akzeptiert einen q-Query-Parameter. Mit diesem Parameter können Nutzende eine Abfrage basierend auf einer Grammatik angeben, die in den OpenAPI-Spezifikationen definiert ist. 

Uns standen folgende Optionen zur Verfügung:

1. Den q-Pfadparameter des Endpunkts direkt als Eingabeparameter des MCP-Tools verfügbar machen
2. Die inneren Felder verfügbar machen, die zum Erstellen des Abfragewerts für den Parameter q als Eingabeparameter des MCP-Tools verfügbar sind

Wir haben beide Ansätze getestet.

Der erste Ansatz erfordert eine genaue und detaillierte Beschreibung des Query-Parameters, die derzeit von der OpenAPI-Spezifikation nicht bereitgestellt wird. Wir sind der Meinung, dass eine umfassende Liste von abfragenden Feldern ein obligatorischer – und kein optionaler – Teil der Dokumentation sein sollte. Es wäre nützlich, wenn sämtliche Nutzende Zugriff auf diese Informationen hätten.

Dieser zweite Ansatz vereinfacht den Prozess für den KI-Agenten. Durch explizite Auflistung der abzufragenden Parameter, wie etwa Schweregrad der Schwachstelle, Veröffentlichungsdatum oder Beschreibung, werden die Informationen für das LLM besser nutzbar. Dadurch entfällt die Notwendigkeit, dass das LLM zuerst die Grammatik einer Abfrage interpretiert, was beim ersten Ansatz ein komplexer Schritt sein kann.

Eine weitere Überlegung ist, dass die explizite Auflistung aller verfügbaren Parameter im MCP-Tool kontinuierliche Arbeit erfordert, um die Konsistenz mit der tatsächlichen Backend-Endpunkt-Implementierung aufrechtzuerhalten. Andererseits hat die Freigabe nur eines Teils der verfügbaren Parameter zur Folge, dass die Vielseitigkeit des Tools eingeschränkt wird, ohne dass eine Verringerung des Verwaltungsaufwands garantiert ist.

Wir haben uns entschlossen, mit der Verwendung eines q-Query-Parameters für das MCP-Tool fortzufahren und seine Beschreibung in der OpenAPI-Definition zu erweitern, damit alle Nutzenden davon profitieren können.

Zusammenfassung

Beim Design eines MCP-Servers haben wir den folgenden Ansatz gewählt:

• Der MCP-Server nutzt die vorhandenen APIs.
• Der MCP-Server nutzt die vorhandene OpenAPI-Dokumentation.
• MCP-Servertools machen denselben Parameter verfügbar, den der Remote-API-Endpunkt erwartet.

Wie bereits erwähnt, ist das Endergebnis auf GitHub verfügbar.