Auf dem geplanten Weg zu autonomen Agenten, die von großen Sprachmodellen (LLMs) angetrieben werden, ist das Model Context Protocol (MCP) derzeit eines der aktuellsten Themen. Auf Konferenzen, Podiumsdiskussionen oder Meetings mit viel Kaffee sprechen alle über MCP-gestützte Agentensysteme. Dies erweckt insgesamt den Eindruck, dass Agenten bereits kurz davor stehen, ein eigenes Bewusstsein zu haben und sich selbst weiterzuentwickeln – bereit, all Ihre geschäftlichen Herausforderungen in nur wenigen Minuten auf unkonventionelle Weise zu lösen.
Bevor wir uns jedoch alle für ein lebenslanges Ticket für diese rasante Fahrt lösen und die Kontrolle über unsere Unternehmen abgeben, sollten wir einen Moment innehalten und uns fragen:
Was steckt wirklich hinter diesem Hype? Was passiert jenseits der Schlagworte und der Demo-Videos, in denen rasend schnell Text generiert wird, unter der Oberfläche dieser MCP-gestützten Systeme und warum genau brauchen wir sie? Wie fügt sich MCP in die bestehende LLM-Technologielandschaft ein und welche Anwendungsfälle und konkreten Anwendungen gibt es? Welche Herausforderungen birgt der aktuelle Status von MCP, etwa in puncto Sicherheit, Akzeptanz und Reife?
Wir möchten diese Fragen nach und nach in unserer Artikelserie über MCP beantworten und beginnen hier mit einer praxisorientierten Einführung in das Thema. Also, schnallen Sie sich an, holen Sie sich Popcorn und bewegen Sie sich mit uns auf dem Grat zwischen Hype und Realität – und entdecken Sie, wie MCP dort hineinpasst.
Vor nicht allzu langer Zeit wurden die ersten LLM-basierten Anwendungen veröffentlicht. Sie wurden schnell Teil sowohl unternehmerischer als auch persönlicher Workflows. Das vermutlich bekannteste Beispiel dafür ist ChatGPT von OpenAI mit seinen zugrundeliegenden GPT-Modellen.
Wenn ein solches LLM Output bzw. Antworten generiert (auch Inferenz genannt), kann es nur die Token (oder vereinfacht gesagt, den Text) in seinem Kontextfenster „sehen“. Das ist das Kurzzeitgedächtnis des Modells . Es besteht aus dem aktuellen Prompt, dem Konversationsverlauf, einem System-Prompt und/oder dem „zusätzlichen Kontext“. Der zusätzliche Kontext enthält Informationen aus Quellen außerhalb des Wissens des LLM, die von Tools bereitgestellt werden, auf die das Modell zugreifen kann, z. B. durch Abrufe aus Wissensrepositorien, ein Python-Script oder eine Internetrecherche.
Der richtige Kontext ist für ein LLM daher entscheidend, um relevante, plausible und präzise Antworten zu generieren. Andernfalls würde es manchmal nur „raten“, , ein Phänomen, das allgemein als „Halluzinieren“ bezeichnet wird.
Seit diesen ersten LLM-basierten Anwendungen sind viele neue Modelle entstanden, die alle auf geeigneten Kontext angewiesen sind . Gleichzeitig hat sich eine Vielzahl neuer Anwendungen entwickelt, die auf LLMs aufbauen. In unseren Projekten beobachten wir, dass dieselben Anwendungsfälle oft eine erhebliche Anzahl an Implementierungen erfordern. Ein beliebter Anwendungsfall bei unseren Kunden und ein gutes Beispiel dafür sind Anwendungen, die Informationen aus Unternehmensdateien abrufen und zusammenfassen. Dies sind Fähigkeiten, die oftmals von sogenannten Retrieval Augmented Generation (RAG)-Systemen bereitgestellt werden. Doch die Flexibilität, mit der diese oder LLM-basierte Anwendungen eher allgemein implementiert werden, führt oftmals zu mehreren Problemen gleichzeitig, einige nennen wir hier:
Genau an dieser Stelle kommt MCP ins Spiel, das 2024 von Anthropic in 2024:
Es ist ein allgemeiner Schnittstellenstandard, der die Kommunikation und den Datenfluss definiert, tool-/ressourcenspezifische Implementierungen und Redundanzen vermeidet und die einfache Anbindung an LLMs per Plug-and-Play ermöglicht. MCP kann somit analog zu anderen technischen Standards wie Wireless-LAN oder USB-C betrachtet werden und es bereichert den Kontext eines individuellen LLM, indem es zusätzlichen Kontext über Dienstprogramme auf generalisierte Weise bereitstellt. Diese Dienstprogramme, die als MCP-Server bezeichnet werden, werden genau einmal entwickelt und können überall eingesetzt werden. Sie erweitern effektiv eine wachsende Liste mit Standard-Plugins.
Stellen Sie sich ein multinationalen Fertigungsunternehmen mit mehreren Produktionsstandorten in verschiedenen Regionen vor, die alle über ein ERP- System für die Lagerhaltung und den Einkauf sowie über Datenbanken mit historischen Produktionstrends verbunden sind. Das Betriebsteam des Unternehmens möchte mithilfe von KI-basierter Unterstützung intelligentere und schnellere Entscheidungen treffen – aber mit Antworten, die auf tatsächlichen Produktions- und Lieferkettendaten aus verschiedenen Quellen basieren.
Ein Business-Szenario könnte so aussehen: Ein Supply Chain Manager die Chat-Oberfläche des Unternehmens öffnet und stellt die Frage: „Wie ist die aktuelle Produktionsauslastung in Deutschland und welche Konsequenzen ergeben sich daraus für Bestandsmanagement und Einkauf?"
Statt einer generischen Antwort gibt das Assistenztool eine klare und umsetzbare Antwort.
„Die aktuelle Produktionsauslastung der deutschen Werke liegt bei 85 % im Vergleich zu 78 % in der letzten Woche. Bei dieser Quote werden die Materialbestände voraussichtlich in fünf Tagen vollständig aufgebraucht sein. Die aktuelle Zeit für die Beschaffung liegt bei durchschnittlich sieben Tagen, was auf einen potenziellen Engpass hinweist, sofern die Bestellungen nicht erhöht werden. Es wird empfohlen, die Bestellimpulse anzupassen oder Produktionslinien, die keine Priorität haben, neu zu planen.
Dies ist ein typischer Anwendungsfall, der durch die Implementierung eines RAG-Systems realisiert wird. Wir sehen dies im Moment häufig: ein virtueller Chat-Assistent basierend auf LLMs, der tatsächliche Unternehmenssysteme zur Erfüllung seiner Aufgaben nutzt und die verfügbaren Unternehmensinformationen als grundlegenden Kontext, der für eine effektive Erfüllung der Aufgaben entscheidend ist, anwendet.
Als Grundlage für die Implementierung eines solchen RAG-Systems können wir die Unternehmenssysteme jetzt durch eine benutzerdefinierte Logik und API-Aufrufe integrieren. Dies erfordert zunächst Zeit, Wissen über die Systeme und die Kommunikation mit den Systemverantwortlichen über die entsprechende Integration. Zweitens müssen wir eventuell Infrastruktur-Themen wie Performance und Kosten sowie Sicherheitsaspekte berücksichtigen. Zuletzt müssen wir die Wartbarkeit und die langfristige Kompatibilität im Hinblick auf die integrierten Systeme gewährleisten.
An dieser Stelle setzt MCP an und entfaltet seine Vorteile: Für jedes der zugrunde liegenden Quellsysteme im Bereich benötigt (in diesem Szenario das ERP-System und die Datenbanken, die wichtige zusätzliche Kontextinformationen des Unternehmens bereitstellen) wird ein MCP-Server benötigt. Dieser muss zunächst gemäß dem MCP-Standard implementiert werden und kann dann lokal oder über die Cloud zugänglich gemacht werden. MCP ermöglicht dann die Plug-and-Play-Nutzung in jeder einzelnen Anwendung, ohne dass alle oben genannten Punkte erneut beachtet werden müssen.
Die folgende Abbildung zeigt dies für zwei beispielhafte Anwendungen (App 1 und App 2). Die für die Verbindung der verschiedenen Technologien erforderliche benutzerspezifische Logik wird in der Anwendungsschicht durch die Einführung von MCP drastisch reduziert. Sie wird in die Framework-Schicht verschoben, wobei die Technologieverantwortlichen für die Implementierung der MCP-Server zuständig sind, da sie über das Wissen über die Business-Logik verfügen.
Systemdesign für zwei Anwendungen - traditionell vs. mit MCP.
Für den genannten Anwendungsfall bedeutet dies, dass die einzelnen Aufwände für die Implementierung und Integration dieser Systeme nach der Einrichtung des ERP-Systems und der Datenbank-MCP-Server minimiert werden. Sie können problemlos unternehmensweit wiederverwendet und zentral skaliert werden, mit einer klaren Trennung der Zuständigkeiten und der Modularität. Dies reduziert den Gesamtaufwand für die Realisierung des RAG-Systems für unser multinationales produzierendes Unternehmen und potenziell auch für alle zukünftigen RAG-Systeme erheblich.
Ausgehend von seiner Kernstruktur ermöglicht das MCP-Konzept auf natürliche Weise autonomere Systeme, die MCP-Server nach Bedarf zur Erfüllung einer Aufgabe verwenden. Diese Systeme - Agenten genannt - können nicht nur zusätzlichen Kontext nutzen, sondern auch auf ihn reagieren, mehrstufige Lösungen planen, Entscheidungen treffen und mit ihrer Umgebung oder anderen Agenten zielgerichtet interagieren.
Es wurden mehrere Protokolle entwickelt, um die Interaktion und die Koordination zwischen den Agenten zu erleichtern . Zu den Beispielen für derartige Protokolle gehört das von IBM eingeführte Agent Communication Protocol (ACP), das den Nachrichtenaustausch zwischen Agenten in lokalen Umgebungen oder in einer gemeinsamen Laufzeitumgebung ermöglicht, wobei der Fokus auf Datenschutz, Beobachtbarkeit und reibungslosem Betrieb liegt. Ein weiteres Beispiel ist das Agent-to-Agent (A2A) Protocol von Google, das den Austausch über Domains und Cloud-Umgebungen in Echtzeit auf dynamische und locker gekoppelte Weise unterstützt. Schließlich bietet das Open Source Agent Network Protocol (ANP) eine dezentralisierte Netzwerkschicht für Agenten-Ökosysteme im gesamten offenen Internet. Diese wurde für zukünftige Agenten-Marktplätze oder Ähnliches konzipiert.
ACP, A2A, und ANP sprechen verschiedene Bereiche der Inter-Agenten-Kommunikation an und befähigen Agenten auf diese Weise miteinander zu sprechen. Im Gegensatz dazu agiert MCP als standardisierte Kontextschicht für einen einzelnen Agenten und fokussiert sich auf die Bereitstellung interner Kapazitäten, um mit verschiedenen Tools und Daten auf strukturierte Weise effektiv zu beurteilen, zu planen und zu handeln.
Wir haben jetzt unsere erste Station auf dieser spannenden Reise erreicht, aber die nächsten Haltestellen werden noch aufregender. In diesem Artikel haben wir Ihnen erste Hintergründe und die Positionierung von MCP als Konzept dargestellt - seinen allgemeinen Ansatz und seine Vorteile, einen beispielhaften Anwendungsfall und seinen Bezug zu Agentensystemen.
Im zweiten Artikel werden wir uns intensiver mit der Struktur und den Konzepten von MCP beschäftigen. Was bedeuten Begriffe wie „MCP-Host“, „MCP-Client“ und „MCP-Server“ wirklich und wie fügen sie sich zusammen? Wie ist der Reifegrad des MCP zum Beispiel im Hinblick auf Sicherheit und Akzeptanz und wo sehen wir Verbesserungspotenzial ? Betrachten Sie es als den Bauplan hinter dem Protokoll - enthüllt.
In Artikel 3 werden wir einen kurzen Reality-Check durchführen . Sie werden sehen, wie wir, das HMS- Team, MCP bereits einsetzen, um betriebliche Abläufe zu optimieren, Kundenanwendungen zu implementieren oder zu verbessern und letztendlich intelligentere Dienstleistungen zu erbringen. Es erwarten Sie Einblicke in die Praxis, Code Snippets und auch ein kurzer Blick in unser proprietäres Code-Migrationstool sowie in einige Kundenprojekte.
In Artikel 4 werden wir uns erneut auf Agentensysteme konzentrieren und mit den Protokollen beginnen, die wir bereits zuvor in diesem Artikel kurz erwähnt haben . Wie funktionieren sie im Detail? Ergänzen sie sich gegenseitig und bieten so Synergien oder konkurrieren sie miteinander? Was sind die individuellen Vor- und Nachteile, die Anwendungsfälle und welche allgemeinen Entwicklungen gibt es im Markt?
Die Basis wurde gelegt. Der nächste „Halt“ ist die Architektur. Wenn Sie gern weiter über MCP diskutieren möchten, sprechen Sie uns gern an. Und behalten Sie unseren Blog im Blick: Wir werden in Kürze neue Artikel in dieser Serie veröffentlichen und darin sowohl technische Deep Dives als auch reale Anwendungen zeigen.
