Dies ist der zweite Artikel unserer HMS-Artikelserie zum Model Context Protocol (MCP), der einen tiefen Einblick in dessen Struktur und Konzepte bietet.
Wir erläutern die Rollen von MCP Host, Client und Server, zeigen, wie Funktionen wie Tools und Ressourcen bereitgestellt werden, und betrachten, wie diese Komponenten in typischen Workflows zusammenwirken. Der Artikel behandelt außerdem die grundlegenden Protokoll-Primitiven, Transportmechanismen und Sicherheitsaspekte.
Falls Sie unseren ersten Artikel noch nicht gelesen haben: MCP: Skalierbare und standardisierte LLM-Integration für Unternehmen
MCP verwendet eine Client-Server-Architektur mit drei zentralen Rollen:
Learn how MCP works: roles of host, client & server, core primitives, transport layer, and security for enterprise LLM workflows.
Der MCP Host kann sich parallel mit mehreren MCP Servern verbinden, wobei jeder Server von seinem eigenen Client verwaltet wird. Diese modulare Architektur stellt eine klare Trennung der Verantwortlichkeiten sicher und unterstützt Sandboxing sowie kontrollierten Zugriff. So kann der Host beispielsweise Nutzerfreigaben zwischen dem LLM und jeder Server-Interaktion erzwingen.
Mindestens eine LLM-Instanz läuft innerhalb des MCP Hosts und fungiert als Konsument des Kontexts. Über den Host können die Instanzen MCP Clients auslösen, um Tools auszuführen oder auf Ressourcen und Prompts zuzugreifen, die von einem MCP Server bereitgestellt werden. Das LLM nimmt jedoch in der MCP-Spezifikation keine definierte Rolle ein und funktioniert als Teil des Hosts und nicht als eigenständige Protokollkomponente.
Aus der Perspektive agentischer Systeme ähneln sich die Aufgaben des MCP Hosts und eines Agents stark. Je nach Anwendungsfall und Interpretation können die Begriffe „MCP Host“ und „Agent“ synonym verwendet werden. Alternativ können sie auch als getrennte Komponenten betrachtet werden: Der Host fungiert als benutzerorientierte Anwendungs-Hülle, die die MCP-Infrastruktur bereitstellt. Der Agent ergänzt dies, indem er die Anwendungslogik kapselt und als intelligenter Orchestrator agiert, der mit dem LLM interagiert und die Client-Kommunikation steuert. Dieses Design erlaubt es, mehrere Agents gleichzeitig innerhalb eines einzelnen Hosts laufen zu lassen, wobei jeder als eigene Instanz mit eigenem Kontext- und Ressourcenumfang behandelt wird – sie können dabei auch zusammenarbeiten. Unabhängig von der Interpretation operiert der Agent immer auf der Host-Seite des Protokolls und nimmt, ebenso wie das LLM, keine definierte MCP-Rolle ein.
Die Kommunikation innerhalb von MCP erfolgt über eine Transportschicht auf Basis von JSON-RPC 2.0. Dies ermöglicht strukturierte Nachrichten über zustandsbehaftete Verbindungen zwischen Clients und Servern. MCP unterstützt sowohl lokale als auch entfernte Transportmechanismen für MCP Server, die entweder lokal oder in Cloud-Umgebungen laufen. Für lokale Kommunikation ist Standard Input/Output (STDIO) einfach und effektiv. Für die Remote-Integration unterstützt das Protokoll HTTP mit Server-Sent Events (SSE) oder Streamable HTTP. Letzteres wird zukünftig für Remote-Verbindungen empfohlen, ist aber noch nicht in allen derzeit verfügbaren MCP Software Development Kits (SDKs) vollständig implementiert. Neben einer schnell wachsenden Zahl von SDKs verschiedener Anbieter bietet auch Anthropic selbst offizielle SDKs für verschiedene Programmiersprachen an.
Während des Betriebs tauschen MCP Clients und Server Requests, Responses und Notifications aus. Jeder Server deklariert sein verfügbares Set an Funktionen über ein JSON Schema. Ein Cloud-Storage-Server könnte zum Beispiel Tools wie „search“ oder „duplicate_file“ anbieten. Dieses Setup unterstützt einen turnusmäßigen, dialogartigen Interaktionsprozess: Das LLM kommuniziert in natürlicher Sprache, ruft jedoch im Hintergrund Tools auf und greift standardisiert auf Ressourcen zu – genau dann, wenn es nötig ist.
Darauf werden wir in einem späteren Kapitel dieses Artikels mit einem Workflow-Beispiel noch einmal eingehen.
MCP führt drei Grundelemente (Funktionsarten) ein, die MCP-Server anbieten und bereitstellen:
Diagram of MCP composability: how servers, clients, and hosts interact with LLMs, featuring sampling for multi-agent workflows.
Ein einzelner MCP-Server kann beliebige Kombinationen dieser Grundelemente bereitstellen – von spezialisierten Servern, die sich nur auf ein einziges Element konzentrieren, bis hin zu monolithischen Servern, die eine breite Palette an Funktionalitäten anbieten.
Sobald geplant ist, dass ein MCP-Server und ein LLM automatisch miteinander interagieren, sollte ein modellgesteuertes Grundelement zur Verfügung stehen.
Diese Grundelemente werden durch zusätzliche Kommunikationsfunktionen ergänzt, die den Austausch zwischen Client und Server (und umgekehrt) unterstützen und weitere Anwendungsfälle ermöglichen:
Zusammengenommen ermöglichen diese Grundelemente und Funktionen, dass MCP reiche Schnittstellen definiert:
Ergänzt wird dies durch das Konzept der Komponierbarkeit (Composability): Ein MCP-Client kann selbst als Server agieren und umgekehrt (siehe Abbildung oben). Zusammen mit dem Sampling-Ansatz ermöglicht dies die Verkettung mehrerer MCP-Server und stärkt damit Multi-Agent-Topologien. Diese Komponierbarkeit ist Teil von MCPs Vision für ein modulares Ökosystem.
Weitere Informationen zu den beschriebenen Kernkonzepten und den aktuellen Entwicklungen finden Sie auf der Spezifikationsseite von Anthropic. Einen Überblick über Clients, die diese Kernkonzepte unterstützen, bietet die Feature-Matrix von Anthropic.
Um zu zeigen und zu erklären, wie MCP in einen Anwendungs-Workflow integriert werden kann, stellen wir uns eine beispielhafte RAG-Anwendung (Retrieval Augmented Generation) vor, die den unten dargestellten Schritten und Abläufen folgt.
Wenn die Anwendung startet, erstellt sie mehrere MCP-Clients. Jeder Client initiiert einen Handshake mit einem entsprechenden Server, um Informationen über unterstützte Funktionen und Protokollversionen auszutauschen. Dieser Handshake stellt sicher, dass beide Seiten kompatibel sind und effektiv miteinander kommunizieren können.
Nach der Initialisierung sendet jeder Client eine Discovery-Anfrage an seinen verbundenen Server, um festzustellen, welche spezifischen Funktionen verfügbar sind. Diese Funktionen können Werkzeuge, Ressourcen oder Eingabevorlagen umfassen. Der MCP-Server antwortet mit einer strukturierten Liste, die jedes dieser Elemente beschreibt, und der Client leitet diese Informationen an den Host weiter. Der MCP-Host kann diese Informationen anschließend interpretieren und für die Nutzung vorbereiten.
Sobald die Discovery abgeschlossen ist, übersetzt die Host-Anwendung die verfügbaren Funktionen in ein Format, das für die Interaktion mit einem LLM geeignet ist. Dies kann zum Beispiel das Parsen von Werkzeugdefinitionen in JSON-Schemas für Funktionsaufrufe beinhalten oder die Organisation von Ressourcen und Eingabevorlagen in einer Form, die das LLM während der Inferenz verwenden kann.
Flowchart of the MCP workflow: initialization, discovery, context provision, invocation, execution, and integration of responses.
Die Anwendung ist nun für die Interaktion mit dem Nutzer vorbereitet. Gibt ein Nutzer beispielsweise die Anfrage „Welche offenen Issues gibt es im HMS-GitHub-Repository?“ ein, analysiert das LLM die Anfrage und erkennt, dass es notwendig ist, ein bestimmtes Werkzeug aufzurufen oder auf eine Ressource zuzugreifen. Es identifiziert die passende Funktion, und der MCP-Host weist den entsprechenden Client an, eine Aufrufanfrage an den für dieses Werkzeug zuständigen Server zu senden.
Der MCP-Server erhält diesen Aufruf, zum Beispiel eine Anfrage „fetch_github_issues“ mit dem Parameter „HMS“, führt die zugrunde liegende Logik aus (z. B. einen API-Call zu GitHub) und verarbeitet das Ergebnis. Sobald die Operation abgeschlossen ist, sendet der Server die Antwortdaten zurück an den MCP-Client.
Der Client leitet dieses Ergebnis dann an den MCP-Host weiter, der die Informationen in den Kontext des LLM integriert. Jede weitere Verarbeitung des LLM erfolgt nun mit diesem erweiterten Kontext. Mithilfe der aktualisierten und relevanten Daten erzeugt das LLM eine Antwort, die sowohl sein internes Schlussfolgern als auch die neu abgerufenen externen Informationen widerspiegelt.
Ein solcher MCP-Flow ermöglicht es dem LLM, stets auf aktuelle Daten zurückzugreifen, spezialisierte Funktionen bei Bedarf zu nutzen und den Nutzern fundierte, aussagekräftige Antworten zu liefern. Die Trennung zwischen MCP-Host, -Client und -Server stellt dabei Modularität, Skalierbarkeit und Flexibilität sicher – sowohl bei der Bereitstellung als auch bei der Wartung verschiedener Werkzeuge in unterschiedlichen Umgebungen.
Wie jede leistungsstarke neue Technologie bringt auch MCP neue Sicherheitsherausforderungen mit sich, die aktuell noch adressiert werden. Da MCP-Server häufig über privilegierte Zugriffe (z. B. API-Keys, Datenbank-Zugangsdaten) oder sensible Daten verfügen, werden sie zu besonders attraktiven Angriffszielen.
Ein mögliches Angriffsszenario ist der Token-Diebstahl: Ein Angreifer, der einen MCP-Server kompromittiert, könnte OAuth-Tokens stehlen und sich so die sprichwörtlichen „Schlüssel zum Königreich“ verschaffen – also vollen Zugriff auf die E-Mails, Dateien und Cloud-Dienste eines Nutzers, ohne dass dabei übliche Anmeldewarnungen ausgelöst würden. Ein kompromittierter MCP-Server könnte außerdem unautorisierte Aktionen über alle verbundenen Accounts hinweg durchführen. Ebenso wäre es möglich, dass ein manipulierte*r MCP-Server nach der Installation seine Werkzeuge verändert: Ein scheinbar harmloses „Wetter“-Tool könnte sich z. B. selbstständig aktualisieren, um Daten zu exfiltrieren – sofern keine Versions- oder Integritätsprüfungen vorhanden sind.
Ein weiteres Risiko ist die sogenannte „Confused Deputy“-Autorisierung: Führt ein Server Aktionen im Namen des LLMs aus, muss sichergestellt sein, dass dies auch mit den richtigen Benutzerberechtigungen geschieht. Die aktuelle MCP-Spezifikation nutzt OAuth2.1 für die Remote-Authentifizierung. Allerdings wurde festgestellt, dass Teile der Spezifikation im Konflikt mit gängigen Enterprise-Best-Practices stehen können. Anthropic und die Community arbeiten bereits daran, die Spezifikation weiterzuentwickeln, um Autorisierung und Credential-Handling zu stärken.
Darüber hinaus bringt MCP neuartige, LLM-spezifische Angriffsvektoren mit sich. Ein Beispiel ist die Prompt Injection, die durch MCP noch gefährlicher wird: Gibt ein Nutzer (oder ein Angreifer) dem LLM einen bösartigen Prompt, könnte das System dazu gebracht werden, ungewollt Werkzeuge auszuführen. Selbst ohne böswillige Absicht könnte ein solcher Prompt unerwartete Handlungen auslösen – etwa das heimliche Hinzufügen eines zusätzlichen Benutzers in einem Cloud-Account (siehe entsprechender Vorfall).
Um diese Risiken abzumildern, gibt es mehrere empfohlene Best Practices:
Als Antwort auf diese Herausforderungen sieht die MCP-Roadmap die Einführung weiterer Features vor – darunter ein offizielles Register zur Auffindung und zentralen Verwaltung validierter Remote-Server, Governance-Mechanismen zur transparenten Nachverfolgung von Standards sowie Validierungstools für Test-Suites, um die Konformität zu prüfen. Diese Maßnahmen werden dazu beitragen, dass das Ökosystem mit Blick auf Sicherheit reift.
MCP definiert ein modulares Protokoll, das es LLM-Anwendungen ermöglicht, über eine strukturierte Host-Client-Server-Architektur mit externen Daten, Werkzeugen und Prompts zu interagieren. Hosts verwalten den Kontext und steuern die Ausführung, Clients übernehmen die Protokollkommunikation, und Server stellen die Funktionen bereit. Die MCP-Grundelemente (Ressourcen, Werkzeuge und Eingabevorlagen) unterstützen fundierte und erweiterbare LLM-Workflows, während zusätzliche Features wie Sampling und Elicitation dynamische Interaktionen ermöglichen.
Der Transport des Protokolls basiert auf JSON-RPC 2.0 mit Unterstützung für lokale und entfernte Server. Sicherheit bleibt ein aktives Entwicklungsfeld – insbesondere im Hinblick auf den Umgang mit Tokens, die Steuerung von Werkzeugaufrufen und den Schutz vor Prompt Injections. Zu den empfohlenen Best Practices gehören Sandboxing, Least-Privilege-Zugriff und Audit-Mechanismen.
Unternehmen, die MCP einsetzen möchten, sollten zunächst in kontrollierten Umgebungen experimentieren, bevor sie zu schnell in die Produktion gehen. Angesichts der laufenden Weiterentwicklung ist es wichtig, auf dem neuesten Stand zu bleiben, da neue Funktionen das Protokoll kontinuierlich leistungsfähiger und robuster machen. Für Entscheidungsträger und Architekten verdient MCP besondere Aufmerksamkeit, da es reale Herausforderungen bei der Einführung von LLMs adressiert.
Durch den Aufbau MCP-kompatibler Systeme können Unternehmen sicherstellen, dass ihre LLM-Anwendungen flexibel und zukunftssicher bleiben. Kurz gesagt: MCP soll das Rückgrat der nächsten Generation von LLM-basierten Systemen werden. Mit zunehmender Reife des Ökosystems entwickelt sich MCP zur Grundlage für sichere, modulare und agentische Anwendungen – sowohl in lokalen als auch in Cloud-Umgebungen.
Im nächsten Artikel der HMS-Serie zu MCP machen wir einen Reality Check: Sie erfahren, wie wir bei HMS MCP bereits einsetzen – um Prozesse zu optimieren, Kundenanwendungen umzusetzen oder zu erweitern und am Ende intelligentere Services zu liefern. Sie können sich auf praxisnahe Einblicke, Code-Beispiele und sogar einen Einblick in unser eigenes Code-Migrationstool sowie einige Kundenprojekte freuen.
Entdecken Sie erfolgreiche Umsetzungen in unseren Referenzen.
