Model Context Protocol: Potenziale und Risiken des MCP

Vom einfachen LLM hin zu Model Context Protocol

 Die Evolution von isolierten LLMs hin zu vielseitigen Tools zeigt, wie sich die Möglichkeiten von KI-Anwendungen im Laufe der Zeit erweitert haben. Als die ersten Modelle veröffentlicht wurden, waren sie von der Außenwelt abgeschlossene Systeme und waren allein auf Texteingaben angewiesen, um Fragen zu beantworten und Instruktionen auszuführen. Diese Mechanik ist zwar beeindruckend, ist jedoch auf das antrainierten Wissen innerhalb des LLM Modells beschränkt.

Mit der Integration von externen Tools in die Architektur von LLMs eröffnete sich eine neue Dimension der Interaktion. Diese Tools ermöglichen es LLMs, mit der Außenwelt kommunizieren und Informationen aus verschiedenen Quellen abzurufen zu lassen. Viele Anbieter haben bereits die Möglichkeit Tools an das LLM weiterzugeben in ihren APIs integriert. Der Prozess ist hierbei häufig sehr ähnlich:

1. Zusätzlich zu dem Prompt werden eine Reihe von Tools inklusive einer Beschreibung und den erforderlichen Parametern mitgegeben.
2. Das LLM entscheidet basierend auf dem Prompt kein, ein oder mehrere Tool/s aufzurufen und gibt diese Tools mit den entsprechenden Parametern an den Nutzer zurück.
3. Der das LLM aufrufende Client (oft eine Webanwendung) führt die entsprechenden Tools aus und schickt das Ergebnis wieder an das Modell.

In allen Fällen ist der Client für die Ausführung der Tools verantwortlich. Das bedeutet aber auch, dass dieser sich um die Verbindung zu etwaigen Datenquellen über entsprechende APIs und das zugehörige Berechtigungsmanagement kümmern muss.

Für einige wenige Anbindungen mag der Aufwand überschaubar sein, jedoch steigt der Wartungsaufwand mit jeder Anbindung um ein Vielfaches an, da jeder Service eine andere Sprache spricht. Jedes neue Tool wird geradezu in die eigene KI-Anwendung “eingebacken” und eine monolithische Architektur entsteht. Der Grund dafür – es gibt kein einheitliches Interface, um mit unterschiedlichsten Tools mit einem standardisierten Protokoll zu kommunizieren. Das Model Context Protocol (MCP) bietet eine derartige Standardisierung an.

MCP nimmt die Rolle als Mediator zwischen LLM/KI-Anwendung und den einzelnen Services (oft sind es Datenquellen) ein. So behandelt MCP jegliche “API Sprache” und versteckt die Komplexität der Handhabung von Tools hinter einem standardisierten Protokoll. Dadurch ermöglicht es Entwicklern, sich auf die fachlichen Inhalte zu konzentrieren: die Gestaltung intelligenter Anwendungen, ohne sich in den Details der Integration zu verlieren. Dank dieser universellen Schnittstelle können LLMs flexibel mit unterschiedlichen Datenquellen und Services kommunizieren, was die Effizienz und Skalierbarkeit von KI-Anwendungen erheblich steigert.

Architektur und Funktionsweise von MCP

Da diese Erklärung zugegebenermaßen noch sehr abstrakt ist, möchte ich die Funktionsweise von MCP an einem Architekturschaubild erläutern. MCP besteht aus den folgenden Hauptkomponenten, welche im Grundkern einer Client-Server Architektur entsprechen:

• MCP Host: KI-Anwendung welche sich um die Erstellung und Management von MCP Clients kümmert (Beispiel: Claude Desktop)

• MCP Client: Verbindet sich mit jeweils einem MCP Server (1:1 Verbindung)

• MCP Server: Verbindet sich mit Datenquellen und stellt entsprechende Tools bereit (Eine Auflistung von MCP Servern findet sich hier)

• Datenquellen: Lokale Dateien oder Remote Services

