Model Context Protocol: Die MCP-Architektur im Detail

Das Model Context Protocol (MCP) definiert neu, wie KI-Systeme mit externen Tools und Datenquellen arbeiten. Es baut auf einfachem Function Calling auf und führt eine leistungsfähige, modulare Client-Server-Architektur ein, die dynamische Tool-Erkennung, sichere Integration und effizientes Session-Management ermöglicht. In diesem Beitrag geht es um die Kernkomponenten von MCP: die Phasen des Lebenszyklus, Primitive wie Tools und Resources und die technischen Neuerungen, die MCP zum Game-Changer für skalierbare KI-Interoperabilität machen.

Die Client-Server-Architektur des Model Context Protocol

MCP folgt einer sauberen Client-Server-Architektur, die die KI-Seite klar von der Tool-Seite trennt:

MCP-Client: Läuft in der KI-Host-Anwendung (etwa einer Chat-Oberfläche, einer IDE mit KI-Assistent oder Claude Desktop). Der Client spricht mit dem LLM und verwaltet die Verbindungen zu den verschiedenen Tool-Servern.
MCP-Server: Ein schlankes Programm, das dem Modell bestimmte Fähigkeiten zur Verfügung stellt. Jeder Server konzentriert sich meist auf eine bestimmte Domäne oder einen bestimmten Dienst: Wetterdaten, E-Mail-Funktionen, Datenbankzugriff und so weiter.

Durch diese Trennung lässt sich modular entwickeln. Tool-Anbieter können MCP-Server bauen, ohne die Feinheiten der LLM-Integration verstehen zu müssen, und KI-Entwickler können jedes MCP-kompatible Tool nutzen, ohne eigene Integrationsarbeit zu leisten.

Client und Server kommunizieren über bidirektionale, zustandsbehaftete Kanäle, die sich so umsetzen lassen:

Lokale stdio-Pipes (für Tools auf demselben Rechner)
WebSockets
HTTP-Streams mit Server-Sent Events (SSE)

Die dauerhafte Verbindung erlaubt einen fortlaufenden Austausch statt isolierter Anfragen und damit auch komplexe Interaktionen über mehrere Schritte.

Verwaltung des Session-Lebenszyklus

Anders als bei einfachen API-Aufrufen legt MCP für Client-Server-Sessions einen formalen Lebenszyklus mit drei klar getrennten Phasen fest:

1. Initialisierungsphase

Sobald die Verbindung steht, führen Client und Server einen strukturierten Handshake durch:

Der Client sendet eine initialize-Anfrage mit seinen Fähigkeiten und seiner Identität
Der Server antwortet mit seinen eigenen Fähigkeiten und den unterstützten Funktionen
Der Client sendet eine initialized-Benachrichtigung, um seine Bereitschaft anzuzeigen

Durch diese Aushandlung wissen beide Seiten, welche Funktionen verfügbar sind, bevor es weitergeht.

2. Betriebsphase

Im normalen Betrieb kann der Client:

Tools über tools/call-Anfragen aufrufen
Resources über resources/get-Anfragen abrufen
Prompts über prompts/get-Anfragen anfordern
regelmäßig ping-Nachrichten senden, um den Zustand der Verbindung zu prüfen

Der Server beantwortet diese Anfragen, führt Funktionen aus und liefert bei Bedarf Ergebnisse zurück.

3. Beendigungsphase

Wenn die Interaktion abgeschlossen ist:

Der Client sendet eine shutdown-Anfrage
Der Server bestätigt und gibt Ressourcen frei
Mit einer exit-Benachrichtigung lässt sich die Verbindung schließen

Durch diesen geordneten Abbau werden Ressourcen sauber freigegeben, und beide Seiten erkennen, dass die Session beendet ist.

Dieser Lebenszyklus bringt mehrere Vorteile:

Er ermöglicht zustandsbehaftete Authentifizierung (einmal pro Session anmelden)
Er erlaubt Kontext-Caching für bessere Performance
Er unterstützt mehrstufige Abläufe, die auf früheren Interaktionen aufbauen
Er bietet klare Fehlergrenzen und Mechanismen zur Wiederherstellung

Aushandlung von Fähigkeiten und Versionierung

Eine große Stärke des Model Context Protocol ist die eingebaute Aushandlung der Fähigkeiten. Bei der Initialisierung tauschen Client und Server Informationen darüber aus, welche Funktionen sie unterstützen:

