MCP-Architektur: Vollständige technische Analyse mit Diagrammen

Die MCP-Architektur ist das grundlegende Gefüge aus Komponenten und Kommunikationsregeln, das MCP (Model Context Protocol) möglich macht. MCP ist ein Open-Source-Standard, und die MCP-Architektur ist die zugrunde liegende Infrastruktur, auf der er läuft.

Jede MCP-Architektur enthält drei Kernkomponenten und ist um diese herum aufgebaut: einen Host, einen Client und einen Server. Das Kommunikations-Framework von MCP wird oft so beschrieben, dass es aus einer Datenschicht und einer Transportschicht besteht. Die Datenschicht ist das Regelwerk dafür, wie Nachrichten formatiert werden (MCP-Anfragen werden in JSON-RPC 2.0 gesendet). Die Transportschicht überträgt diese Nachrichten und nutzt für externe Verbindungen Streaming HTTP.

Die MCP-Architektur ist ein Server-Framework, das das Model Context Protocol implementiert – einen offenen Standard zur Verbindung von KI-Modellen mit Tools, mit Ressourcen wie Datenbanken und mit Prompts, die den Eingabekontext erweitern. Diese werden zusammenfassend als „Primitive“ bezeichnet. Letztlich ermöglicht die MCP-Architektur LLMs, zu erkennen, welche Tools verfügbar sind, und Workflows auszuführen – ganz ohne regelmäßige Updates auf der Client-Seite.

Diagramm der MCP-Architektur: Eine KI-Anwendung tauscht Anfragen mit einem MCP-Server aus, der Tools, Ressourcen und Prompts bereitstellt.

Seit ihrer Einführung durch Anthropic hat sich die MCP-Architektur in KI-Workflows weit verbreitet. Das liegt vor allem daran, dass sie wartungsintensivere Systeme – etwa solche, die auf mehreren API-Verbindungen basieren – ersetzt, ohne dass die Leistung darunter leidet. Da sich alle verfügbaren Funktionen hinter dem MCP-Server befinden, ist nur eine einzige Verbindung erforderlich, und Updates sowie Erweiterungen stehen der Client-Anwendung sofort zur Verfügung.

MCP gibt LLMs die Möglichkeit, die ihnen verfügbaren Tools, Prompts und Ressourcen zu erkennen und aufzurufen – entweder auf dem lokalen System der Host-Anwendung oder bei einem externen Anbieter.

Bei Tools, die Zugriff auf externe Funktionen bieten, besteht die Erkennung darin, dass der Host einen tools/list-Aufruf an den MCP-Server sendet, um herauszufinden, welche Tools verfügbar sind. Das LLM (oder in manchen Fällen der Host) kann dann die Beschreibungen der verfügbaren Tools lesen und diese bei Bedarf anfordern. Bei Prompts und Ressourcen läuft es ähnlich ab.

Diagramm der Komponenten der MCP-Architektur: Ein Host mit einem LLM, einem Orchestrator und einem Client verbindet sich in zwei Schritten – erst Erkennung, dann Anfragen – mit einem MCP-Server, der Tools, Ressourcen und Prompts bereitstellt.

Dies steht im Gegensatz zu individuell entwickelten, API-basierten Architekturen, die in der Softwareentwicklung bislang die Norm waren: Funktionen außerhalb der App mussten dort über dedizierte Verbindungen mit exakt formatierten Anfragen aufgerufen werden.

Die Host-Anwendung ist die zentrale Orchestrierungsplattform und ist mit einem LLM verbunden. Bekannte Tools wie Perplexity und Claude Desktop können innerhalb eines MCP-Systems als Hosts fungieren.

In einem einfachen Workflow stellt der Nutzer über die Chat-Oberfläche eine Frage. Die Orchestrator-Komponente des Hosts ergänzt die Frage dann um Kontext und teilt dem LLM mit, welche MCP-Primitive verfügbar sind, zusammen mit einer Beschreibung ihrer Fähigkeiten.

Der Client ist eine Softwarekomponente in der KI-Anwendung. MCP stellt eine Standardschnittstelle bereit, über die der Client gemäß den Anweisungen des Hosts oder LLMs mit internen und externen MCP-Servern kommuniziert. Seine Aufgabe ist es, eine Verbindung herzustellen, JSON-RPC-Nachrichten zu formatieren, Anfragen zu senden und Antworten zu empfangen.

Die Begriffe „MCP-Host“ und „MCP-Client“ werden manchmal synonym verwendet. Die Unterscheidung ist jedoch sinnvoll, da ein Host wie Perplexity mehrere MCP-Clients gleichzeitig orchestrieren kann. Ein komplexer KI-Workflow kann Zugriff auf Dutzende oder sogar Hunderte separater MCP-Server erfordern, und jeder davon nutzt eine eigene Verbindung.

