Was ist ein MCP-Server? Wann REST/OpenAPI reicht – und wann MCP für KI-Agenten sinnvoll ist

Das Problem: Ein Agent, der nichts tun kann

Das Model Context Protocol (MCP) ist ein offenes Protokoll von Anthropic, das standardisiert, wie LLM-Anwendungen auf externe Datenquellen und Werkzeuge zugreifen. Es löst ein konkretes Problem: Sprachmodelle wie GPT-4, Claude oder Mistral können Sprache verstehen und generieren, aber sie haben keinen Zugriff auf eure Systeme. Ohne externe Anbindung können sie keinen Kalender abfragen, keinen Termin buchen, keine Kundendaten nachschlagen.

Damit ein KI-Agent tatsächlich handeln kann, braucht er eine Schnittstelle zur Außenwelt. Diese Schnittstelle muss dem Agenten erklären, welche Werkzeuge es gibt, und ihm erlauben, diese Werkzeuge aufzurufen. Genau das ist die Aufgabe eines MCP-Servers.

Was MCP umfasst

MCP definiert drei zentrale Primitive, die ein Server anbieten kann:

Tools — Funktionen, die der Agent aktiv aufruft. Verfügbarkeit prüfen, Termin buchen, Kundendaten anlegen. Der Agent entscheidet eigenständig, welches Werkzeug er wann einsetzt.

Resources — Datenquellen, die der Agent lesen kann. Kontextinformationen wie Öffnungszeiten, Dienstleistungskataloge oder Kundendaten, die der Agent für seine Entscheidungen braucht.

Prompts — Vorgefertigte Prompt-Templates, die der Server bereitstellt. Nützlich für standardisierte Abläufe, die der Client direkt verwenden kann.

In der Praxis sind Tools der häufigste Einstiegspunkt. Unser MCP-Server für FloviAi nutzt primär Tools — aber das Protokoll ist breiter angelegt.

Wann REST/OpenAPI reicht — und wann nicht

REST-APIs mit OpenAPI-Spezifikation können vieles, was MCP auch kann: maschinenlesbare Schemas, Parameter-Validierung, Endpunkt-Discovery. OpenAPI beschreibt HTTP-APIs ausdrücklich so, dass Menschen und Computer die Fähigkeiten eines Dienstes entdecken und verstehen können. Für Anwendungen mit festem Ablauf ist das völlig ausreichend.

Der Unterschied liegt in der Zielgruppe. OpenAPI ist für Entwickler geschrieben, die den Client-Code vorher festlegen. MCP ist für LLM-Anwendungen gebaut, die den Ablauf erst zur Laufzeit bestimmen. Drei Punkte machen den Unterschied konkret:

Modellzentrierte Discovery. Nach der Initialisierung und Capability-Negotiation kann ein MCP-Client verfügbare Tools über tools/list entdecken und sie über tools/call aufrufen. Das ist ein standardisierter Ablauf, der direkt auf LLM-Clients ausgerichtet ist. Bei OpenAPI muss ein Entwickler die Endpunkte in den Agenten-Code einbinden — möglich, aber nicht standardisiert für den Agenten-Kontext.

Natürlichsprachliche Beschreibungen. Ein OpenAPI-Endpunkt wie /api/v1/calendar/slots hat eine technische Beschreibung für Entwickler. MCP-Werkzeuge haben eine Beschreibung, die auf Sprachmodelle optimiert ist: "Gibt verfügbare Zeitfenster für einen Salon zurück. Muss vor einer Buchung aufgerufen werden." Das Modell liest diese Beschreibung und entscheidet, ob das Werkzeug zur aktuellen Anfrage passt.

Ein Protokoll für Tools, Resources und Prompts. MCP bündelt den modellzentrierten Zugriff auf Werkzeuge, Datenquellen und Prompt-Templates in einem Protokoll. Bei REST müsste man das aus mehreren Endpunkten und Konventionen zusammenbauen.

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 MCP-Client verbindet sich mit dem Server, durchläuft die Initialisierung (initialize) und fragt dann über tools/list die verfügbaren Werkzeuge 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 und Mitarbeitername. In unserer Implementierung ergänzen wir zusätzlich einen Relevanz-Score — das ist keine MCP-Vorgabe, sondern unsere Serverlogik, die dem Agenten hilft, die besten Optionen zu priorisieren. 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 ruft jetzt create_appointment über tools/call auf, ü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/OpenAPI: Eine Einordnung

