MCP: das Model Context Protocol erklärt

MCP in einem Satz

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen einheitlich auf externe Werkzeuge und Datenquellen zugreifen: Ein Programm stellt seine Funktionen einmal nach den Regeln des Protokolls bereit, und jede MCP-fähige KI-Anwendung kann sie nutzen – ohne dass für jede Kombination aus Modell und Tool eine eigene Schnittstelle gebaut werden muss.

Der oft zitierte Vergleich trifft es gut: MCP ist so etwas wie USB-C für KI-Anwendungen. Ein Stecker, viele Geräte. Vorgestellt wurde das Protokoll Ende 2024 von Anthropic und als offener Standard freigegeben. Im Laufe von 2025 haben es die übrigen großen Anbieter übernommen – seitdem ist es faktisch der Normalweg, um Werkzeuge an Sprachmodelle anzubinden.

Das Problem, das MCP löst

Vor MCP war jede Anbindung Einzelarbeit. Wolltest du drei KI-Anwendungen mit fünf internen Systemen verbinden, brauchtest du im ungünstigsten Fall fünfzehn eigene Integrationen – jede mit eigener Authentifizierung, eigenem Datenformat und eigener Wartung. Kam ein Tool dazu, vervielfachte sich der Aufwand. Genau daran ist in den Jahren davor ein Großteil der ambitionierten Agenten-Projekte gescheitert: nicht am Modell, sondern an der Anbindung.

MCP dreht das um. Das System, das etwas anbietet, beschreibt seine Funktionen einmal in einer maschinenlesbaren Form. Jede KI-Anwendung, die das Protokoll spricht, versteht diese Beschreibung – welche Funktionen es gibt, welche Angaben sie erwarten und was zurückkommt. Aus vielen einzelnen Verbindungen wird ein gemeinsamer Anschluss.

Für dich als Anwenderin oder Anwender heißt das konkret: Neue Werkzeuge kommen per Konfiguration dazu, nicht per Entwicklungsprojekt.

Host, Client, Server: die drei Rollen

Die Begriffe klingen technischer, als sie sind.

Wichtig zum Verständnis: Ein MCP-Server ist nichts Großes. Der Name weckt falsche Erwartungen. Oft ist es ein kleines Programm, das lokal auf deinem Rechner läuft und einen Ordner, eine Datenbank oder ein Werkzeug zugänglich macht. Es gibt sie ebenso als gehostete Dienste, die über das Netz erreichbar sind.

Der Ablauf ist immer derselbe: Der Host meldet sich beim Server an und fragt, was er kann. Der Server antwortet mit einer Liste seiner Funktionen samt Beschreibung. Diese Liste bekommt das Modell zu sehen. Braucht es im Gespräch eine davon, fordert es den Aufruf an, der Host führt ihn über den Client aus – idealerweise mit deiner Bestätigung – und das Ergebnis fließt zurück ins Gespräch.

Was ein MCP-Server anbietet

Ein Server stellt drei Arten von Bausteinen bereit. Die Unterscheidung ist praktisch relevant, weil sie darüber entscheidet, wer die Kontrolle hat.

Werkzeuge (Tools). Aktionen, die das Modell auslösen kann: eine Suche ausführen, einen Datensatz anlegen, eine Datei schreiben, eine Berechnung starten. Das ist der Teil mit Wirkung – und der Teil, der eine Freigabe braucht.

Ressourcen (Resources). Inhalte zum Lesen: Dateien, Tabellenblätter, Datenbankeinträge, Dokumentationen. Sie verändern nichts, sondern liefern dem Modell Kontext. Was davon in das Gespräch geladen wird, steuert in der Regel die Anwendung, nicht das Modell.

Vorbereitete Anweisungen (Prompts). Vom Server mitgelieferte Vorlagen für wiederkehrende Abläufe, die du in der Anwendung auswählst – etwa „Diesen Datensatz gegen unsere Kriterien prüfen". Der Server bringt damit sein eigenes Bedienwissen mit.

Diese Struktur ist der Grund, warum MCP mehr ist als eine hübschere Programmierschnittstelle: Das Protokoll transportiert nicht nur Funktionen, sondern auch deren Beschreibung. Das Modell weiß, wofür ein Werkzeug gedacht ist – nicht nur, wie man es technisch aufruft.

Wo dir MCP heute begegnet

In Chat- und Desktop-Anwendungen. Die Assistenz-Apps der großen Anbieter lassen sich über MCP mit lokalen Ordnern, Notizsystemen oder Projektwerkzeugen verbinden. Du konfigurierst den Server einmal, danach steht das Werkzeug im Gespräch zur Verfügung. Wie das im Alltag aussieht, zeigt der Claude-Guide.

