Wenn Sie nach „model context protocol architecture diagram“ gesucht haben, in der Hoffnung, etwas zu finden, das Sie tatsächlich auf einem Whiteboard skizzieren und Ihrem Team erklären können, sind Sie hier richtig. Die meisten Erklärungen zu MCP bleiben entweder bei „es verbindet KI mit Tools“ stehen oder tauchen direkt in Spezifikationsdetails ein, ohne die grundlegende Architekturfrage zu beantworten: Was kommuniziert mit was, in welcher Reihenfolge und wer ist wofür verantwortlich?
Dieser Artikel vermittelt Ihnen das Bild auf Implementierungsebene. Nicht nur Definitionen.
Was die meisten Teams erst nach dem Go-live lernen
- MCP liegt über APIs – es standardisiert, wie LLMs diese entdecken und aufrufen, ersetzt sie jedoch nicht.
- Die offene Client-Server-Architektur bedeutet, dass ein Host mehrere Clients ausführen kann, die jeweils unabhängig mit einem anderen Server verbunden sind.
- MCP definiert die Integrationsschnittstelle; Zugriffskontrolle, Data Governance und Sicherheit müssen Sie selbst implementieren.
Was das Model Context Protocol ist und warum Anthropic es eingeführt hat
Das Model Context Protocol ist ein offenes Protokoll, das Anthropic im November 2024 eingeführt hat. Die Definition in der offiziellen Spezifikation ist präzise: MCP ist eine standardisierte Methode für KI-Anwendungen, über eine konsistente Schnittstelle externe Datenquellen, Tools und Systeme anzubinden, statt für jede Verbindung eine individuelle Integration zu entwickeln.
Dieser letzte Teil ist entscheidend. Vor MCP schrieb jedes Team, das ein LLM mit einem Tool verband, einen eigenen Adapter. Unterschiedliche Struktur, unterschiedliche Authentifizierungsmethoden, unterschiedliche Fehlerbehandlung. Hochgerechnet auf Dutzende Tools erhalten Sie Dutzende individuelle Integrationen, die jeweils separat gewartet werden müssen. Der MCP-Standard wurde geschaffen, um dies auf eine einheitliche Protokollstruktur zu reduzieren.
Anthropic hat MCP eingeführt, aber es ist kein exklusives Anthropic-Produkt. Die MCP-Spezifikation ist offen, wird öffentlich gepflegt und bereits in IDEs, Coding-Assistenten, KI-Plattformen und Enterprise-Agent-Stacks eingesetzt. Bis zum ersten Quartal 2026 identifizierte die Karte des Protokollökosystems von DigitalApplied MCP neben A2A, ACP und UCP als vier eigenständige Protokolle mit relevanter Branchenakzeptanz – das bedeutet, MCP ist längst keine experimentelle Kuriosität mehr. Es gehört dazu, wie produktive Agentensysteme tatsächlich entwickelt werden.
Das Model Context Protocol ermöglicht jeder konformen KI-Anwendung, ohne individuelle Integration pro Paar auf jedes konforme Tool oder jede konforme Datenquelle zuzugreifen. Das ist das gesamte Wertversprechen. Alles andere folgt daraus.
Das Client-Server-Modell hinter der MCP-Architektur
Die offizielle MCP-Spezifikation beschreibt eine Client-Host-Server-Architektur, bei der jeder Host mehrere Client-Instanzen ausführen kann. Vier Komponenten. Jede mit einer klar eigenen Rolle.
Hier entsteht häufig Verwirrung: Die Begriffe „Client“ und „Server“ haben in MCP eine spezifische Bedeutung, die nicht immer der Verwendung dieser Wörter in allgemeinen Netzwerken entspricht. Und „Host“ ist wiederum etwas Drittes und nicht lediglich ein anderes Wort für Server. Lassen Sie uns die Begriffe aufschlüsseln, damit Sie das Diagramm tatsächlich zeichnen können.
MCP-Host: Die Anwendung, die das LLM ausführt
Der MCP-Host ist die Anwendung, die das Large Language Model einbettet oder ausführt und den gesamten Prozess startet. Denken Sie an Claude Desktop, Cursor oder eine benutzerdefinierte KI-Anwendung, die Ihr Team entwickelt hat. Der Host ist das, womit Benutzer tatsächlich interagieren.
Der Host ist außerdem für Zugriffskontrolle und Data Governance verantwortlich. Dieses Detail wird ständig übersehen, ist aber im Produktivbetrieb entscheidend. MCP sichert nicht automatisch alles ab. Der Host entscheidet, welche Server verbunden werden dürfen, auf welchen Datenumfang jeder Client zugreifen kann und wer berechtigt ist, welche Tools aufzurufen. Wenn Sie eine KI-Anwendung bereitstellen, die sensible Systeme berührt, und diese Ebene nicht durchdacht haben, haben Sie eine Governance-Lücke in Produktion gebracht.
Ein Host, mehrere Clients. Das ist das Muster.
MCP-Client: Der Eins-zu-eins-Konnektor innerhalb des Hosts
Jeder MCP-Client befindet sich innerhalb des Hosts und unterhält eine Eins-zu-eins-Verbindung mit einem einzelnen MCP-Server. Ein Client, ein Server. Das ist die Einschränkung.
Ein einzelner Host kann jedoch gleichzeitig mehrere Clients starten, die jeweils auf einen anderen Server verweisen. Wenn Ihr Host also gleichzeitig mit einem Datenbankserver, einem GitHub-Server und einem internen Ticketsystemserver kommunizieren muss, führt er drei Clients aus. Jeder Client verwaltet seinen eigenen Verbindungslebenszyklus, verarbeitet seinen eigenen Sitzungsstatus und kommuniziert unabhängig mit dem jeweiligen Server.
Die Unterscheidung zwischen Server und Client ist hier wichtig: Der Client ist nicht das benutzerseitige Element. Er ist die Konnektorebene innerhalb des Hosts. Wenn Sie beide als austauschbar behandeln, werden Diagramme schnell falsch.
Die praktische Checkliste vor der Einrichtung:
- Prüfen Sie, ob die Host-Anwendung mehrere gleichzeitige Client-Verbindungen unterstützt.
- Jedes Client-Server-Paar benötigt eine eigene Authentifizierungskonfiguration.
- Der Client-Lebenszyklus (Start, Beenden, Fehlerbehandlung) wird vom Host verwaltet.
- Fällt ein Server aus, ist nur der mit ihm verbundene Client betroffen, nicht der gesamte Host.
MCP-Server: Tools, Ressourcen und Prompts bereitstellen
Der MCP-Server ist der unabhängige Prozess, der dem Client Funktionen bereitstellt. Er ist das, was Ihr Team entwickelt – oder aus einer vorhandenen Bibliothek von MCP-Server-Implementierungen übernimmt –, wenn Sie einem LLM Zugriff auf eine Datenquelle oder ein internes Tool geben möchten.
Ein Server stellt drei Arten von Funktionen bereit, sogenannte Primitives: Tools, Ressourcen und Prompts. Alle drei behandeln wir im nächsten Abschnitt.
Der Server läuft unabhängig vom Host. Er muss nichts darüber wissen, welcher Host oder Client sich mit ihm verbindet. Diese Unabhängigkeit macht das Ökosystem kombinierbar: Sie können einen Server für Ihre interne Confluence-Instanz entwickeln, und jeder konforme MCP-Host kann sich damit verbinden. Kein individueller Konnektor pro KI-Anwendung. Der Server stellt lediglich seine Funktionen bereit; der Client entdeckt sie.
Aus Sicht der Implementierungsentscheidung findet hier die eigentliche Arbeit statt. Wenn Teams fragen: „Wie verbinden wir unseren KI-Assistenten mit unseren internen Tools?“, lautet die Antwort: Sie entwickeln oder übernehmen für jedes Tool einen MCP-Server. Die Datenquellen, auf die Ihr LLM zugreifen muss, werden als serverseitige Ressourcen und Tools gekapselt.
MCP-Primitives: Tools, Ressourcen und Prompts erklärt
Die MCP-Spezifikation definiert drei Arten von Funktionen, die Server für Clients bereitstellen. Sie werden Primitives genannt und machen MCP über eine allgemeine Protokolldefinition hinaus nützlich. Jede erfüllt einen anderen Zweck.
Wenn Sie alle drei verstehen, können Sie von „MCP verbindet KI mit Tools“ zu „das stellt unser Server tatsächlich bereit – und deshalb“ übergehen.
Tools und Function Calling in MCP
MCP-Tools sind ausführbare Funktionen, die das LLM über den Client aufrufen kann. Wenn Sie mit Function Calling in der API von OpenAI gearbeitet haben, kennen Sie das Muster: Sie beschreiben eine Funktion, das Large Language Model entscheidet, wann es sie aufrufen soll, und sie wird mit konkreten Argumenten ausgeführt.
MCP standardisiert, wie KI-Modelle diese Funktionen über unterschiedliche Server hinweg entdecken. Ohne MCP hat jeder Server seine eigene Struktur für die Erkennung. Mit MCP fordert der Client den Server im gleichen Anfrageformat auf, seine verfügbaren Tools aufzulisten – unabhängig davon, um welchen Server es sich handelt. Das LLM sieht ein konsistentes Tool-Schema, egal wie viele Server beteiligt sind.
Ein praktisches Beispiel: Ein Server für GitHub stellt Tools wie search_repository, get_file_contents und create_pull_request bereit. Das LLM kann all diese Tools erkennen, ihre Parameter verstehen und sie über den Client ausführen, ohne dass auf Host-Seite eine individuelle Integration erforderlich ist. Der Server hinterlegt diese Tools mit API-Aufrufen an GitHub. MCP liegt über diesen APIs; es ersetzt sie nicht.
Das MCP-Protokoll verarbeitet außerdem, was geschieht, wenn ein Tool-Aufruf fehlschlägt, rate-limitiert wird oder eine unerwartete Antwort liefert. Dieser Lebenszyklus liegt auf der Protokollebene, sodass das LLM ihn nicht direkt verwalten muss.
Datenzugriff über MCP-Ressourcen
Ressourcen sind der Mechanismus, mit dem MCP-Server strukturierte oder unstrukturierte Daten für den Client bereitstellen. Während Tools Aktionen ausführen, liefern Ressourcen Kontext. Ein Tool könnte eine Datenbankabfrage ausführen; eine Ressource stellt das Schema bereit, damit das LLM relevanten Kontext erhalten kann, bevor es entscheidet, was abgefragt werden soll, oder Daten direkt in seine Schlussfolgerungen einbeziehen kann.
Ressourcen können Dokumente, Datenbankeinträge, Dateiinhalte, Analyseergebnisse oder alles andere sein, was dem LLM nützliche Informationen liefert. Der Client ruft sie ab und der Server gibt die Daten in einem standardisierten Format zurück.
Das ist für Teams wichtig, die LLM-Anwendungen an bestehende Datenquellen anbinden. Statt für jede Datenquelle individuelle Retrieval-Logik zu schreiben, kapseln Sie die Quelle in einem MCP-Server und stellen die relevanten Daten als Ressourcen bereit. Das LLM kann sie abfragen, ohne etwas über das zugrunde liegende Speichersystem wissen zu müssen.
Transportschicht: Wie STDIO und HTTP+SSE Nachrichten zwischen Client und Server übertragen
Die Transportschicht ist der Kommunikationskanal zwischen MCP-Client und Server. Die MCP-Spezifikation verwendet JSON-RPC 2.0 als Nachrichtenformat für alle Transportschichten. Dadurch bleibt die Struktur von Anfragen und Antworten konsistent, unabhängig davon, welche Transportschicht Sie wählen.
Im Kernprotokoll sind zwei Transportschichten definiert: STDIO und HTTP mit Server-Sent Events.
STDIO ist der lokale Transport. Der Host startet den MCP-Server als Unterprozess, und Client sowie Server kommunizieren über Standard-Eingabe- und -Ausgabeströme. Das ist typisch für lokale MCP-Bereitstellungen, bei denen der Server auf demselben Rechner wie der Host läuft. Die meisten IDE-Integrationen (Cursor, VS Code-Erweiterungen) verwenden STDIO, da der Server ein lokaler Prozess ist. Die Einrichtung ist einfach; es gibt keine Netzwerkschnittstelle, um die Sie sich kümmern müssen.
HTTP+SSE ist der Remote-Transport. Der Server läuft als separater Prozess, möglicherweise auf einem anderen Rechner oder in einer anderen Umgebung, und die Kommunikation zwischen MCP-Client und Server erfolgt über HTTP. Server-Sent Events verarbeiten die Nachrichtenrichtung vom Server zum Client, während der Client Nachrichten über reguläre HTTP-POST-Anfragen sendet. Dies verwenden Sie, wenn der Server remote gehostet wird, von mehreren Hosts gemeinsam genutzt wird oder als Service bereitgestellt ist.
Die Protokollversionen für beide sind in der Spezifikation definiert, und die beiden Transportschichten sind zur Laufzeit nicht austauschbar. Sie wählen eine bei der Bereitstellung, und diese Entscheidung hat Folgen.
| Anwendungsfall | Transport | Warum |
|---|---|---|
| Lokaler Unterprozess (IDE-Plugin, Desktop-App) | STDIO | Gleicher Rechner, geringer Overhead, keine Netzwerkfreigabe |
| Gemeinsamer Remote-Server (teamweiter Zugriff) | HTTP+SSE | Rechnerübergreifend, von mehreren Hosts zugänglich |
| In der Cloud bereitgestellter Server | HTTP+SSE | Von Natur aus über das Netzwerk erreichbar |
| Entwicklung/Tests auf lokalem Rechner | STDIO | Einfachste Einrichtung, keine Authentifizierungskonfiguration erforderlich |
🤔 Moment.
Die Transportauswahl wirkt wie eine Konnektivitätspräferenz. Tatsächlich ist sie eine Entscheidung über Architekturgrenzen. STDIO bedeutet, dass Ihr Server auf dem MCP-Host-Rechner läuft – das definiert Ihr Bereitstellungsmodell, Ihren Sicherheitsperimeter und ob der Server mit anderen Hosts geteilt werden kann. HTTP+SSE bedeutet, dass Ihr Server über das Netzwerk erreichbar ist – damit entstehen völlig andere Governance-Fragen. Die „einfache“ Wahl bringt architektonische Festlegungen mit sich.
Wie sich die MCP-Architektur mit einer direkten API-Integration vergleichen lässt
Das hartnäckigste Missverständnis, das ich sehe: MCP ersetze APIs. Das tut es nicht. Lassen Sie mich klar sagen, was es tatsächlich macht.
MCP ist eine Standardprotokollebene, die über APIs liegt. Wenn ein MCP-Server ein Tool wie search_database bereitstellt, wird dieses Tool durch einen API-Aufruf unterstützt – oder durch eine Datenbankabfrage oder das Lesen einer Datei. MCP standardisiert, wie das LLM das Tool entdeckt und aufruft. Die zugrunde liegende API existiert weiterhin. MCP stellt lediglich eine konsistente Schnittstelle bereit, um sie aufzurufen.
Die für mich passende Analogie ist das Language Server Protocol, das von jedem großen Code-Editor verwendet wird. LSP standardisierte, wie Editoren mit Tools zur Sprachanalyse kommunizieren. Vor LSP entwickelte jeder Editor individuelle Integrationen mit jedem Language Server. Nach LSP kann jeder konforme Editor mit jedem konformen Language Server verbunden werden. MCP folgt demselben Muster für KI-Anwendungen und externe Tools.
Das Problem der Verbindung von KI-Systemen, das MCP löst, wird manchmal als N×M-Integrationsproblem bezeichnet. Ohne Standardprotokoll erfordern N KI-Anwendungen, die mit M Tools verbunden werden, bis zu N×M individuelle Konnektoren. Mit einem MCP-Standard implementiert jede KI-Anwendung MCP einmal – auf Client-Seite –, jedes Tool implementiert MCP einmal – auf Server-Seite –, und jedes konforme Paar kann sich verbinden.
📊 In der Praxis:
Ohne MCP bedeuten fünf interne Tools, die Sie mit KI-Assistenten verbinden möchten, fünf individuelle Integrationsschichten – jede mit eigener Authentifizierung, Fehlerbehandlung und Erkennungslogik –, die separat gepflegt werden müssen, sobald sich eines der fünf Tools ändert. Mit MCP verbindet sich ein einzelner konformer Client im Host über dasselbe Protokoll mit allen fünf Servern. Wenn ein Server sein Tool-Schema aktualisiert, erkennt der Client die Änderung über den standardisierten Ablauf zur Funktionsaushandlung und nicht über ein maßgeschneidertes Adapter-Update.
Die externen Systeme, die Ihr LLM benötigt – Datenbanken, APIs, Dateispeicher und interne Dienste –, verschwinden nicht hinter MCP. Sie sind weiterhin vorhanden. MCP verhindert lediglich, dass Sie für jede KI-Anwendung, die diese Systeme erreichen muss, einen eigenen Konnektor schreiben.
Wo die MCP-Architektur in agentische KI-Workflows passt
Hier ist ein weiteres Missverständnis, das direkt angesprochen werden sollte: MCP ist kein Agent-Framework.
Ein agentisches System benötigt mindestens eine Planungsebene – etwas, das entscheidet, was als Nächstes zu tun ist –, eine Speicher- oder Kontextverwaltungsebene – etwas, das verfolgt, was geschehen ist –, und eine Tool-Zugriffsebene – etwas, das für Aktionen externe Systeme anbindet. MCP übernimmt die dritte Ebene. Die ersten beiden übernimmt es nicht.
Bei der Entwicklung von KI-Agenten ist das Agent-Framework über MCP für die Logik verantwortlich: Welches Ziel wird verfolgt, welche Schritte werden unternommen, wann wird erneut versucht, wann wird abgebrochen und wie wird der Kontext über mehrere Interaktionen hinweg verwaltet? MCP regelt, wie auf diese Tools und Datenquellen zugegriffen wird, sobald das Framework entschieden hat, sie zu nutzen.
Die Beziehung lautet: Agentische Systeme nutzen MCP, um Tools zu erreichen; MCP dient nicht dazu, Agenten auszuführen.
Diese Unterscheidung ist bei der Entwicklung agentischer Systeme wichtig. Wenn sich Ihr Workflow fehlerhaft verhält, müssen Sie wissen, ob das Problem in der Agentenlogik liegt – falsche Entscheidung, falsches Ziel, falsche Kontextverwaltung – oder in der Tool-Zugriffsebene – falscher Server, fehlgeschlagener Aufruf, falscher Parameter. Wenn Sie beides miteinander vermischt haben, wird die Diagnose deutlich schwieriger.
In der Praxis liegt der Workflow im Stack über MCP. Das Agent-Framework entscheidet, wann ein Tool aufgerufen wird; MCP übernimmt, wie dieser Aufruf ausgeführt wird und wie die Antwort zurückkommt. Kontextsensitives KI-Verhalten setzt voraus, dass das Agent-Framework den Kontext verwaltet; MCP stellt lediglich den Mechanismus bereit, zusätzlichen Kontext abzurufen, wenn das Framework ihn anfordert.
Ein konkretes Beispiel: Ein Team für Entwickler-Tools in einem mittelgroßen Engineering-Unternehmen wollte, dass sein KI-Coding-Assistent interne Code-Repositories durchsucht, CI/CD-Läufe auslöst und Incident-Tickets erstellt, ohne die IDE zu verlassen. Das Team entwickelte drei MCP-Server – einen pro Tool –, die jeweils relevante Tools und Ressourcen bereitstellen, und verband sie über die Client-Ebene mit dem IDE-Host. Die KI-Systeme in der IDE rufen diese Tools nun auf. Die Logik, die bestimmt, wann ein CI-Lauf ausgelöst und wann nur eine Warnung angezeigt wird, befindet sich jedoch im Agent-Framework über allem anderen. Die Kommunikation zwischen KI-Komponenten und Servern ist die Aufgabe von MCP. Die Überlegung, was zu tun ist, nicht.
Wenn Sie Latenodes AI Agent Builder und MCP Server Builder zusammen verwenden, wird diese Aufteilung im Canvas sichtbar: Der MCP-Server stellt bereit, welche Tools verfügbar sind, und der Agenten-Workflow entscheidet, wann diese aufgerufen werden. Diese Trennung ist nicht nur saubere Architektur in einem Diagramm – sie ermöglicht das Debugging, wenn der Agent eine falsche Entscheidung trifft.
Sicherheits- und Governance-Verantwortlichkeiten in einer MCP-Bereitstellung
MCP definiert die Integrationsschnittstelle. Es implementiert nicht Ihre Sicherheitsrichtlinie. Teams, die MCP-verbundene Systeme bereitstellen und erwarten, dass das Protokoll die Zugriffskontrolle übernimmt, stellen dies in der Produktion fest – meist zu einem ungünstigen Zeitpunkt.
Diese Verantwortlichkeiten liegen bei Ihrer Implementierung, nicht bei MCP selbst:
- Durchsetzung der Zugriffskontrolle (Host)
Der Host entscheidet, mit welchen MCP-Servern sich jeder Client verbinden darf und welchen Umfang jede Verbindung erhalten darf. MCP bietet keinen integrierten Mechanismus, um zu verhindern, dass sich ein Client mit einem Server verbindet, den er nicht erreichen sollte. Die KI-Anwendung muss diese Prüfung ausdrücklich implementieren, bevor sie einen Client startet.
- Datenbeschränkung pro Tool und Ressource (Server)
Der Server ist dafür verantwortlich, nur Daten zurückzugeben, die der Anfragende sehen darf. Wenn Ihr MCP-Server eine Datenbank kapselt und ein Client eine Ressourcenabfrage sendet, muss der Server Zugriffsrechte auf Zeilen- oder Schemaebene durchsetzen, bevor er Ergebnisse zurückgibt. Das Sprachmodell und die Client-Ebene können nicht erkennen, ob die zurückgegebenen Daten angemessen eingeschränkt wurden.
- Verwaltung des Authentifizierungslebenszyklus (Host und Server)
OAuth-Tokens, API-Schlüssel und Service-Credentials laufen ab. Der Host muss die Token-Aktualisierung für Clients verwalten, und der Server muss die Authentifizierung bei jeder Anfrage validieren, nicht nur beim Verbindungsaufbau. Ein häufiges Fehlermuster: Die Authentifizierung funktioniert beim Start, gerät unbemerkt aus dem Takt und liefert Stunden später 401-Fehler zurück. Das Dashboard sieht oft weiterhin normal aus, bis jemand feststellt, dass keine Daten mehr fließen.
- Audit-Protokollierung (Host und Server)
MCP enthält keinen integrierten Audit-Trail. Wenn Sie nachvollziehen müssen, welche Tools mit welchen Argumenten von welchem Client aufgerufen wurden und was zurückgegeben wurde, müssen Sie diese Protokollierung selbst entwickeln – sowohl auf Server-Seite für Tool-Aufrufe als auch auf Host-Seite für Sitzungsereignisse.
- Server-Isolation (Server)
Jeder MCP-Server sollte unabhängig mit eigenen Credentials und einem eigenen Zugriffsbereich arbeiten. Ein Server mit weitreichenden Berechtigungen, der kompromittiert wird, legt alles in diesem Bereich offen. Wenn eine Abfrage auf einem Server fehlschlägt, sollte dies nicht auf andere Server übergreifen. Isolation ist eine Architekturentscheidung, keine Protokollgarantie.
