Model Context Protocol (MCP)

Model Context Protocol (MCP) Das Model Context Protocol (MCP) ist ein offener Standard, der festlegt, wie KI-Modelle strukturiert auf externe Daten und Werkzeuge zugreifen. Anthropic hat ihn entwickelt, die Projektführung liegt inzwischen bei der Linux Foundation. Statt für jede Kombination aus Modell und Tool einen eigenen Adapter zu bauen, baut ein Entwickler einen MCP-Server einmal, und jeder MCP-fähige Client kann ihn nutzen. Technisch basiert das Protokoll auf JSON-RPC und trennt sauber zwischen Host, Client und Server.

Was das Model Context Protocol ist

Die bisherige LLM-Integration in bestehende IT-Landschaften war ein Architektur-Albtraum. Wer seine Datenbank an eine KI anbinden wollte, schrieb einen eigenen Adapter, für jedes Tool und jedes Modell neu. Das ist teuer, wartungsintensiv, und es skaliert nicht. Das Model Context Protocol (MCP) beendet dieses Chaos.

Man kann den MCP-Standard als USB-C-Anschluss für KI-Anwendungen beschreiben: ein offener Standard, der regelt, wie KI-Modelle mit Datenquellen kommunizieren. Anthropic hat ihn entwickelt, mittlerweile liegt die Projektführung bei der Linux Foundation, organisiert als eigenständiges LF-Projekt mit eigener Governance-Struktur. Das Ziel ist seit dem ersten Tag gleich geblieben: Ein Entwickler baut einen Connector einmal, und er funktioniert bei jedem MCP-fähigen Client.

Wer noch skeptisch ist, ob das mehr als ein weiteres Buzzword ist: Deine Daten müssen für den Zugriff nicht auf fremde Server wandern. Ein MCP-Server läuft oft lokal auf deiner eigenen Maschine oder in deiner eigenen Infrastruktur, und die Verbindung zum Modell läuft kontrolliert über einen Client, den du selbst konfigurierst.

Wie die MCP-Architektur funktioniert

Technisch basiert das Protokoll auf JSON-RPC. Das macht die Kommunikation leichtgewichtig und zustandslos, jede Anfrage trägt ihre eigene Protokollversion und ihre eigenen Fähigkeiten mit sich. Die Architektur löst dabei ein klassisches Informatik-Problem, das M×N-Problem.

Ohne Standard müssten M verschiedene Modelle einzeln mit N verschiedenen Tools verbunden werden. Etwa Claude, GPT-5 und Gemini mit Google Drive, Slack und einer SQL-Datenbank, jede Kombination einzeln verdrahtet. Jede neue Kombination bedeutet neuen Code. Der Aufwand wächst dabei mit jedem zusätzlichen Modell oder Tool schneller, als jemand ihn pflegen kann. MCP dreht die Rechnung um zu M+N: Jedes Tool baut einmal eine Schnittstelle, und die ist danach für jeden kompatiblen Client sofort nutzbar.

Die drei Rollen: Host, Client und Server

Ein MCP-System kennt drei klar getrennte Akteure. Der Host ist die Anwendung, in der die KI läuft, zum Beispiel Claude Desktop oder eine IDE wie Cursor. Der Client sitzt im Host und übersetzt dessen Anfragen, wobei jeder Client mit genau einem Server spricht. Der Server ist der eigentliche Zugriffspunkt: Er stellt lokale Dateien, eine Datenbank oder eine externe API bereit und reicht sie strukturiert an den Client weiter.

Die Rollenverteilung ist strikt, und das ist Absicht. Ein Server sieht nie die ganze Konversation und nie, was in einem anderen Server passiert. Der Host behält die Kontrolle über Sicherheit und Freigaben, während die Server isolierte, austauschbare Bausteine bleiben. Ohne Server bleibt die KI blind für deine konkreten Daten, egal wie gut das Modell selbst ist.

Der Unterschied zu einer klassischen API

Warum reicht keine gewöhnliche REST-API? Weil APIs für Entwickler gebaut sind, nicht für Sprachmodelle. Eine API mit hunderten Endpunkten überfordert ein Modell schnell, was zu falschen Tool-Aufrufen und Halluzinationen führt.

MCP standardisiert deshalb drei Bausteine. Prompts sind vordefinierte Befehlsvorlagen für das Modell. Resources sind strukturierte Datenpakete zur Kontexterweiterung. Tools sind ausführbare Funktionen wie "Datei speichern" oder "Zeile in einer Tabelle aktualisieren". Ein Client kann so gezielt nur das anfragen, was für die aktuelle Aufgabe zählt, statt eine ganze API-Dokumentation in den Kontext zu laden.