Ein Server könnte ankündigen: „Ich unterstütze die Primitive Tools und Resources, aber nicht Prompts“
Ein Client könnte erklären: „Ich kann mit OAuth-Authentifizierung und Sampling-Anfragen umgehen“

Danach einigen sie sich auf eine gemeinsame Teilmenge an Funktionen. Diese Aushandlung sorgt für Vorwärts- und Abwärtskompatibilität: Neuere Implementierungen funktionieren mit älteren zusammen, indem sie auf die gemeinsamen Fähigkeiten zurückfallen.

Ähnlich handeln Webbrowser und Server Protokollversionen aus, und ähnlich ermitteln Bluetooth-Geräte die unterstützten Profile. Dadurch kann sich MCP mit der Zeit weiterentwickeln, ohne bestehende Integrationen lahmzulegen.

Dynamische Tool-Erkennung

Zu den stärksten Funktionen von MCP gehört die dynamische Tool-Erkennung. Beim klassischen Function Calling müssen die verfügbaren Funktionen vorab definiert sein, MCP dagegen erlaubt es, Fähigkeiten zur Laufzeit zu entdecken.

Verbindet sich ein MCP-Client zum Beispiel mit einem Server, kann er eine tools/list-Anfrage senden, um zu erfahren, welche Funktionen verfügbar sind. Der Server antwortet mit einem Katalog von Tools, der unter anderem Folgendes enthält:

Namen und Beschreibungen
Erforderliche Parameter und ihre Typen
Formate der Rückgabewerte
Anforderungen an die Authentifizierung

Diese Informationen lassen sich dann dem Modell präsentieren (über System-Prompts oder andere Mechanismen), damit es fundiert entscheiden kann, welche Tools es nutzt.

Diese dynamische Erkennung ermöglicht leistungsfähige Szenarien:

KI-Assistenten können sich je nach Bedarf der Nutzer mit neuen Tools verbinden
Tools können ihre Fähigkeiten aktualisieren, ohne dass der Client geändert werden muss
Systeme können sich an Benutzerrechte anpassen und nur autorisierte Tools anzeigen

Nehmen Sie einen universellen KI-Assistenten, der bei verschiedenen Aufgaben hilft. Fragt ein Nutzer nach dem Wetter, kann sich der Assistent dynamisch mit einem Wetter-MCP-Server verbinden, dessen Fähigkeiten erkunden und das passende Tool nutzen. Fragt der Nutzer später nach seinem Kalender, verbindet sich der Assistent mit einem anderen MCP-Server für Kalenderfunktionen.

Mehr als einfache Funktionsaufrufe: die Primitive des Model Context Protocol

Tools (Funktionen) sind das offensichtlichste Primitiv in MCP, aber das Protokoll definiert noch weitere Primitive, die den Spielraum erweitern:

Resources

Resources bieten einen standardisierten Weg, strukturierte Daten oder Dokumente abzurufen. Anders als Tools, die Aktionen ausführen, sind Resources passive Datenquellen.

Ein MCP-Server für ein Code-Repository könnte zum Beispiel Dateien als Resources bereitstellen. Braucht das Modell eine bestimmte Datei, kann der Client sie über eine resources/get-Anfrage abrufen:

{
  "jsonrpc": "2.0",
  "id": 456,
  "method": "resources/get",
  "params": {
    "uri": "repo://myproject/src/main.py"
  }
}

Der Server liefert den Dateiinhalt zurück, den der Client in den Kontext des Modells aufnehmen kann. So arbeitet das Modell mit aktuellen Informationen, ohne dass sie vorab geladen sein müssen.

Prompts

Prompts sind vordefinierte Anweisungsvorlagen, die sich über mehrere Interaktionen hinweg wiederverwenden lassen. Ein Server kann Standard-Prompts für häufige Aufgaben anbieten und so für einheitliches Verhalten sorgen.

Ein Datenanalyse-Server könnte etwa Prompts wie „Fasse diesen Datensatz zusammen“ oder „Finde Anomalien in diesen Werten“ bereitstellen. Der Client holt sie über prompts/get-Anfragen und kann sie auf konkrete Kontexte anwenden.

Roots und Sampling

Auf der Client-Seite definiert MCP weitere Primitive:

Roots: Geben Servern kontrollierten Zugriff auf vom Client verwaltete Ressourcen (etwa Dateisystempfade)
Sampling: Erlaubt Servern, in bestimmten Szenarien Modell-Completions anzufordern

