MCP (Model Context Protocol): Definition, Funktionsweise und Beispiele

Ein KI-Agent, der nur mit sich selbst sprechen kann, nützt wenig. Um wirklich zu handeln, muss er Ihre Dateien lesen, Ihre Datenbanken abfragen, in Ihre Werkzeuge schreiben. MCP ist das Protokoll, das entstanden ist, um diese Verbindung zu standardisieren, statt sie bei jedem neuen Werkzeug neu zu erfinden.

Definition im Detail

Die offizielle Website des Protokolls definiert es so: MCP ist "ein offener Standard, um KI-Anwendungen mit externen Systemen zu verbinden", der ihnen Zugriff auf Datenquellen (lokale Dateien, Datenbanken), Werkzeuge (Suchmaschinen, Rechner) und Workflows (spezialisierte Prompts) verschafft. Die eigene Dokumentation fasst die Idee mit einem einfachen Bild zusammen: MCP ist wie ein USB-C-Anschluss für KI-Anwendungen, ein standardisierter Anschluss statt eines unterschiedlichen Kabels für jedes Gerät.

Das Protokoll wurde von Anthropic am 25. November 2024 angekündigt. Die Ankündigung beschreibt das Problem, das MCP lösen soll: KI-Assistenten blieben von eigentlich entscheidenden Daten isoliert, jede neue Quelle erforderte eine maßgeschneiderte Implementierung, was ein Integrationsproblem schuf, das sich mit jedem neuen Werkzeug und jedem neuen Modell vervielfachte. Anthropic veröffentlichte gleichzeitig die Spezifikation, Entwicklungskits und ein Repository mit MCP-Referenzservern für Werkzeuge wie Google Drive, Slack, GitHub, Git oder Postgres. Siehe Anthropics Ankündigung.

IBM bietet eine ergänzende technische Formulierung: MCP ist "eine Standardisierungsschicht, die es KI-Anwendungen ermöglicht, effizient mit externen Diensten zu kommunizieren, etwa Werkzeugen, Datenbanken oder vordefinierten Prompt-Vorlagen". Diese Beschreibung betont einen oft vergessenen Punkt: MCP sagt einem Agenten nicht, wann er ein Werkzeug nutzen soll, noch wie er mehrere Schritte orchestriert. Es standardisiert nur, wie sich das Werkzeug beschreibt und verbindet. Siehe den IBM-Beitrag zu MCP.

So funktioniert es

MCP folgt einer Client-Server-Architektur mit drei Rollen, detailliert beschrieben von der offiziellen Dokumentation und von Microsoft in seiner .NET-Doku übernommen. Der MCP-Host (MCP host) ist die KI-Anwendung selbst, etwa ein Assistent oder ein Code-Editor. Er erstellt für jeden Dienst, mit dem er sich verbindet, einen dedizierten MCP-Client. Jeder Client hält eine Verbindung zu einem MCP-Server, dem Programm, das tatsächlich Daten oder Aktionen bereitstellt. Ein MCP-Server kann lokal auf dem Rechner des Nutzers laufen oder entfernt auf den Servern des Werkzeuganbieters.

Konkret stellt ein MCP-Server drei Arten von Elementen bereit: Werkzeuge (Aktionen, die der Agent auslösen kann, etwa eine Datenbank abfragen oder eine Nachricht senden), Ressourcen (abrufbare Daten, etwa der Inhalt einer Datei) und Prompts (wiederverwendbare Anfragevorlagen). Der Client fragt zunächst beim Server ab, was er anbietet, und kann dann ein bestimmtes Werkzeug mit bestimmten Argumenten aufrufen, eine Funktionsweise nahe der, die unser Artikel zum Tool-Calling beschreibt.

