Schnittstellen für KI-Werkzeuge

Was ist das Model Context Protocol (MCP)?

MCP

Das Model Context Protocol ist ein offener Standard, über den KI-Anwendungen einheitlich auf externe Werkzeuge, Dateien und Datenquellen zugreifen. Statt für jede Kombination aus Anwendung und System eine eigene Anbindung zu bauen, beschreibt ein Server seine Fähigkeiten einmal maschinenlesbar.

Jeder Assistent, der auf Dateien, Tickets oder Datenbanken zugreifen soll, braucht eine Anbindung, und dieser Standard ersetzt die vielen Einzellösungen dafür.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Art: Offener Standard, herstellerübergreifend
Besteht aus: Server, Client und Werkzeugbeschreibungen
Typisch bei: Anbindung von Dateien, Tickets, Datenbanken
Verwechselt mit: Function Calling

Server, Client und Werkzeugbeschreibung

Ein MCP-Server stellt bereit, was ein Modell nutzen darf: Werkzeuge, die etwas tun, Ressourcen, die etwas liefern, und vorbereitete Anweisungsbausteine. Jedes Werkzeug hat einen Namen, eine Beschreibung in normaler Sprache und ein Schema für seine Parameter. Diese Beschreibung ist der eigentliche Kern, denn anhand von ihr entscheidet das Modell, wann ein Aufruf sinnvoll ist.

Die Anwendung, in der du arbeitest, ist der Client. Sie verbindet sich mit dem Server, holt die Liste der Werkzeuge und legt sie dem Modell vor. Will das Modell etwas aufrufen, führt nicht das Modell den Aufruf aus, sondern der Client, und er reicht auch das Ergebnis zurück. Modell und System sind so nie direkt verbunden, dazwischen sitzt immer eine Stelle, an der du prüfen und protokollieren kannst.

Als Transport gibt es zwei übliche Wege: lokal über die Standardein- und -ausgabe eines Prozesses auf demselben Rechner, oder über das Netzwerk zu einem entfernt betriebenen Server. Lokal bleiben die Zugangsdaten auf deinem Gerät, entfernt lässt sich ein Server zentral für ein ganzes Team betreiben.

Warum ein Standard hier etwas bringt

Ohne Standard entsteht für jede Kombination aus KI-Anwendung und Zielsystem eine eigene Anbindung. Fünf Anwendungen und acht Systeme ergeben vierzig einzelne Verbindungen, die alle gepflegt werden wollen. Mit einem gemeinsamen Protokoll schreibst du je System einen Server, und jede Anwendung, die das Protokoll spricht, kann ihn nutzen.

Der zweite Gewinn ist Ordnung. Die Anbindung steckt nicht mehr in einem langen Prompt, sondern in einer Beschreibung mit Schema. Ändert sich das Zielsystem, änderst du den Server, nicht dreißig Prompts an verschiedenen Stellen.

Rechte und Risiken

Ein Server arbeitet mit genau den Rechten, die du ihm gibst. Ein Zugang mit Schreibrechten wird früher oder später schreiben, auch wenn das nie geplant war, weil das Modell den Aufruf für die naheliegende Lösung hält. Lesende Zugänge, getrennte Konten pro Server und eine Bestätigung vor allem, was sich nicht zurücknehmen lässt, sind hier keine Vorsicht, sondern Grundausstattung.

Dazu kommt eine unangenehme Eigenschaft: Was ein Server zurückliefert, geht als Text in das Modell. Steht in einem abgerufenen Ticket oder Dokument eine Anweisung, kann das Modell sie befolgen. Prüf deshalb, aus welchen Quellen Inhalte kommen, und begrenze, wohin ein System Daten senden darf. Einen Server aus fremder Quelle liest du vorher durch, denn er läuft mit deinen Rechten auf deinem Rechner.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Model Context Protocol und was oft damit gleichgesetzt wird

Model Context Protocol gegen Function Calling

Function Calling ist die Fähigkeit des Modells, einen strukturierten Aufruf zu formulieren. MCP regelt die Ebene darüber, nämlich wie Werkzeuge bereitgestellt, beschrieben und angebunden werden. Das eine schließt das andere nicht aus, sie greifen ineinander.

Model Context Protocol gegen A2A

Ein Agent-zu-Agent-Protokoll regelt, wie eigenständige Agenten miteinander sprechen. MCP regelt, wie ein Agent an Werkzeuge und Daten kommt. Große Systeme nutzen beides nebeneinander.

Model Context Protocol gegen Klassische API

Eine REST-Schnittstelle richtet sich an Programme, die genau wissen, was sie aufrufen. MCP liefert zusätzlich die Beschreibung in normaler Sprache, aus der ein Modell selbst ableitet, wann welcher Aufruf passt.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Ein Server ist ein Zugang, kein Zubehör

Ein MCP-Server läuft mit den Rechten dessen, der ihn eingerichtet hat. Wenn du einem Assistenten einen Server für das Ticketsystem gibst, bekommt er alles, was dieses Konto sehen und ändern darf, und nicht nur das eine Projekt, an das du gerade denkst. Eigene technische Konten mit engem Zuschnitt sind hier die Mühe wert.

Die Werkzeugbeschreibungen sind Text, den das Modell liest und ernst nimmt. Ein Server aus fremder Quelle kann darin Anweisungen unterbringen, die mit der eigentlichen Funktion nichts zu tun haben. Deshalb gehört jeder Server, den du einbindest, geprüft und freigegeben, so wie andere Software auch.

Und weniger ist oft mehr: Je mehr Werkzeuge gleichzeitig angemeldet sind, desto häufiger greift das Modell zum falschen. Wer Server je Aufgabe einbindet statt alle dauerhaft laufen zu lassen, bekommt verlässlichere Abläufe und kürzere Anfragen.

Model Context Protocol lernen

Wie du einen eigenen Server baust und Werkzeuge sauber beschreibst, zeigen die Trainings zum Anbinden von Werkzeugen an KI-Agenten .

Den Unterbau dafür, also Schnittstellen und Datenanbindung, behandeln die Kurse zum Bauen eigener KI-Anwendungen .

Kurse, die Model Context Protocol behandeln

Häufige Fragen

Wer steht hinter MCP?

Entwickelt und offengelegt hat es Anthropic. Seit Dezember 2025 liegt das Protokoll bei der Agentic AI Foundation, einem Projektverbund unter dem Dach der Linux Foundation, und wird dort herstellerneutral weiterentwickelt. Anthropic sitzt im zuständigen Gremium, hat dort aber kein Vetorecht. Für dich heißt das vor allem, dass ein einmal geschriebener Server nicht an einen einzelnen Anbieter gebunden ist.

Brauche ich MCP, um ein Modell an interne Systeme zu hängen?

Nicht zwingend. Eine direkte Anbindung über die eigene Anwendung funktioniert genauso. MCP lohnt sich, sobald mehrere Anwendungen oder mehrere Teams auf dieselben Systeme zugreifen sollen, weil du die Anbindung dann nur einmal pflegst.

Läuft ein MCP-Server lokal oder auf einem Server?

Beides ist vorgesehen. Lokal gestartet bleiben Zugangsdaten und Dateien auf deinem Gerät, was für den Zugriff auf ein Arbeitsverzeichnis passt. Für gemeinsam genutzte Systeme betreibst du den Server zentral und regelst die Rechte dort, samt Protokoll über alle Aufrufe.

Persönlich für dich da