Besonders interessant ist Sampling, weil es eine Art „Callback“ ermöglicht: Tools können während ihrer Ausführung zusätzliches KI-Reasoning anfordern. Ein komplexes Analyse-Tool könnte das Modell zum Beispiel fragen: „Soll ich auf Basis dieser Zwischenergebnisse mit Methode A oder B weitermachen?“

So entsteht ein Zusammenspiel zwischen Modell und Tools, das anspruchsvollere Denkprozesse erlaubt. Anthropic empfiehlt allerdings menschliche Aufsicht beim Einsatz von Sampling, um mögliches ausuferndes Self-Prompting zu verhindern.

Sicherheit und Kontrolle

MCP geht auch auf Sicherheitsfragen bei der Interaktion zwischen KI und Tools ein:

Authentifizierung: Das Protokoll unterstützt OAuth 2.0 und andere Standardverfahren zur Authentifizierung und sichert so den Zugriff auf geschützte Ressourcen.
Berechtigungsgrenzen: Der Client bestimmt, welche Server verbunden sind, und erlaubt so eine feingranulare Rechteverwaltung.
Monitoring: Durch die strukturierte Form von MCP lassen sich alle Tool-Aufrufe leicht protokollieren und prüfen.
Menschliche Aufsicht: Kritische Vorgänge lassen sich so markieren, dass ein Mensch sie vor der Ausführung freigeben muss.

Diese Schutzmaßnahmen helfen, Missbrauch zu verhindern, und lassen trotzdem leistungsfähige Automatisierung zu.

Interoperabilität und das wachsende Ökosystem

Die größte Stärke von MCP ist vielleicht der Fokus auf Interoperabilität. Mit einer gemeinsamen „Sprache“ für die Interaktion zwischen KI und Tools ermöglicht es ein Ökosystem, in dem:

mehrere KI-Systeme dieselben Tools nutzen können
mehrere Tools in derselben Session zusammen genutzt werden können
neue Fähigkeiten dazukommen können, ohne bestehende zu stören

Das erinnert daran, wie das Language Server Protocol (LSP) die Entwicklerwerkzeuge grundlegend verändert hat: Vor LSP brauchte jede IDE eigene Plugins für jede Programmiersprache, nach LSP konnte eine Implementierung in allen kompatiblen Editoren laufen.

Rund um MCP entsteht bereits ein Open-Source-Ökosystem mit Servern für:

Websuche und Browsing
Dateisystemzugriff
Datenbankabfragen
E-Mail und Messaging-Dienste
API-Gateways
Code-Repositories und Code-Ausführung

Mit dem Wachstum dieses Ökosystems werden KI-Assistenten immer leistungsfähiger, weil sie diese modularen Tools kombinieren können, um komplexe Probleme zu lösen.

Praxisbeispiel: Probleme in mehreren Schritten lösen

Um zu zeigen, was MCP leisten kann, nehmen wir an, ein Nutzer bittet einen KI-Assistenten: „Erstelle eine Zusammenfassung des heutigen Meetings und teile sie mit dem Team auf Slack.“

Mit MCP könnte der Assistent so vorgehen:

Verbindung zu einem Kalender-MCP-Server aufnehmen, um die Details des Meetings zu ermitteln
Einen Transkriptions-MCP-Server nutzen, um auf Meeting-Notizen oder Aufzeichnungen zuzugreifen
Ein Zusammenfassungs-Tool aufrufen, um eine knappe Zusammenfassung zu erstellen
Verbindung zu einem Slack-MCP-Server aufnehmen, um die Zusammenfassung im passenden Channel zu posten

All das läuft über ein einheitliches Protokoll, und das Modell steuert den Ablauf anhand seines Verständnisses der Anfrage.

Ohne MCP wäre für diesen Workflow eine eigene Integration mit mehreren APIs nötig, jede mit eigener Authentifizierung, eigenen Datenformaten und eigener Fehlerbehandlung. MCP abstrahiert diese Unterschiede und bietet eine einheitliche Schnittstelle.

Ausblick

Mit der wachsenden Verbreitung des Model Context Protocol dürfen wir immer ausgereiftere KI-Assistenten erwarten, die komplexe, mehrstufige Aufgaben in verschiedenen Bereichen bewältigen. Dank seiner Erweiterbarkeit kann sich das Protokoll zusammen mit den Fortschritten bei KI und Tools weiterentwickeln.

In unserem dritten und letzten Beitrag vergleichen wir MCP mit anderen Ansätzen für Function Calling, sehen uns reale Anwendungen an und besprechen, was die Zukunft für diesen vielversprechenden Standard bringen könnte.

Aus dem Englischen übersetzt: zum Originalbeitrag