Ein KI-Modell ist nur so nützlich wie die Daten und Werkzeuge, auf die es zugreifen kann. Sobald ein Large Language Model (LLM) mehr tun soll, als Text zu generieren – etwa eine Datenbank abfragen, eine Datei lesen oder eine externe API aufrufen – braucht es eine Verbindung zur Außenwelt. Bislang bauen Entwickler dafür individuelle Integrationen: ein Custom-Connector für die Datenbank, ein weiterer für das Dateisystem, ein dritter für den Kalender. Bei n Datenquellen und m KI-Anwendungen entsteht so schnell ein n×m-Geflecht aus Punkt-zu-Punkt-Integrationen, das mit jeder neuen Kombination komplexer und wartungsaufwändiger wird. Das Model Context Protocol (MCP) löst dieses Problem mit einem offenen Standard. Dieser Artikel erklärt, was MCP ist, wie es technisch aufgebaut ist und welche Designprinzipien dahinterstehen.
Was ist das Model Context Protocol (MCP)?
Das Model Context Protocol (MCP) ist ein offener Standard (offizielle Dokumentation), der definiert, wie KI-Anwendungen strukturiert mit externen Datenquellen und Werkzeugen kommunizieren. Anthropic hat MCP im November 2024 veröffentlicht und als Open-Source-Spezifikation freigegeben; seitdem wird das Protokoll von einer wachsenden Community aus Anbietern und Entwicklern weiterentwickelt.
Die Grundidee lässt sich mit einer Analogie greifbar machen: USB-C hat die Vielzahl proprietärer Ladekabel und Adapter durch einen universellen Anschluss ersetzt. MCP verfolgt dasselbe Prinzip für KI-Systeme: Statt jede Datenquelle individuell an ein bestimmtes Modell anzubinden, stellt das Model Context Protocol (MCP) eine einheitliche Schnittstelle bereit, die jede kompatible KI-Anwendung nutzen kann.
Abgrenzung zu klassischen APIs
MCP ist kein Ersatz für REST oder GraphQL. Es operiert auf einer anderen Ebene. Eine klassische API stellt einen festen Satz von Endpunkten bereit, den ein Entwickler zur Build-Zeit kennt und fest in seinen Code integriert. MCP hingegen beschreibt zur Laufzeit, welche Fähigkeiten ein Server anbietet – ein KI-Modell entdeckt diese Fähigkeiten dynamisch, ohne dass die Integration bei jeder Änderung neu programmiert werden muss. MCP kann intern durchaus REST-APIs oder Datenbankverbindungen ansprechen; es fügt eine standardisierte Beschreibungs- und Discovery-Schicht darüber.
Die Architektur von MCP
Die Architektur des Model Context Protocol (MCP) folgt einem klaren Rollenmodell mit drei Komponenten: Host, Client und Server.
Host, Client und Server
- MCP Host: Die KI-Anwendung, in der das Modell läuft – etwa ein Chat-Interface, eine IDE-Erweiterung oder ein Agent-Framework. Der Host koordiniert eine oder mehrere Client-Verbindungen.
- MCP Client: Eine Komponente innerhalb des Hosts, die genau eine 1:1-Verbindung zu einem MCP Server hält. Für jeden Server, mit dem der Host kommuniziert, existiert ein eigener Client.
- MCP Server: Ein Programm, das Daten oder Funktionen einer bestimmten Quelle – etwa ein Dateisystem, eine Datenbank oder eine externe API – über MCP bereitstellt.
Kommunikationsgrundlage: JSON-RPC 2.0
Client und Server tauschen Nachrichten im Format JSON-RPC 2.0 aus – einem leichtgewichtigen, textbasierten Protokoll für Remote-Prozeduraufrufe. Jede Anfrage enthält eine Methode und Parameter, jede Antwort ein Ergebnis oder eine Fehlermeldung. Diese Entscheidung hält die Implementierung bewusst einfach: JSON-RPC ist sprachunabhängig und lässt sich in praktisch jeder Programmiersprache umsetzen.
Transport-Mechanismen
MCP unterstützt zwei Transportwege, je nachdem, wo Client und Server laufen:
- stdio (Standard Input/Output): Für lokale Server, die als Subprozess auf demselben Rechner laufen. Client und Server kommunizieren direkt über die Standard-Ein- und -Ausgabe – ohne Netzwerk-Overhead.
- Streamable HTTP: Für entfernte Server, die über ein Netzwerk erreichbar sind. Der Transport unterstützt bidirektionale Kommunikation und eignet sich für Server, die von mehreren Clients gleichzeitig genutzt werden.
Session-Lifecycle und Capability Negotiation
Beim Verbindungsaufbau handeln Client und Server ihre unterstützten Fähigkeiten aus – die sogenannte Capability Negotiation. Der Server teilt mit, welche Tools, Resources und Prompts er anbietet; der Client teilt mit, welche Funktionen der Host unterstützt, etwa ob er Rückfragen an den Nutzer stellen kann. Erst nach dieser Initialisierungsphase beginnt der eigentliche Austausch von Daten und Funktionsaufrufen.
Die Kernbausteine (Primitives) von MCP
Das Model Context Protocol strukturiert die Kommunikation über drei zentrale Bausteine, die auch als Primitives bezeichnet werden.
| Primitive | Beschreibung | Beispiel |
|---|---|---|
| Tools | Ausführbare Funktionen, die das KI-Modell aufrufen kann | search_files, create_ticket |
| Resources | Datenquellen, die dem Modell als Kontext bereitgestellt werden | Eine Konfigurationsdatei, ein Datenbank-Schema |
| Prompts | Vordefinierte, wiederverwendbare Abfragemuster | Ein Template für Code-Reviews |
Tools: Aktionsfähigkeit für das Modell
Tools sind Funktionen mit einem definierten Schema für Ein- und Ausgabeparameter. Das Modell entscheidet zur Laufzeit, ob und mit welchen Parametern es ein Tool aufruft; der Server validiert die Parameter und führt die eigentliche Aktion aus. Tools ermöglichen sowohl lesende als auch schreibende Operationen – von einer einfachen Abfrage bis zum Anlegen eines Datensatzes.
Resources: Kontext ohne Funktionsaufruf
Resources unterscheiden sich von Tools dadurch, dass sie keine Aktion auslösen, sondern Daten bereitstellen – vergleichbar mit einer GET-Anfrage ohne Nebeneffekte. Ein Server kann etwa den Inhalt einer Datei, ein Datenbankschema oder Log-Einträge als Resource exponieren, die das Modell bei Bedarf in seinen Kontext lädt.
Prompts: Standardisierte Abfragemuster
Prompts sind vordefinierte Vorlagen für wiederkehrende Anfragen. Statt dass jeder Nutzer denselben komplexen Prompt manuell formuliert, stellt der Server ihn als Template bereit – mit Platzhaltern für variable Parameter. Das reduziert Inkonsistenzen und macht bewährte Abfragemuster wiederverwendbar.
Ein viertes, fortgeschrittenes Konzept ist Sampling: Damit kann ein Server bei Bedarf eine Anfrage an das Sprachmodell des Hosts zurückschicken, etwa um einen Zwischenschritt von der KI bewerten zu lassen. Für den Einstieg in MCP sind Tools, Resources und Prompts jedoch die relevanten Bausteine.
Designprinzipien des Model Context Protocol (MCP)
Hinter der Architektur stehen einige wiederkehrende Designentscheidungen, die erklären, warum MCP so und nicht anders aufgebaut ist.
Standardisierung statt Punkt-zu-Punkt-Integration
Das zentrale Ziel des Model Context Protocol (MCP) ist, die n×m-Integrationslast aufzulösen. Ein Server-Anbieter implementiert MCP einmal; jeder MCP-kompatible Host kann diesen Server nutzen, ohne eine eigene Integration zu bauen. Umgekehrt profitiert jeder Host sofort von allen verfügbaren MCP-Servern, ohne für jeden einzeln Code zu schreiben.
Sicherheit und Nutzerkontrolle
MCP ist so konzipiert, dass der Zugriff eines Modells nie implizit erfolgt. Der Host entscheidet, welche Server verbunden werden, und kann – insbesondere bei schreibenden Tool-Aufrufen – eine explizite Bestätigung des Nutzers verlangen, bevor eine Aktion ausgeführt wird. Diese Kontrolle liegt bewusst außerhalb des Protokolls selbst, in der Verantwortung der Host-Implementierung.
Modularität und Komponierbarkeit
Server sind unabhängig voneinander und lassen sich beliebig kombinieren. Ein Host kann gleichzeitig mit einem Dateisystem-Server, einem Datenbank-Server und einem Ticketing-Server verbunden sein, ohne dass diese Server voneinander wissen. Diese lose Kopplung erlaubt es, einzelne Server auszutauschen oder zu erweitern, ohne die übrige Integration anzufassen.
Laufzeit-Discoverability
Ein MCP Client fragt beim Verbindungsaufbau aktiv ab, welche Tools, Resources und Prompts ein Server anbietet – die Fähigkeiten sind also nicht hart codiert, sondern werden dynamisch entdeckt. Ändert ein Server-Anbieter seine Funktionen, muss der Host-Code nicht angepasst werden; das Modell erkennt die neuen Möglichkeiten beim nächsten Verbindungsaufbau automatisch.
Modell-Agnostizismus
MCP macht keine Vorgaben zum verwendeten KI-Modell. Ein MCP-Server, der einmal implementiert ist, funktioniert unabhängig davon, ob der Host ein Modell von Anthropic, OpenAI oder ein Open-Source-Modell einsetzt. Das entkoppelt die Integrationsarbeit von der Wahl des Sprachmodells.
Wo MCP in der Praxis eingesetzt wird
MCP-Server existieren bereits für eine breite Palette an Anwendungsfällen: Zugriff auf Versionskontrollsysteme und Ticketing-Tools in Entwicklungsumgebungen, Anbindung von Wissensdatenbanken und Dokumentenspeichern für Recherche-Assistenten, oder Automatisierung wiederkehrender Abläufe in Geschäftsanwendungen. Gemeinsam ist all diesen Fällen dasselbe Muster: Ein Server kapselt den Zugriff auf eine Datenquelle, ein Host verbindet sich darüber mit beliebigen kompatiblen KI-Modellen.
Auch im industriellen Umfeld gewinnt das Protokoll an Bedeutung, etwa als Integrationsschicht zwischen KI-Systemen und dem Unified Namespace (UNS). Wie ein MCP-Server dort konkret als Vermittler zwischen AI Agents und einer Broker-basierten UNS-Architektur eingesetzt wird – inklusive Referenzarchitektur, Tool-Design und Sicherheitsmodell – behandelt dieser Artikel mit praktischen Anwendungsbeispiel im UNS-Kontext.
Empfehlungen für den Einstieg
Do
- Klein anfangen: Einen einzelnen MCP-Server für einen klar abgegrenzten Anwendungsfall aufsetzen, bevor mehrere Server kombiniert werden.
- Tool-Design fachlich denken: Tools an Operationen ausrichten, die ein Fachanwender nachvollziehen kann – nicht an technischen Datenbank- oder API-Endpunkten.
- Sicherheitsmodell von Anfang an mitdenken: Festlegen, welche Tool-Aufrufe eine explizite Nutzerbestätigung erfordern, bevor der Server produktiv geschaltet wird.
Avoid
- Zu granulare Tools: Ein Tool pro Datenbankspalte erzeugt unübersichtlich viele Funktionen und erschwert dem Modell die sinnvolle Auswahl.
- Zu generische Tools: Ein einzelnes Tool, das beliebige Datenbankabfragen entgegennimmt, umgeht die Validierungs- und Kontrollschicht, die MCP eigentlich bietet.
- Schreibzugriffe ohne Bestätigung: Tools, die Daten verändern oder Aktionen auslösen, sollten nie ohne Rückfrage an den Nutzer laufen.
Fazit
Das Model Context Protocol (MCP) schließt eine strukturelle Lücke zwischen KI-Modellen und den Datenquellen, Werkzeugen und Systemen, mit denen sie arbeiten sollen. Statt jede Integration einzeln zu bauen, stellt ein offener Standard eine gemeinsame Sprache bereit, die jeder kompatible Host und jeder kompatible Server versteht. Drei zentrale Erkenntnisse:
- Klare Rollentrennung: Das Host-Client-Server-Modell trennt KI-Anwendung, Verbindungslogik und Datenquelle sauber voneinander – jede Komponente kann unabhängig weiterentwickelt werden.
- Drei einfache Bausteine: Tools, Resources und Prompts decken die wichtigsten Interaktionsmuster zwischen Modell und Außenwelt ab, ohne die Komplexität einer vollständigen API-Spezifikation.
- Standardisierung reduziert Integrationsaufwand: Ein einmal gebauter MCP-Server funktioniert mit jedem MCP-kompatiblen Host – unabhängig vom eingesetzten Sprachmodell.