Diagramm eines MCP-Hosts wie Perplexity, der drei MCP-Clients orchestriert, die jeweils mit einem eigenen MCP-Server verbunden sind, etwa einer Datenbank, Dateien oder einer externen API.

Der Server stellt alle Tools bereit, die das KI-basierte Tool nutzen kann. Aus architektonischer Sicht interpretiert der MCP-Server die eingehende Anfrage und verbindet sich bei Bedarf mit den angeforderten Primitiven.

MCP-Server können Zugriff auf drei Kategorien von Primitiven bieten:

Tools: Dabei handelt es sich im Wesentlichen um externe Softwarefunktionen. Bei einem herkömmlichen API-basierten Ansatz könnte eine Webanalyse-Anwendung Daten etwa über eine formatierte Anfrage an einen externen Server abrufen. In der MCP-Architektur sind alle Drittanbieterfunktionen eines Anbieters über eine einzige Verbindung verfügbar, und Anfragen werden nach standardisierten Formatierungsregeln erstellt.
Ressourcen: Ressourcen sind Datenquellen, die schreibgeschützten Kontext liefern. Datenbankschemas sind ein gutes Beispiel. Der MCP-Server stellt die verschiedenen Informationsquellen bereit, die dem Host zur Verfügung stehen. Wenn der Host die Datenbank abfragt, etwa mit einer von einem LLM generierten SQL-Suche, gilt dies als Tool-Anfrage.
Prompts: Dabei handelt es sich um wiederverwendbare Prompt-Vorlagen, die LLMs bei der Ausführung bestimmter Aufgaben unterstützen. Ein Nutzer oder Host ruft einen Prompt statt eines Tools auf, wenn für die Erledigung einer Aufgabe vorgefertigte Anweisungen benötigt werden. Häufig werden voreingestellte Aufgaben in einer Host-Anwendung, etwa die Optionen „Code prüfen“ oder „Daten analysieren“, als Prompts gespeichert, die der Nutzer auswählen kann.

Erwähnenswert ist auch, dass sich MCP und API als Technologien nicht gegenseitig ausschließen. Der MCP-Server kann API-Aufrufe bereitstellen, die als Antwort auf eine Erkennungsanfrage verfügbar sind. Entscheidend ist, dass deren Pflege dem MCP-Anbieter obliegt, nicht dem Client.

Die Datenschicht in der MCP-Architektur ist das Regelwerk, das festlegt, wie Anfragen, Antworten und Benachrichtigungen formatiert werden. Die Standardsprache für Nachrichten ist JSON-RPC.

Jede MCP-Architektur folgt einem grundlegenden Ablauf: (1) Initialisierung und Erkennung durch den Host, (2) Antwort des MCP-Servers und (3) ein Aufruf durch den Host (manchmal vom LLM entschieden), wobei jede Phase einer separaten JSON-Nachricht entspricht.

Diagramm der MCP-Datenschicht: Ein Nutzer sendet einen Prompt an die Host-Anwendung, in der das LLM mit dem MCP-Client zusammenarbeitet; der Client sendet eine Anfrage an den MCP-Server (Tools, Ressourcen, Prompts) und erhält ein Ergebnis, und der Host gibt eine Antwort an den Nutzer zurück.

Sehen wir uns anhand von zwei Beispielen an, wie die Tool-Erkennung funktioniert (dies kann ebenso für Ressourcen oder Prompts gelten):

Tools vor der LLM-Generierung erkennen: Der Host initialisiert den MCP-Client, der eine tools/list-Anfrage sendet (die Liste der verfügbaren Tools des MCP-Servers). Das LLM prüft diese während des Generierungsprozesses und entscheidet, ob ein bestimmtes Tool, eine Ressource oder ein Prompt benötigt wird.
Dem LLM die Option zur Suche geben: In einem agentischen System fügt der Host der Kontexteingabe eine Erkennungsoption hinzu, etwa search-tools, und das LLM kann bei Bedarf eine Suche anfordern.

Tools, bei denen es sich größtenteils um Funktionen externer Anwendungen handelt, werden in der Regel vom LLM oder Host ausgewählt. Ressourcen und Prompts werden meist auf Veranlassung des Nutzers oder durch den Host angefordert.

So sieht eine tools/list-Anfrage einer fiktiven Notizen-Anwendung an einen MCP-Server aus:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

In diesem Beispiel identifiziert “id”:101 die Anfrage über eine ID, damit der Client Antworten zuordnen kann, und das Feld “params” enthält zusätzliche Informationen über den Client, etwa den Client-Namen (notes-app-client) und seine Fähigkeiten.

