Wie das Model Context Protocol es KI-Agenten ermöglicht, Tools zu entdecken und aufzurufen

Bitten Sie einen KI-Assistenten darum, „eine minimale Landing-Page in Figma für eine KI-SaaS-Anwendung namens FlowAI zu erstellen, mit dunklem Hintergrund, einem Überschriftstext, einer Call-to-Action-Taste sowie drei Feature-Karten“, und ein gut vernetzter Assistent kann das bewältigen: Er erstellt das Design in Figma, ohne dass Sie die App öffnen müssen oder jemand eine eigene Figma-Integration schreiben muss. Das erste Ergebnis dient als Ausgangspunkt, und Sie können durch das Anfordern neuer Screens oder Änderungen an der Typografie weiterarbeiten. Der gleiche Ansatz funktioniert auch bei vielen anderen Anwendungen.

Das wirft offensichtliche Fragen auf. Wie steuert ein Sprachmodell eine andere Anwendung? Ist MCP einfach nur eine weitere API? Was geschieht tatsächlich zwischen der Anfrage und dem Ergebnis – und warum wird das Protokoll so intensiv diskutiert? Dieser Artikel beantwortet jede dieser Fragen, damit Sie MCP als Ingenieur verstehen können anstatt es als Black Box zu betrachten.

Was MCP ist

MCP, das Model Context Protocol, ist eine Standardmethode dafür, dass KI-Anwendungen externe Tools entdecken und nutzen können. Im Figma-Szenario ist das einfachste Bild eine Kette: Die KI-Anwendung kommuniziert mit MCP, und MCP wiederum kommuniziert mit Figma. Man beschreibt, was man möchte, das Modell interpretiert die Anfrage, prüft, welche Tools über MCP verfügbar sind, und ruft das passende Tool auf.

Figma ist nur ein Beispiel. Über dasselbe Protokoll kann eine KI-Anwendung auf eine Datenbank, Slack, GitHub sowie praktisch jedes andere System zugreifen, das einen MCP-Server anbietet.

In diesem Kontext bedeutet ein „Tool“ einfach eine Funktion, die ein Service dem Modell zur Aufrufung zur Verfügung stellt – beispielsweise „einen Rahmen erstellen“, „Nachrichten suchen“ oder „eine Abfrage ausführen“. MCP verleiht diesen Funktionen eine einheitliche Struktur, sodass jede kompatible KI-Anwendung sie finden und nutzen kann.

Das Integrationssproblem, das MCP löst

Ohne ein gemeinsames Protokoll benötigt jede Kombination aus einer KI-Anwendung und einem Tool eigenen, maßgeschneiderten Code. Die Verbindung eines Assistenten mit Figma ist eine Integration. Die Verbindung eines zweiten Assistenten mit Figma ist eine weitere. Die Hinzufügung von Slack bedeutet wieder eine neue Integration, und eine Datenbank noch eine weitere. Die Anzahl der Integrationsmöglichkeiten steigt mit jeder Kombination aus einer Anwendung und einem Tool, wodurch deren Wartung schnell unübersichtlich wird.

Mit MCP stellt jeder Tool-Anbieter seine Funktionen einmal über das Protokoll zur Verfügung, und jede KI-Anwendung implementiert dieses Protokoll ebenfalls nur einmal. Jede kompatible Anwendung kann somit jedes kompatible Tool nutzen. Ein nützlicher Vergleich: MCP fungiert wie ein universeller Adapter zwischen KI-Modellen und den Tools, die sie benötigen.

Ist MCP ein Ersatz für APIs?

Nein. APIs werden nicht verschwinden. Figma, Stripe und Slack haben weiterhin ihre APIs, und Ihre PostgreSQL-Datenbank existiert weiterhin hinter allem, was darauf aufgebaut wird. In der Praxis sind viele MCP-Server nur dünne Schichten über bestehenden APIs.

Was sich ändert, ist die Art und Weise, wie diese Funktionen einer KI-Anwendung präsentiert und genutzt werden. Bei einer traditionellen Integration liest ein Entwickler die API-Dokumentation, wählt den richtigen Endpunkt aus, schreibt den Client-Code, kümmert sich um die Authentifizierung, sendet Anfragen und analysiert Antworten. All diese Entscheidungen werden im Voraus getroffen und im Code festgelegt.

