Das Problem: Ein Agent, der nichts tun kann
Sprachmodelle wie GPT-4, Claude oder Mistral sind gut darin, Sprache zu verstehen und zu generieren. Aber sie haben keinen Zugriff auf eure Systeme. Sie können keinen Kalender abfragen, keinen Termin buchen, keine Kundendaten nachschlagen. Ohne externe Werkzeuge sind sie auf das beschränkt, was in ihren Trainingsdaten steckt.
Damit ein KI-Agent tatsächlich handeln kann, braucht er eine Schnittstelle zur Außenwelt. Diese Schnittstelle muss zwei Dinge leisten: Dem Agenten erklären, welche Werkzeuge es gibt. Und ihm erlauben, diese Werkzeuge aufzurufen.
Genau das ist die Aufgabe eines MCP Servers.
MCP in einem Satz
Das Model Context Protocol (MCP) ist eine standardisierte Schnittstelle, über die KI-Agenten externe Werkzeuge entdecken und aufrufen können. Jedes Werkzeug beschreibt sich selbst: Was es tut, welche Parameter es braucht und was es zurückgibt. Der Agent liest diese Beschreibungen und entscheidet eigenständig, welches Werkzeug er wann einsetzt.
Warum nicht einfach eine REST-API?
REST-APIs funktionieren gut für Anwendungen, die von Menschen entwickelt wurden. Ein Entwickler liest die Dokumentation, versteht die Endpunkte und schreibt Code, der sie aufruft. Das Programm weiß vorher, in welcher Reihenfolge welche Endpunkte aufgerufen werden.
Bei KI-Agenten ist das anders. Der Agent entscheidet erst im Gespräch, was er tun muss. Er folgt keinem festen Ablauf, sondern reagiert auf das, was der Nutzer sagt. Dafür braucht er drei Dinge, die eine klassische REST-API nicht bietet:
Werkzeug-Erkennung. Der Agent muss wissen, welche Werkzeuge verfügbar sind, ohne dass das jemand vorher festcodiert. Bei MCP fragt der Agent einen Schema-Endpunkt ab und bekommt eine Liste aller Werkzeuge mit Beschreibungen. Bei einer REST-API müsste ein Entwickler für jedes neue Werkzeug den Agenten-Code anpassen.
Semantische Beschreibungen. Ein REST-Endpunkt wie /api/v1/calendar/slots?salon=123&date=2026-01-10 sagt einem Entwickler, was er tut. Ein Sprachmodell versteht das nicht zuverlässig. MCP-Werkzeuge haben eine natürlichsprachliche Beschreibung: "Gibt verfügbare Zeitfenster für einen Salon zurück." Das Modell liest diese Beschreibung und entscheidet, ob das Werkzeug zur aktuellen Anfrage passt.
Strukturierte Validierung. MCP definiert Parameter über Schemas. Der Agent kann nicht einfach beliebige Werte schicken. Wenn ein Pflichtfeld fehlt oder ein Datumsformat falsch ist, wird die Anfrage abgelehnt, bevor sie das Backend erreicht. Das verhindert Fehler, die bei einer offenen API leicht passieren.
Wie ein Agent MCP-Werkzeuge nutzt
Nehmen wir ein konkretes Beispiel. Ein Kunde ruft an und sagt: "Ich brauche morgen einen Haarschnitt bei Anna."
Schritt 1: Werkzeuge entdecken
Der Agent kennt den MCP Server und fragt dessen Schema ab. Er bekommt zurück:
- check_availability: Gibt verfügbare Zeitfenster zurück. Parameter: Salon, Datum, Dauer, optionaler Mitarbeiterwunsch.
- create_appointment: Legt einen Termin an. Parameter: Salon, Mitarbeiter, Startzeit, Kundenname.
- cancel_appointment: Storniert einen bestehenden Termin.
Schritt 2: Intent erkennen und Werkzeug wählen
Der Agent versteht: Der Kunde will einen Termin buchen. Dafür muss er zuerst prüfen, ob Anna morgen frei hat. Er wählt check_availability.
Schritt 3: Parameter extrahieren und Werkzeug aufrufen
Aus dem Satz "morgen einen Haarschnitt bei Anna" extrahiert der Agent: Datum = morgen, Dienstleistung = Haarschnitt (30 Minuten), Mitarbeiterin = Anna. Er ruft check_availability mit diesen Parametern auf.
Schritt 4: Ergebnis interpretieren
Der MCP Server antwortet mit einer Liste freier Zeitfenster. Jedes Ergebnis enthält Startzeit, Mitarbeitername und einen Relevanz-Score. Der Agent formuliert daraus: "Anna hat morgen um 10:00 Uhr und um 15:00 Uhr Zeit. Was passt besser?"
Schritt 5: Aktion ausführen
Der Kunde sagt "15 Uhr". Der Agent wählt jetzt create_appointment, übergibt die bestätigten Parameter und bucht den Termin. Der MCP Server antwortet mit einer Bestätigung.
Das Entscheidende: Der Agent hat den Ablauf nicht vorher gewusst. Er hat die Werkzeuge gelesen, die Situation verstanden und die richtige Reihenfolge selbst bestimmt. Wenn der Kunde stattdessen gesagt hätte "Ich muss meinen Termin absagen", hätte der Agent cancel_appointment gewählt, ohne dass jemand diesen Pfad vorher programmiert hat.
Was eine gute Werkzeug-Beschreibung ausmacht
Die Beschreibung eines MCP-Werkzeugs bestimmt, ob der Agent es korrekt einsetzt. Zwei Beispiele:
Schlecht: "Kalender-Endpunkt für Daten." Der Agent weiß nicht, ob er damit Verfügbarkeit prüfen, Termine anlegen oder Öffnungszeiten abfragen soll.
Gut: "Gibt verfügbare Zeitfenster für einen Salon zurück, basierend auf Datum, Dienstleistungsdauer und optionalem Mitarbeiterwunsch. Muss vor einer Buchung aufgerufen werden." Der Agent weiß genau, was das Werkzeug tut und wann er es braucht.
Die Beschreibung ist keine technische Dokumentation für Entwickler. Sie ist eine Anweisung für das Sprachmodell. Klarheit schlägt Vollständigkeit.
MCP vs. REST-API: Eine Einordnung
| Aspekt | REST-API | MCP |
|---|---|---|
| Zielgruppe | Entwickler und Apps | KI-Agenten |
| Werkzeug-Erkennung | Manuell (Docs lesen, Swagger) | Automatisch (Schema-Abfrage) |
| Beschreibungen | Für Menschen (OpenAPI-Spec) | Für Sprachmodelle (natürlichsprachlich) |
| Entscheidungslogik | Im Client-Code festgelegt | Vom Sprachmodell bestimmt |
| Neue Werkzeuge | Client-Code muss angepasst werden | Agent erkennt sie automatisch |
| Validierung | Optional, oft erst im Backend | Schema-basiert, vor Ausführung |
| Ergebnis-Format | Frei (JSON, XML, Text) | Strukturiert mit Metadaten für LLM-Interpretation |
MCP ersetzt keine REST-APIs. Es ergänzt sie. Wenn ein Mensch oder eine App den Kalender abfragt, ist eine REST-API die richtige Wahl. Wenn ein KI-Agent den Kalender abfragen soll, braucht er MCP.
Wann MCP Sinn ergibt
MCP lohnt sich, wenn mindestens zwei dieser Bedingungen zutreffen:
Mehrere Agenten greifen auf dieselben Werkzeuge zu. Ein Telefonassistent, ein Chatbot und ein E-Mail-Agent brauchen alle Zugriff auf den Kalender. Statt drei separate Integrationen zu schreiben, definiert ein MCP Server die Werkzeuge einmal. Alle Agenten lesen dasselbe Schema.
Werkzeuge ändern sich oder kommen hinzu. Wenn ihr nächsten Monat ein neues Werkzeug hinzufügt (z.B. "Warteliste verwalten"), erkennen bestehende Agenten es automatisch über das Schema. Kein Agent-Code muss angepasst werden.
Agenten sollen Entscheidungen treffen, nicht Abläufe abarbeiten. Wenn der Ablauf feststeht (immer Schritt 1, dann Schritt 2, dann Schritt 3), reicht eine API mit festcodiertem Client. Wenn der Agent je nach Gesprächsverlauf unterschiedliche Werkzeuge in unterschiedlicher Reihenfolge nutzen muss, braucht er MCP.
Wann eine einfache API reicht
MCP ist kein Allheilmittel. In diesen Situationen reicht eine REST-API:
- Nur menschliche Nutzer oder Apps konsumieren die Schnittstelle.
- Der Ablauf ist fest und ändert sich selten.
- Es gibt nur einen Client, der die API nutzt.
- Keine KI-Agenten im Spiel.
MCP einzuführen, wo es keine Agenten gibt, ist Overengineering.
Sicherheit und Mandantentrennung
Ein MCP Server, der einem KI-Agenten Zugriff auf Kundendaten oder Buchungssysteme gibt, muss sicher sein. Das Protokoll selbst schreibt keine Authentifizierung vor, aber in der Praxis ist sie unverzichtbar.
Jede Werkzeug-Anfrage sollte authentifiziert sein, typischerweise über ein JWT-Token. Der MCP Server prüft bei jeder Anfrage: Gehört dieser Salon zum anfragenden Mandanten? Darf dieser Agent auf diese Daten zugreifen?
Genauso wichtig: Idempotenz. Wenn eine Buchungsanfrage durch einen Netzwerkfehler zweimal gesendet wird, darf nur ein Termin entstehen. Ein optionaler Idempotenz-Schlüssel in der Anfrage verhindert Doppelbuchungen bei Wiederholungsversuchen.
Wie wir MCP einsetzen
In FloviAi nutzen wir einen MCP Server als Schnittstelle zwischen unserem KI-Telefonassistenten und dem Kalendersystem. Der Agent hat drei Werkzeuge: Verfügbarkeit prüfen, Termin buchen, Termin stornieren. Die Werkzeug-Beschreibungen sind so formuliert, dass der Agent die richtige Reihenfolge selbst erkennt.
Das Ergebnis: Der Agent kann Termine buchen, ohne dass wir den Ablauf vorher festcodieren. Wenn ein Kunde mitten im Gespräch seine Meinung ändert ("Doch lieber nächste Woche"), passt sich der Agent an und ruft die Verfügbarkeitsprüfung erneut auf. Das wäre mit einem fest programmierten Workflow deutlich aufwendiger.
Gleichzeitig bleibt die Mandantentrennung gewahrt: Jeder Salon auf der Plattform hat seinen eigenen Datenbereich, und der MCP Server validiert bei jedem Werkzeugaufruf, dass der Agent nur auf die Daten des richtigen Salons zugreift.
Fazit
MCP ist kein Ersatz für REST-APIs. Es ist eine zusätzliche Schicht, die KI-Agenten handlungsfähig macht. Werkzeuge beschreiben sich selbst, Agenten entscheiden eigenständig, welches Werkzeug sie wann einsetzen, und ein standardisiertes Schema sorgt dafür, dass Validierung, Sicherheit und Mandantentrennung nicht dem Zufall überlassen werden.
Wer KI-Agenten baut, die mehr tun sollen als Text generieren, kommt um ein Protokoll wie MCP nicht herum. Wer keine Agenten baut, braucht es nicht.