Als Antwort gibt der MCP-Server Tool-Definitionen zurück, die die Namen der verfügbaren Tools und die zugehörigen Details enthalten. Die Liste könnte beispielsweise ein add-task-Tool enthalten, mit dem die Notizen-Anwendung Aufgaben in einer verbundenen Aufgabenverwaltungs- oder Kalenderanwendung erstellen und jeder Aufgabe einen Titel und eine Priorität zuweisen kann.

So könnte eine Anfrage aussehen:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Das Feld “method” teilt dem MCP-Server mit, dass es sich um einen Tool-Aufruf handelt, “name” gibt an, welches Tool aufgerufen werden soll, und “arguments” liefert die erforderlichen Eingaben.

Wenn die Datenschicht das Was der Verbindung zwischen einem Client und einem MCP-Server ist, dann ist die Transportschicht das Wie. Sie legt fest, auf welche Weise Nachrichten übertragen werden: den konkreten Kanal und die Regeln dafür, wie Anfragen und Antworten zugestellt werden.

MCP verfügt über zwei Transportwege:

Standardeingabe/-ausgabe: Dieser Weg wird genutzt, wenn der MCP-Server in derselben lokalen Umgebung wie die Host-App läuft. Der Client schreibt die JSON-Anfrage in die Standardeingabe des Servers. Der Server liest sie, führt den angeforderten Vorgang aus und schreibt die Antwort in die Standardausgabe.
Streamable HTTP: Wenn der MCP-Server außerhalb der Host-Anwendung läuft, sendet der MCP-Client Anfragen per HTTP POST an den Server. Der Server antwortet entweder mit einer einzelnen JSON-Nachricht oder mit einem Server-Sent Events (SSE)-Stream – einem dauerhaft offenen „Empfangskanal“, über den er im Laufe der Zeit mehrere Nachrichten zurückgeben kann.

Eine mandantenfähige MCP-Architektur ist eine Implementierungsform, die mehrere Nutzer (Mandanten) gleichzeitig bedienen kann.

Ein Mandant kann dabei eine Einzelperson, eine Gruppe von Personen oder eine Organisation sein. Die Implementierung kann vorsehen, für jeden Mandanten einen separaten MCP-Server zu betreiben, Zugriff auf einen einzigen gemeinsam genutzten Server zu gewähren oder eine Gruppe von Servern hinter einem zentralen Gateway zu platzieren. Wird ein Gateway verwendet, leitet es Anfragen anhand der Identität des Nutzers oder der Art der Anfrage an die richtigen Endpunkte weiter.

Sie funktioniert nach demselben Grundprinzip wie die Standard-MCP-Architektur, allerdings laufen einzelne Nutzeranfragen in einem eigenen Arbeitsbereich (auch wenn dabei gemeinsam genutzte Ressourcen zum Einsatz kommen) und werden separat authentifiziert. Dies ist in Unternehmensszenarien üblich, und gemeinsam genutzte Ressourcen werden oft bevorzugt, weil der Betrieb mehrerer MCP-Server unnötig kostspielig wäre.

Wie sieht eine durchgängige MCP-Anfrage in der Praxis aus? Es gibt acht zentrale Phasen, an denen jeweils eine eigene Architekturkomponente beteiligt ist.

Flussdiagramm einer durchgängigen MCP-Anfrage in acht Schritten: Tool-Erkennung, Nutzereingabe, Modellverarbeitung, Tool-Auswahl, Anfrage, Tool-Ausführung, Ergebnis und Antwortgenerierung.

So sieht ein MCP-Tool-Aufruf in der Praxis aus – anhand des vorherigen Beispiels einer Notizen-Anwendung, die mit einem Aufgabenverwaltungsdienst verbunden ist:

Tool-Erkennung: Die Notizen-Anwendung (Host) nutzt ihren MCP-Client, um die verfügbaren Tools des Servers über eine tools/list-Anfrage abzurufen. Der Server gibt deren Namen, Beschreibungen und erwartete Eingaben zurück, auch die für das Tool add-task. Dies kann geschehen, bevor Sie einen Prompt absenden.
Nutzereingabe: Sie senden über den In-App-Chatbot eine Anfrage an die LLM-basierte Notizen-Anwendung, etwa: „Erstelle in meinem Kalender eine Aufgabe mit mittlerer Priorität, um meinen neuen Entwurf zu prüfen.“
Modellverarbeitung: Der Host sendet Ihre Anfrage und die relevanten Tool-Definitionen an das LLM.
Tool-Auswahl: Das LLM generiert eine strukturierte Tool-Anfrage, die das Tool und seine Eingaben angibt: add-task mit title: Entwurf prüfen und priority: Medium. Der Host prüft, ob die Aktion zulässig ist, und übergibt die Anfrage an den MCP-Client, der eine JSON-RPC-Nachricht sendet.
Anfrage: Der MCP-Client sendet eine tools/call-Anfrage an seinen MCP-Server.
Tool-Ausführung: Der MCP-Server ruft die API der Aufgabenverwaltungsanwendung auf, um eine neue Aufgabe mit dem angegebenen Titel und der angegebenen Priorität zu erstellen.
Rückgabe des Ergebnisses: Der Server sendet das Ergebnis an den MCP-Client zurück, der es an den Host weitergibt. Der Host fügt es den Informationen hinzu, die dem LLM bereitgestellt werden.
Antwortgenerierung: Das LLM nutzt das Ergebnis, um eine Antwort für den Nutzer zu generieren, etwa: „Ich habe eine Aufgabe mit mittlerer Priorität erstellt, um den Entwurf zu prüfen.“