Mit MCP kann die KI-Anwendung laufend vom Server fragen, welche Tools dieser anbietet. Ein Server für einen Online-Shop könnte beispielsweise mit Tools wie folgenden antworten:

• Produkte suchen
• Bestellung abrufen
• Rückerstattung erstellen

Jedes Tool verfügt über einen Namen, eine Beschreibung seines Zwecks sowie ein strukturiertes Eingabeschema, das vom Modell gelesen werden kann. Auf der Grundlage der Anfrage des Benutzers wählt das Modell das passende Tool aus und liefert Argumente, die dem Schema entsprechen. Die Entscheidung darüber, welche Operation durchgeführt werden soll, wechselt von im Voraus geschriebenem Code zu der Abwägung des Modells zum Zeitpunkt der Anfrage.

Die drei Bausteine: Host, Client und Server

MCP ist um drei Rollen herum organisiert.

Der Host

Der Host ist die KI-Anwendung, mit der der Benutzer tatsächlich interagiert: ein Chat-Assistent, ein KI-Programmierwerkzeug oder jede Anwendung, deren Kern ein Sprachmodell ist. Er kontrolliert das Gespräch sowie das Modell und entscheidet, welche Server das Modell nutzen darf.

Der MCP-Client

Der Client ist der Komponente innerhalb des Hosts, die die Kommunikation mit einem MCP-Server verwalten wird. Bei der Konzeption des Protokolls läuft in der Regel ein Client pro Serververbindung auf dem Host, sodass ein Assistent, der mit Figma und GitHub verbunden ist, zwei separate Client-Sessions betreibt.

Der MCP-Server

Der Server stellt Tools der KI-Anwendung zur Verfügung und verbindet sie mit echten Systemen. Wenn ein Tool aufgerufen wird, ist der Server der Teil, der tatsächlich mit Figma’s API kommuniziert, die Datenbankabfrage ausführt oder die Nachricht an Slack sendet.

Was passiert bei einem Toolaufruf

Wenn man die drei Rollen zusammen betrachtet, wird der Ablauf klar: Der Client ermöglicht es dem Host, die von einem Server angebotenen Tools zu entdecken und diese mit ordnungsgemäß strukturierten Parametern aufzurufen, sobald das Modell deren Verwendung für notwendig hält.

Es handelt sich dabei nicht um eine einmalige Anfrage, die danach vergessen wird. Es ist ein Dialog zwischen Client und Server. Zunächst werden eine Sitzung hergestellt und die Funktionalitäten vereinbart, anschließend bittet der Client um eine Liste der Tools und sendet später Toolaufrufe, um die Ergebnisse zu erhalten. Im Hintergrund werden diese Nachrichten über JSON-RPC übertragen – entweder über Standard-Eingabe/Ausgabe bei lokal laufenden Servern oder über HTTP bei entfernten Servern.

Das Sprachmodell ist es, was dies von einer herkömmlichen Integration unterscheidet. Es gibt keine fest codierten Aufrufsequenzen; das Modell liest die Toolbeschreibungen, bestimmt, welche Tools zum Ziel des Benutzers geeignet sind, und ruft sie in der Reihenfolge auf, die der Dialog erfordert.

Eine Schritt-für-Schritt-Anleitung mit einem E-Commerce-Assistenten

Betrachten wir einen Support-Assistenten für einen Online-Shop, dessen MCP-Server drei Tools bereitstellt:

• get_order

search_products

create_refund

Ein Kunde schreibt: „Wo ist meine Bestellung?“ Das Modell erkennt die Absicht, stellt fest, dass ein Tool namens get_order verfügbar ist, und entscheidet sich, dieses mit der Bestell-ID des Kunden aufzurufen. Die Anfrage wird vom Client zum Server gesendet, der anschließend die Bestelldatenbank oder die interne Orders-API abfragt und strukturierte Daten zur Bestellung zurückgibt. Das Modell wandelt diese Daten dann in eine natürliche Antwort um, zum Beispiel: „Ihre Bestellung wurde gestern versandt und sollte am Donnerstag ankommen.“

Der Kunde folgt mit den Worten nach: „Eigentlich sollte es rückerstattet werden.“ Da das Modell den Kontext des Gesprächs noch kennt, weiß es, auf welche Bestellung sich „es“ bezieht. Es erkennt, dass create_refund verfügbar ist, und ruft es mit denselben Bestelldaten auf. Falls der Server auch ein Tool wie notify_finance bereitstellt, könnte das Modell diesen Schritt ebenfalls in den Workflow aufnehmen.