Was MCP wirklich löst

Wer heute noch für jede Verbindung einen eigenen Adapter baut, verschwendet Budget. Der Wechsel auf einen offenen Standard sichert langfristig Unabhängigkeit von einem einzelnen Anbieter, weil ein einmal gebauter Server mit jedem MCP-fähigen Modell funktioniert, nicht nur mit dem, für das er ursprünglich gedacht war.

Der zweite Punkt ist Sicherheit. Statt API-Keys direkt in einen Chat zu kopieren, arbeitet MCP lokal: Du entscheidest, welcher Server aktiv ist, und der Server läuft unter deiner eigenen Kontrolle statt bei einem fremden Anbieter. Das macht Zero-Trust-Architekturen für externe Datenquellen praktisch umsetzbar, weil der Zugriff pro Server und pro Berechtigung einzeln geregelt wird.

Oft werde ich gefragt, ob MCP Retrieval-Augmented Generation ersetzt. Nein, es ergänzt es. Für Vektorsuche über große Dokumentenmengen brauchst du weiterhin eine RAG-Pipeline. Für den direkten Zugriff auf ein einzelnes Dokument oder eine Live-Datenquelle ist ein MCP-Server oft die schlankere Lösung, ohne den Aufbau einer eigenen Vektordatenbank.

Wo MCP heute im Einsatz ist

In der Softwareentwicklung ist Vibe Coding das Stichwort. Moderne Editor-Tools nutzen MCP, um Codebases zu lesen, Git-Historien zu prüfen und direkt im Terminal zu agieren, ohne dass der Entwickler den Kontext wechselt.

Im Unternehmensumfeld sieht das ähnlich aus. Enterprise Search verbindet Slack, Confluence und Drive zu einer einzigen Abfrage, mit der ein Team Fragen wie "Wie hoch war das Budget für Projekt X?" direkt beantwortet bekommt, statt drei Tools einzeln zu durchsuchen. Beim Debugging liest die KI Server-Logs in Echtzeit mit, statt dass jemand sie von Hand durchscrollt.

Am deutlichsten wird der Nutzen bei KI-Agenten. Ein autonomer Agent braucht ein verlässliches Nervensystem, um mit seiner Umgebung zu interagieren: Dateien lesen, Tools aufrufen, Ergebnisse prüfen. MCP liefert genau diese Schicht. Was den Unterschied zwischen einem reagierenden Assistenten und einem zielgerichtet handelnden Agenten ausmacht, steht im Vergleich zwischen KI-Assistent und KI-Agent.

Governance, Sicherheit und der aktuelle Stand

MCP ist inzwischen kein Anthropic-Projekt mehr im engeren Sinn. Seit die Linux Foundation die Trägerschaft übernommen hat, entscheidet ein mehrstufiges Gremium aus Lead- und Core-Maintainern über die Weiterentwicklung. Änderungen am Protokoll laufen über einen offenen Vorschlagsprozess, öffentlich einsehbar. Das ist der Unterschied zwischen einem Standard, der von einem einzelnen Unternehmen abhängt, und einem, der eine eigene Struktur zum Überleben hat.

Sichtbar wird das an der offiziellen MCP Registry, einem zentralen Verzeichnis für öffentlich erreichbare MCP-Server, getragen unter anderem von Anthropic, GitHub, PulseMCP und Microsoft. Statt einen Server aus einer zweifelhaften Quelle zu installieren, kann ein Client dort nach geprüften Einträgen suchen, jeder mit einer eindeutigen Namensraum-Verifizierung über DNS.

Das ändert nichts an der eigenen Verantwortung. Was ein Server darf, entscheidest weiterhin du, und dieser Teil wird gern unterschätzt. MCP macht die technische Verbindung einfach, aber die Rechteverwaltung liegt bei dir. Plan Zeit ein, um zu definieren, welcher Server auf welche Daten zugreifen darf, bevor du ihn produktiv schaltest. Die projekteigenen Security Best Practices sind ein guter Ausgangspunkt, gerade wenn ein Server Zugriff auf mehr als deine eigene Festplatte bekommt.

Weitere Begriffe rund um KI-Automatisierung stehen im Glossar. Wie ein Modell mit dem Kontext arbeitet, den MCP ihm liefert, erklärt der Eintrag zu Context Engineering.

Zurück zum AI und Automation Glossar.