MCP und herkömmliche API-Architektur werden oft verwechselt, sind aber sich ergänzende Technologien. MCP wurde speziell für KI-basierte Anwendungen entwickelt. Es beseitigt den hohen Wartungsaufwand, den die Implementierung und Verwaltung mehrerer fest codierter API-Verbindungen mit sich bringt.

Indem MCP einer Host-Anwendung eine einzige Verbindung pro Funktionsanbieter oder interner Ressource bereitstellt, hilft es, das Problem aufgeblähter Kontexteingaben (Auflistung aller APIs) oder eingeschränkter API-basierter Anwendungsskripte zu beheben.

Stattdessen können MCPs APIs (oder vielmehr die Funktionen, die APIs aufrufen) als Teil ihrer Tool-Liste bereitstellen. Wenn ein Anbieter seine App aktualisiert und eine neue API hinzukommt oder sich die Dokumentation ändert, aktualisiert er einfach den MCP-Server. Auf Seiten der Host-App sind keine Codeänderungen erforderlich.

Die Sicherheit von MCP wird seit seiner Einführung intensiv diskutiert. Zwar gilt MCP allgemein als sichere Technologie, doch es gibt mehrere Sicherheitsrisiken, von denen viele in komplexen Architekturimplementierungen stärker zum Tragen kommen.

Die MCP-Architektur weist folgende potenzielle Schwachstellen auf:

Prompt-Injection: Ein Nutzer fügt einen bösartigen Prompt in externe Daten ein, den das KI-Modell fälschlicherweise als Anweisung interpretiert.
Zu weitreichende Zugriffsrechte: MCP-Server können einem KI-Modell potenziell eine große Zahl von Tools bereitstellen, was das Potenzial für Sicherheitsprobleme (den Schadensradius) vergrößern kann.
Unbeabsichtigte Datenlecks: Schlecht konfigurierte Implementierungen können dazu führen, dass sensible Informationen wie API-Schlüssel oder Datenbank-Anmeldedaten an ein LLM weitergegeben werden.
Manipulation des lokalen Systems: Lokale MCP-Server sind ebenso anfällig für Probleme des lokalen Systems, etwa bösartige Skripte, wie jede andere Anwendung – mit dem zusätzlichen Problem, dass sie nachgelagert schädliche Auswirkungen auf agentische KI-Systeme haben können.

Keines dieser Probleme ist unüberwindbar. Oft genügen etablierte Maßnahmen, um die Sicherheit des Systems zu gewährleisten. Maßnahmen wie die Einbindung eines Menschen in den Ablauf (Human in the Loop), strenge Kontrollen rund um sensible Daten und der Schutz vor Serverangriffen sind gängige Praxis.

MCP hat sich als nützlicher und beliebter offener Standard für Entwickler erwiesen. Es löst viele Probleme fest codierter APIs in LLM-basierten Anwendungen und verringert den Programmieraufwand für Entwickler erheblich.

Künftig wird die zugrunde liegende Host- und Serverarchitektur von MCP mit ziemlicher Sicherheit gleich bleiben. Zukünftige Innovationen werden sich auf fortschrittliche agentische Fähigkeiten in mehrstufigen Workflows konzentrieren.

Darüber hinaus werden stärkere Sicherheitsvorkehrungen nötig sein, wenn diese agentischen Funktionen implementiert werden, ebenso wie eine skalierbare Architektur – insbesondere in der Transportschicht –, da KI-Systeme immer umfangreicher und komplexer werden.

Was ist die MCP-Architektur?

Komponenten der MCP-Architektur: Hosts, Clients und Server

Host

Client

Server

Was ist die Datenschicht in der MCP-Architektur?

Was ist die Transportschicht in der MCP-Architektur?

Was ist eine mandantenfähige MCP-Architektur?

Diagramm der MCP-Architektur: Schritt-für-Schritt-Durchlauf

Wie unterscheidet sich die MCP-Architektur von herkömmlicher API-Architektur?

Ist die MCP-Architektur sicher?

Wie geht es mit der MCP-Architektur weiter?