Diese Aufteilung der Arbeit ist die Kernidee von MCP. Das Modell entscheidet, welches Tool verwendet werden soll und mit welchen Argumenten. Der Server führt die eigentliche Operation aus. In einem Produktivsystem würde man diesem Ablauf noch ein weiteres Element hinzufügen: Eine Rückerstattung ist eine folgenreiche, irreversible Aktion, weshalb viele Teams vor der Ausführung eine ausdrückliche Bestätigung des Benutzers oder Serverseitige Richtlinienprüfungen verlangen, anstatt allein auf das Urteil des Modells zu vertrauen.

Was MCP Ihnen bietet

Drei Vorteile heben sich hervor.

1. Standardisierung: KI-Anwendungen interagieren auf eine einheitliche Weise mit externen Tools, anstatt für jede Integration ein anderes Muster zu verwenden.
2. Flexibilität: Das Modell entdeckt verfügbare Tools und liest deren Schemata direkt, sodass Sie keine Funktion mehr manuell in einem umfangreichen Systemprompt beschreiben müssen.
3. Wiederverwendbarkeit: Ein MCP-Server wird einmal erstellt und kann anschließend viele kompatible KI-Anwendungen bedienen.

Was MCP nicht kann

Es ist hilfreich, genau über die Grenzen Bescheid zu wissen, denn der Hype um das Protokoll kann diese verschwimmen lassen.

• MCP ist kein Wundermittel und macht eine zugrunde liegende API nicht leistungsfähiger, als sie bereits ist.

Es macht ein KI-System nicht zuverlässig. Das Modell kann immer noch das falsche Tool wählen oder falsche Argumente übergeben, weshalb Validierung sowie sinnvolle Fehlerbehandlung auf dem Server weiterhin unerlässlich sind.

Es beseitigt keine Probleme im Bereich Authentifizierung oder Sicherheit. Server benötigen weiterhin Zugangsdaten, Zugriffskontrolle und Audits, und die Ausgaben der Tools können unzuverlässigen Inhalt enthalten, der versucht, das Modell zu beeinflussen.

Das bedeutet nicht, dass jedes interne System einem KI-Agenten zugänglich gemacht werden sollte. Gewähren Sie nur den kleinstmöglichen Satz an Tools und Berechtigungen, die ein bestimmter Anwendungsfall tatsächlich benötigt.

KI, die eine API aufruft, ist nichts Neues; Entwickler verbinden bereits seit Jahren Modelle mit APIs. Was MCP hinzufügt, ist eine standardisierte Schnittstelle, über die ein Modell viele verschiedene Tools entdecken und nutzen kann, ohne für jedes eine eigene Integration erstellen zu müssen.

Haupterkenntnisse

• MCP ist ein Protokoll zur Verbindung von KI-Anwendungen mit Tools. Es baut auf APIs auf, anstelle sie zu ersetzen.
• Server stellen Tools zusammen mit Beschreibungen und Eingabeschemata bereit; der Host sowie seine Clients kümmern sich um die Erkennung und Kommunikation.
• Das Modell entscheidet, welches Tool aufgerufen werden soll und mit welchen Argumenten; der Server führt die eigentliche Operation aus.
• Durch Standardisierung wird ein zunehmendes Netzwerk an einmaligen Integrationen in Komponenten umgewandelt, die nur einmal entwickelt und anschließend wiederverwendet werden.
• Zu Ihrer Verantwortung gehören Zuverlässigkeit, Authentifizierung, Minimierung von Berechtigungen sowie die Bestätigung riskanter Aktionen.

Falls Sie gerade anfangen, beginnen Sie damit, bestehende MCP-Server wie die von GitHub, Slack oder Figma mit einem Assistenten zu verbinden, den Sie bereits nutzen, und beobachten Sie, wie das Modell Werkzeuge auswählt. Sobald der Nutzen klar ist, ist es der natürliche nächste Schritt, Ihren eigenen Server für eine interne Datenbank oder Dienst zu erstellen. Um zu sehen, wie MCP in größere Agent-Frameworks passt, lesen Sie unseren Artikel über die Standardisierung der Werkzeugintegration in LangGraph mit MCP.