Thantaree | shutterstock.com

Generative-AI-Tools und KI-Agenten dafür “fit” zu machen, mit der Außenwelt zu interagieren, ist die Voraussetzung dafür, dass diese autonom reale Tasks übernehmen können. Dieses Ziel in großem Maßstab zu verwirklichen, war für Entwickler lange schwierig, da sie dafür viel Aufwand in komplexen, maßgeschneiderten Code stecken mussten. Dieses Problem wollen gleich mehrere Protokolle lösen, die in den letzten Monaten an den Start gebracht wurden. Hervorgetan hat sich dabei insbesondere das vom KI-Anbieter Anthropic Ende 2024 veröffentlichte Model Context Protocol.

In diesem Artikel erfahren Sie,

• wie sich (ein) MCP(-Server) definiert,
• wo der Unterschied zu RAG und Funktionsaufrufen liegt, und
• wie Model Context Protocol funktioniert.

Model Context Protocol – Definition

Model Context Protocol ist ein quelloffener Standard, der KI-Systeme mit Datenbanken, Dateisystemen und anderen Tools verbindet. Damit entsteht auch eine effiziente, standardisierte Möglichkeit, um KI-basierte Agenten aufzubauen. Dabei funktioniert MCP über eine Server-Client-Architektur.

MCP-Server definiert

Bevor wir uns mit den verschiedenen Komponenten der MCP-Architektur befassen, gilt es zunächst auch den Begriff „MCP-Server” zu definieren, der mittlerweile fast so etwas wie ein Synonym für das Protokoll selbst geworden ist. Ein MCP-Server ist ein leichtgewichtiges Programm, das zwischen einem KI-System und einem Service oder einer Datenquelle angesiedelt ist. Der MCP-Server fungiert als Brücke und kommuniziert mit der KI über einen MCP-Client in einem standardisierten Format. Mit anderen Services oder Datenquellen läuft die Verbindung über die API, die diese bereitstellen. MCP-Server sind relativ einfach zu erstellen. Auch weil viele dieser Server kostenlos verfügbar sind – beispielsweise über GitHub.  

MCP, RAG & Function Calling

MCP ist nicht die erste Technik, die entwickelt wurde, um KI mit der Außenwelt zu verbinden. So ermöglicht etwa Retrieval Augmented Generation (RAG) großen Sprachmodellen (LLMs), Dokumente einzubeziehen, die nicht Teil ihrer Trainingsdaten sind. Das erfordert allerdings, die Zieldaten in eine Vektor-Datenbank zu übertragen.  

Diverse LLMs unterstützen außerdem das Feature, Funktionen aufzurufen (Function Calling). Diese Sprachmodelle erkennen es, wenn ein Benutzer-Prompt den Einsatz eines Hilfswerkzeugs erfordert.

Model Context Protocol setzt auf dieser Function-Calling-Fähigkeit auf, bietet aber eine standardisierte(re) Möglichkeit, eine Verbindung zu Diensten und Datenquellen herzustellen. So wird es möglich, KI-Systeme mit externen Quellen zu verbinden, ohne jedes Mal das Rad neu erfinden, respektive programmieren zu müssen.  

Die MCP-Architektur

Werfen wir nun einen Blick auf die verschiedenen Komponenten der MCP-Architektur und deren Zusammenspiel.

• Der MCP-Host ist die KI-basierte Anwendung, die die Verbindung zur Außenwelt herstellt. Als Anthropic MCP einführte, integrierte es das Protokoll in seine Desktop-Anwendung von Claude, die damit zu einem der ersten MCP-Hosts wurde. Hosts sind allerdings nicht auf LLM-basierte Chatbots beschränkt. Auch eine KI-gestützte IDE könnte beispielsweise als Host dienen. Ein Host-Programm umfasst das Kern-LLM sowie eine Vielzahl von Hilfsprogrammen.
• Der MCP-Client ist das wichtigste dieser Hilfsprogramme. Jedes LLM benötigt einen Client, der an die Art und Weise angepasst ist, wie es Tools aufruft und Daten verarbeitet. Alle MCP-Clients bieten ihren Hosts jedoch einen Standardsatz an Diensten. Sie suchen nach verfügbaren Servern und melden diese Dienste sowie die für ihren Aufruf erforderlichen Parameter zurück. All diese Informationen werden in den Prompt-Kontext des LLM übernommen. Wenn das LLM eine Benutzereingabe erkennt, die einen verfügbaren Service aufrufen soll, sendet es eine entsprechende Anfrage über den Client an den jeweiligen MCP-Server.
• Jeder MCP-Server ist so aufgebaut, dass er mit einer Datenquelle oder einem externen Service in einer Sprache kommuniziert, die diese „verstehen“. Er kommuniziert zudem mit dem MCP-Client, fungiert also als eine Art Vermittler zwischen den beiden Komponenten.
• MCP-Client und MCP-Server kommunizieren in einem JSON-basierten Format miteinander. Der MCP-Transport-Layer konvertiert MCP-Protokollnachrichten für die Übertragung in das JSON-RPC-Format und konvertiert JSON-RPC-Nachrichten auf der Empfängerseite zurück. Zu beachten ist dabei, dass ein Server lokal auf demselben Rechner wie der Client oder online ausgeführt werden kann. Im ersten Fall erfolgt die Client-Server-Kommunikation über stdio, im zweiten Fall über streambares HTTP.

Das nachfolgende Schaubild demonstriert, wie die MCP-Komponenten zusammenwirken.

Foundry

Das MCP-Server-Ökosystem

Obwohl die Architektur mit ihren Komponenten auf den ersten Blick komplex erscheint, sorgen die Modularität, Portabilität und Standardisierung von MCP dafür, dass Entwickler ein leichteres Leben haben. Denn:

• Ein MCP-Server kann mit jeder KI-Anwendung kommunizieren, die einen ordnungsgemäß implementierten MCP-Client enthält. Wenn Sie Ihren Service für KI-Agenten verfügbar machen möchten, können Sie also einen einzigen Server erstellen und haben die Sicherheit, dass dieser mit diversen Arten von LLMs funktioniert.
• Ein MCP-Client muss umgekehrt zwar auf einen bestimmten Host zugeschnitten sein, kann aber mit jedem ordnungsgemäß implementierten MCP-Server verbunden werden. Sie müssen also nicht herausfinden, wie ein spezifisches LLM mit Google Docs, einer MySQL-Datenbank oder einem Wettervorhersagedienst verbunden werden kann. Es gilt lediglich einen MCP-Client zu erstellen. Dieser kann über MCP-Server eine Verbindung zu Diensten aller Art herstellen.

Für tiefere Einblicke in das MCP-Server-Ökosystem empfiehlt sich ein Besuch des MCP Servers Repository auf GitHub. (fm)

Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!