Die Kommunikation zwischen Client und Server kann entweder über Stdio (die Konsole) oder über HTTP erfolgen. Ersteres ist ideal für lokale MCP Server während HTTP für remote Server eingesetzt werden kann. Ein zentraler Bestandteil des MCP Protokolls ist die Discovery von Werkzeugen. Durch dieses Konzept wird es den Clients ermöglicht alle Tools durch einen einheitlichen Endpunkt (/tools/list) abzufragen. Der Server antwortet mit einer Auflistung aller Tools inklusive einer Beschreibung und der benötigten Argumente, um ein Tool zu nutzen (bspw. eine Frage für einen Suchdienst oder die der Issue-Key von einem Jira-Ticket, das wir bearbeiten möchten).

Diese Tools können entsprechend an das LLM übergeben werden, welches basierend auf dem Prompt eines oder mehrerer dieser Tools auswählen kann, um die Anfrage des Nutzers zu beantworten. Wenn ein Tool verwendet werden soll, stellt jeder MCP Server einen entsprechenden Endpunkt zur Verfügung (/tool/call). Der Client übergibt den Tool-Namen, sowie alle benötigen Parameter über diesen Endpunkt an den Server, welcher daraufhin das Tool ausführt. Das Ergebnis des Toolaufrufs kann daraufhin als zusätzlicher Kontext an das LLM übergeben werden, um die initale Anfrage des Nutzers beantworten zu können.

Anwendungsfelder von MCP

Ein Beispiel kann so aussehen: “Such bitte unsere Definition of Done im Projekt ABC aus dem Confluence und wende sie auf das Jira-Ticket ABC-123 an.“

Die Anwendungsfelder von MCP sind vielseitig. Gerade durch die Standardisierung von MCP Servern stellen viele Serviceprovider MCP Schnittstellen für ihre Datenquellen bereit. Hierdurch müssen entsprechende Adapter nicht händisch implementiert werden und sind somit in unterschiedlichen Szenarien wieder verwendbar. Diese Flexibilität reduziert den Entwicklungsaufwand und beschleunigt die Implementierung neuer Funktionen.

Ein in dem letzten Jahr zunehmend relevanter Anwendungsfall von modernen KI-Anwendung ist die Enterprise Search. Dabei steht die Anbindung von diversen Datenquellen an eine zentrale Suchfunktion im Vordergrund, um Verbindungen zwischen isoliertem Wissen über verschiedene Systeme hinweg herzustellen. MCP spielt hierbei eine zentrale Rolle, da es die Integration unterschiedlichster Wissensquellen erleichtert. Durch die nahtlose Anbindung dieser Quellen können Unternehmen die gesammelten Informationen innerhalb einer RAG Pipeline nutzen, um präzisere und kontextreichere Antworten zu generieren.

MCP ist jedoch nicht nur auf die Anbindung von Wissensquellen beschränkt, sondern kann ebenso zur Integration verschiedener Tools eingesetzt werden. Dies eröffnet ganz neue Möglichkeiten für die Entwicklung von Support-Bots. Diese Bots können nun nicht nur Fragen beantworten, sondern auch konkrete Aktionen auslösen, wie beispielsweise das Erstellen von Jira Tickets oder das Bearbeiten und kommentieren von Confluence Seiten. Durch die Kombination von intelligenten Antworten und der Möglichkeit, direkt in Arbeitsprozesse einzugreifen, erhöhen Support-Bots die Effizienz und Effektivität im Kundenservice und in internen Abläufen erheblich. MCP schafft hierbei ein flexibles System in dem Tools ohne großen Aufwand hinzugefügt oder entfernt werden können.

Alternativen zu MCP - Atlassian Rovo und Co.

Die Funktionalität von MCP als Drehscheibe und Grundlage für ein Ökosystem von spezifischen Agenten ist strategisch verführerisch für die großen Plattformanbieter, deren Dienste oft Datenquellen in Enterprise-AI-Anwendungen sein werden: Sowohl Microsoft als auch Atlassian oder auch Slack positionieren sich, um hier nicht nur eine passive Rolle zu spielen, sondern selbst die Drehscheibe zu sein. Tatsächlich sieht die Implementierung von Atlassian Rovo dem MCP-Konzept sehr ähnlich und es werden auch ähnliche Anwendungsfälle adressiert.