Genau hier weichen die Quellen bei der genauen Reichweite von MCP voneinander ab. IBM und Microsoft sind sich einig, dass MCP das Tool-Calling nicht ersetzt: Das bleibt der darunterliegende Mechanismus, über den ein Modell konkret die Ausführung einer Aktion anfordert. Was MCP hinzufügt, ist eine gemeinsame Art, diese Werkzeuge zu beschreiben und zu entdecken, unabhängig vom Modellanbieter, wo zuvor jeder Anbieter sein eigenes Aufrufformat vorschrieb. Ebenso ersetzt MCP nicht die klassischen APIs: Microsofts .NET-Doku präzisiert, dass ein MCP-Server "eine Abstraktion über einer REST-API bereitstellen kann", um einem Modell Geschäftsdaten zugänglich zu machen. MCP ist also eine gemeinsame Fassade über bestehenden APIs, keine Technologie, die sie überflüssig macht.

Ein MCP-Server kann auch eine Dokumentenbasis bereitstellen, die vor der Antwort durchsucht wird, ein Anwendungsfall, der sich direkt mit dem Prinzip von RAG überschneidet: zuerst in einer zuverlässigen Quelle suchen, dann die Antwort aus dem Gefundenen generieren.

Konkretes Beispiel bei Atako

Der Standard-Plan von Atako listet "Atako MCP" unter seinen inkludierten Funktionen auf, neben den Integrationen, der Observability oder BYOK, auf der Seite Preise. Ein in den Kontoeinstellungen generierter API-Schlüssel dient unter anderem dazu, externe MCP-Clients mit der Plattform zu verbinden.

Der Rest der genauen Umsetzung, welche Server, welche Werkzeuge im Detail bereitgestellt werden, ist bis heute nicht öffentlich dokumentiert. Bei diesem Punkt bleibt man besser sachlich, statt eine Werkzeugliste oder ein Startdatum zu erraten.

Häufige Fehler

Erster Fehler: glauben, MCP sei ein völlig neuer Mechanismus, der das Tool-Calling ersetze. Das ist nicht der Fall, MCP standardisiert die Beschreibung und Entdeckung von Werkzeugen, aber der Aufruf selbst bleibt ein klassischer, vom Modell erzeugter Funktionsaufruf.

Zweiter Fehler: denken, ein "MCP-Server" bezeichne zwangsläufig eine große entfernte Maschine. Die offizielle Dokumentation unterscheidet klar zwischen lokalen Servern, die auf dem Rechner des Nutzers laufen und lokal kommunizieren, und entfernten Servern, die beim Anbieter des Werkzeugs gehostet werden und über HTTP erreichbar sind.

Dritter Fehler: MCP mit einer Sicherheitsgarantie an sich verwechseln. Das Protokoll standardisiert, wie ein Modell ein Werkzeug entdeckt und aufruft, es entscheidet nicht an seiner Stelle über die diesem Werkzeug gewährten Berechtigungen. Auf einer seriösen Plattform bleibt diese Entscheidung eine getrennte Schicht, unabhängig vom verwendeten Verbindungsprotokoll.

Vierter Fehler: glauben, jedes mit einem Agenten verbundene Werkzeug laufe zwangsläufig über MCP. Viele Agenten, auch solche, die Integrationen wie GitHub oder Slack nutzen, rufen Aktionen über klassisches Tool-Calling auf, ohne einen dedizierten MCP-Server zu durchlaufen. Atako dokumentiert nicht öffentlich das Detail der Werkzeuge, die sein eigenes MCP bereitstellt: MCP bleibt eine Verbindungsoption unter mehreren, kein zwingender Weg, um einem Agenten Werkzeuge zu geben.

Weiterführend

MCP hat sich recht schnell als ein von einem breiten Ökosystem getragener Standard etabliert: Die offizielle Dokumentation nennt Anwendungen wie Claude oder Code-Editoren wie Visual Studio Code und Cursor unter den kompatiblen MCP-Clients. Um die benachbarten Bausteine dieses Protokolls zu verstehen, geht es zum vollständigen Glossar, mit den Begriffen Tool-Calling, RAG und BYOK, allesamt Mechanismen zur Verbindung oder Konfiguration auf Modellseite.