MCP ersetzt keine REST-APIs. In der Praxis sitzt MCP meist vor bestehenden Systemen und macht deren Funktionen für LLM-Anwendungen standardisiert nutzbar. Wenn ein Mensch oder eine App den Kalender abfragt, ist eine REST-API die richtige Wahl. Wenn ein KI-Agent den Kalender abfragen soll, standardisiert MCP den Zugriff.

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"), können bestehende Agenten es über tools/list entdecken — vorausgesetzt, die Werkzeug-Beschreibung ist klar genug formuliert, damit das Sprachmodell versteht, wann es das Werkzeug einsetzen soll.

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. Die aktuelle MCP-Spezifikation definiert dafür ein optionales Authorization-Framework für HTTP-basierte Transports auf Basis von OAuth 2.1, inklusive Protected Resource Metadata und standardisierten Discovery-Mechanismen. Für andere Transports (z.B. stdio) gelten andere Regeln — aber für produktive Web-Deployments ist OAuth der vorgesehene Weg.

Authentifizierung. In unserer Implementierung prüft der MCP-Server bei jeder Anfrage über ein JWT-Token: Gehört dieser Salon zum anfragenden Mandanten? Darf dieser Agent auf diese Daten zugreifen?

Human-in-the-loop. Die MCP-Spezifikation betont ausdrücklich, dass Tool-Aufrufe aus Trust-&-Safety-Sicht transparent sein sollten. Ein produktiver MCP-Client sollte dem Nutzer die Möglichkeit geben, kritische Aktionen zu sehen und abzulehnen, bevor sie ausgeführt werden. Das ist besonders bei Buchungen oder Stornierungen relevant.

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. Das ist keine MCP-Vorgabe, sondern Best Practice für jeden produktiven Server.

Wie wir MCP einsetzen

In FloviAi nutzen wir einen MCP-Server als Schnittstelle zwischen unserem KI-Telefonassistenten und dem Kalendersystem. Der Agent hat drei Tools: 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 tools/call, dass der Agent nur auf die Daten des richtigen Salons zugreift.

Häufige Fragen zu MCP

Was ist der Unterschied zwischen MCP und einer REST-API?

REST/OpenAPI beschreibt HTTP-APIs für Entwickler und Anwendungen. MCP standardisiert den modellzentrierten Zugriff auf Tools, Resources und Prompts für LLM-Anwendungen. MCP ersetzt REST nicht — es sitzt in der Praxis meist davor und macht bestehende Systeme für KI-Agenten nutzbar.

Ist MCP ein offizieller Standard?

MCP ist ein offenes Protokoll, das Anthropic 2024 veröffentlicht hat. Es ist kein ISO- oder W3C-Standard, hat aber breite Adoption in der LLM-Ökosystem erreicht. Die Spezifikation ist öffentlich und wird aktiv weiterentwickelt.

Wie sicher ist MCP?

Für HTTP-basierte Transports definiert die Spezifikation ein Authorization-Framework auf Basis von OAuth 2.1. Zusätzlich empfiehlt die Spezifikation Human-in-the-loop-Kontrollen, damit kritische Tool-Aufrufe vom Nutzer bestätigt werden können. Die konkrete Absicherung (Mandantentrennung, Idempotenz) liegt beim Server-Implementierer.

Wann brauche ich einen MCP-Server?

Wenn ein KI-Agent zur Laufzeit entscheiden soll, welche Werkzeuge er in welcher Reihenfolge nutzt. Wenn der Ablauf feststeht und nur Apps oder Menschen die API nutzen, reicht REST/OpenAPI.

Fazit

MCP ist kein Ersatz für REST-APIs. Es ist eine zusätzliche Schicht, die den modellzentrierten Zugriff auf externe Werkzeuge, Datenquellen und Prompt-Templates standardisiert. Nach Initialisierung und Capability-Negotiation kann ein Agent verfügbare Tools entdecken und aufrufen, ohne dass jemand den Ablauf vorher festcodiert.

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.