In Automatisierungsplattformen. Sowohl n8n als auch Zapier unterstützen MCP inzwischen in beide Richtungen: Ein Workflow kann selbst als MCP-Server auftreten, sodass eine KI-Anwendung ihn als Werkzeug aufruft – und ein KI-Schritt im Workflow kann umgekehrt fremde MCP-Server nutzen. Das ist der praktisch interessanteste Fall, weil sich damit hunderte vorhandene App-Anbindungen ohne Eigenentwicklung für Agenten öffnen lassen.

In Entwicklungsumgebungen. Code-Werkzeuge binden über MCP Dokumentation, Ticketsysteme und Datenbanken an. Das ist auch die Grundlage dafür, dass KI-gestütztes Programmieren über den reinen Editor hinausgeht – siehe Vibe Coding.

Was das für Agenten bedeutet

MCP löst genau den Baustein, an dem in KI-Agenten erstellen die meiste Arbeit hängt: die Werkzeuge. Statt jede Anbindung selbst zu bauen, greifst du auf vorhandene Server zurück oder stellst deine eigenen Systeme einmal bereit.

Drei Folgen sind schon sichtbar:

• Austauschbarkeit der Modelle. Wenn Werkzeuge über ein neutrales Protokoll hängen, kostet ein Modellwechsel keine Neuentwicklung der Integrationen mehr.
• Wiederverwendbarkeit. Ein einmal bereitgestellter Server für euer CRM steht allen internen KI-Anwendungen zur Verfügung.
• Ein wachsender Fundus. Für die verbreiteten Systeme – Dateiablagen, Datenbanken, Projekt- und Ticketwerkzeuge, Websuche – existieren bereits fertige Server.

Was MCP dagegen nicht löst: Ein Agent wird davon nicht klüger. Zuschnitt der Aufgabe, Qualität der Daten und Guardrails bleiben genau die Baustellen, die sie vorher waren. Die Grundlagen dazu stehen in Was sind KI-Agenten?.

Sicherheit: die Fragen vor der Anbindung

Ein MCP-Server bekommt Zugriff auf echte Daten und darf echte Aktionen ausführen. Bevor du einen anbindest, klär drei Dinge:

Herkunft. Server aus offenen Verzeichnissen sind schnell installiert – und laufen auf deinem Rechner mit deinen Rechten. Nutze bevorzugt Server der Systemhersteller selbst oder solche, deren Quelle du prüfen kannst.

Rechteumfang. Jeder Server bekommt eigene Zugangsdaten mit dem kleinstmöglichen Rechteumfang. Lesezugriff, wo Lesen reicht. Ein Server, der einen Ordner freigibt, sollte den Ordner freigeben – nicht das Dateisystem.

Bestätigung vor Wirkung. Werkzeugaufrufe mit Außenwirkung gehören hinter eine ausdrückliche Bestätigung. Und eine Eigenheit dieses Aufbaus solltest du kennen: Weil das Modell die Werkzeugbeschreibungen des Servers liest, kann ein manipulierter Server dem Modell über diese Beschreibungen Anweisungen unterschieben. Das ist kein theoretisches Risiko, sondern der Hauptgrund, warum blindes Vertrauen in fremde Server keine gute Idee ist.

Ehrliche Einordnung

MCP ist ein junger Standard und entwickelt sich schnell. Die Rollenaufteilung und die Grundbausteine sind stabil, aber Details – Authentifizierung, Verzeichnisse, Betriebsmodelle – bewegen sich noch. Rechne damit, dass ein Aufbau von heute in einem Jahr Nacharbeit braucht.

Trotzdem lohnt der Einstieg: Der Nutzen liegt weniger in einzelnen spektakulären Anwendungen als darin, dass Anbindungen ihren Sonderstatus verlieren. Das war lange die eigentliche Bremse.

Fazit

MCP ist die Steckdose zwischen Sprachmodell und Außenwelt. Ein System beschreibt seine Funktionen einmal nach den Regeln des Protokolls, jede MCP-fähige Anwendung kann sie nutzen. Für Agentenprojekte fällt damit der teuerste Teil weg – die Einzelanbindung pro Tool. Was bleibt, ist die inhaltliche Arbeit: klarer Aufgabenzuschnitt, saubere Daten, minimale Rechte und eine Bestätigung vor jeder Aktion, die nach außen wirkt.