Hier versteckt sich eine Make-or-Buy-Entscheidung mit weitreichenden architekturellen Implikationen: Bewegen wir uns mit der LLM-Dienst-Integration innerhalb eines Ökosystems, können wir auf ein homogenes Berechtigungsmanagement hoffen. Agenten lesen und schreiben mit den Berechtigungen der aktiven Nutzerin. Bei der Anbindung heterogener Systeme stellt sich die Frage der Authentifizierung jeweils neu und es ist nicht klar, ob die aktive Nutzerin überhaupt Zugriff auf alle angebundenen Systeme hat und wenn ja, mit welchen Berechtigungen. Zudem ermöglichen die Plattformen viele Freiheiten für Self-Service und Citizen Developer.

Der MCP-Ansatz auf der anderen Seite ist vor allem eine Befreiung aus solche “Walled Gardens” und bedeutet die Unabhängigkeit von den einzelnen Plattformen und ihren (teils volatilen) Spielregeln und Rahmenbedingungen. Eine On-Premise-Implementierung auf MCP-Basis ist gut vorstellbar, die großen Plattformen sind implizit beschränkt auf Daten, die in der Cloud verarbeitet werden dürfen. Entsprechende Lösungen entstehen nicht im Self-Service / No-Code-Modus, bringen aber alle Freiheiten und Qualitäten moderner Software-Entwicklungsprozesse mit.

Die Ankündigung eines Remote MCP-Servers durch Atlassian (Beta) stellt hier eine spannende Mischung der beiden Alternativen dar.

Was sind die Risiken?

Wir haben in den vorherigen Kapiteln den Fokus auf den Vorteilen von MCP gelegt, wir dürfen aber nicht vergessen, dass MCP noch ein sehr neuer Standard ist und auch mit Risiken einhergeht. Gerade in dem Bereich der Compliance gibt es potenzielle Risiken, welche bei einem Einsatz von MCP in der eigenen Enterprise KI-Anwendung berücksichtigt werden müssen.

• Ein besonders kritisches Risiko besteht in der autonomen Entscheidung des LLMs, bestimmte Tools auszuwählen und auszuführen. Diese Entscheidungsfreiheit kann zu unkontrollierten Datenmanipulationen und Datenverlust führen, sowie zu unerwünschten Änderungen an den angebundenen Systemen. Wenn KI-Systeme in der Lage sind, ohne menschliches Eingreifen zu agieren, besteht die Gefahr, dass essenzielle Daten versehentlich verändert oder gelöscht werden. Solche autonomen Entscheidungen sind sogar durch den EU AI Act für Hoch-Risiko KI-Systeme untersagt. Bei solchen Systemen muss ein Mensch die Entscheidungen der KI immer hinterfragen und bestätigen. Es ist daher entscheidend geeignete Sicherheitsmechanismen und Human-in-the-loop Ansätze einzuführen.

• Ebenso kritisch zu sehen ist, dass es der MCP-Standard einfach macht, LLM-Agenten im eigenen Namen agieren zu lassen - bspw. mit einem Kommentar im Jira. Das ist nicht nur schlechter Stil sondern auch nicht im Sinne der Transparenzverpflichtungen per Artikel 50 (1) des EU AI Acts.

Fazit

Model Context Protocol ist eine wegweisende Lösung zur Integration von Datenquellen und Tools für Large Language Modelle (LLMs). Es ermöglicht Unternehmen, isolierte Datensilos zu überwinden und die Effizienz ihrer KI-Anwendungen durch ein einfaches Plug-and-Play erheblich zu steigern. Gleichzeitig müssen potenzielle Risiken, insbesondere in Bezug auf Datenkontrolle und Compliance, ernst genommen werden. Ein verantwortungsvoller Umgang mit MCP ist entscheidend, um das volle Potenzial dieser Technologie auszuschöpfen und gleichzeitig Sicherheitsstandards einzuhalten.

Sie möchten MCP auch in Ihrem Ökosystem einsetzen?

Wir unterstützen Sie bei der Konzeption, Implementierung und Betrieb – wir beraten Sie, ob und wie Sie MCP als universellen Konnektor in Ihrem Unternehmen einführen können.

Auf dem KI-Roundtable (20.05.2025) der viadee in Dortmund wird es auch um diese Themen gehen.