MCP vs. OpenAPI: Wofür welcher Standard da ist
Die kurze Antwort: OpenAPI beschreibt eine HTTP-API, damit Entwickler und Code-Generatoren dagegen bauen können. MCP verpackt die Fähigkeiten eines Dienstes so, dass ein KI-Modell sie zur Laufzeit nutzen kann. Bei MCP vs. OpenAPI geht es nicht darum, wer gewinnt, sondern welches Publikum du bedienst: Menschen und Tooling zur Build-Zeit, oder ein Modell mitten in einer Aufgabe.
Die Unterscheidung zählt, weil gerade eine verführerische Abkürzung herumgeht: "Unsere API hat doch eine OpenAPI-Spec, wir geben die Spec einfach dem Modell und lassen es HTTP-Aufrufe machen." Klingt effizient. In der Praxis verbrennt es Kontext, scheitert an der Authentifizierung und produziert einen Agenten, der technisch jeden Endpunkt sieht und praktisch keinen davon gut nutzt.
Wofür OpenAPI wirklich da ist
OpenAPI (früher Swagger) ist ein maschinenlesbarer Vertrag für eine HTTP-API. Es listet jeden Pfad, jede Methode, jeden Parameter, jeden Request-Body, jedes Response-Schema und jeden Fehlercode, plus das Auth-Schema der API. Diese Vollständigkeit ist der Zweck. Ein Code-Generator braucht jedes Feld für einen typisierten Client, eine Doku-Seite braucht jeden Endpunkt, ein Validator braucht jedes Schema, um Fehler vor dem Release zu fangen.
Das Publikum sind Entwickler und Build-Tooling. Niemand erwartet, dass ein Mensch eine Spec-Datei mit tausenden Zeilen YAML von oben bis unten liest. Maschinen konsumieren sie und machen etwas Brauchbares daraus.
Wofür MCP da ist
MCP, das Model Context Protocol, ist ein offener Standard, der KI-Agenten mit Tools verbindet. Ein MCP-Server bietet eine Liste von Tools an, jedes mit Namen, einer für das Modell geschriebenen Beschreibung und einem Eingabe-Schema. Der Client des Agenten holt die Liste, das Modell wählt ein Tool, und der Server führt den Aufruf aus und liefert ein Ergebnis, mit dem das Modell arbeiten kann.
Zwei Design-Entscheidungen trennen das von einer Spec-Datei. Erstens ist es ein Laufzeit-Protokoll: Das Modell entdeckt, was es kann, genau in dem Moment, in dem es das braucht, und die Tool-Liste kann sich zwischen Sessions ändern, ohne dass jemand den Agenten umkonfiguriert. Zweitens ist es kuratiert: Ein guter Server bietet acht aufgabenförmige Tools an, nicht zweihundert Endpunkte. Falls dir die Server-Seite neu ist, starte mit [Was ist ein MCP-Server?](/de/blog/what-is-an-mcp-server).
Warum "gib dem Modell einfach die Spec" scheitert
Es verbrennt Kontext. Eine OpenAPI-Spec ist absichtlich vollständig, und vollständig ist zur Inferenz-Zeit teuer. Angenommen, eine Spec dokumentiert 200 Endpunkte und jeder kostet im Schnitt 300 Tokens an Pfaden, Parametern und Schemas. Das sind 60.000 Tokens API-Beschreibung im Kontextfenster, bevor das Modell ein Wort deiner eigentlichen Aufgabe liest, und die meisten Aufgaben berühren drei oder vier Endpunkte. Den Rest bezahlst du trotzdem, bei jedem Schritt. Dieselbe Logik gilt übrigens innerhalb von MCP, weshalb [weniger in den Kontext laden](/de/blog/reduce-mcp-token-usage) auch dort zählt.
Es scheitert an Auth. Die Spec sagt dem Modell, dass die API OAuth 2.0 mit bestimmten Scopes nutzt. Sie kann den Autorisierungs-Flow nicht ausführen, das Token nicht speichern, es nicht erneuern, wenn es abläuft, und das Geheimnis nicht aus dem Transkript heraushalten. Ein Modell, das YAML liest, weiß, wie man sich authentifizieren müsste. Es hat keinen Weg, es zu tun. Ein MCP-Server besitzt dieses Problem: Zugangsdaten leben serverseitig, und das Modell ruft Tools auf, die bereits authentifiziert ankommen.
Es beschreibt Requests, keine Arbeit. Selbst mit der vollen Spec im Kontext muss das Modell rohes HTTP korrekt komponieren: Pagination, Rate Limits, Retries, einen Lookup-Aufruf in einen Update-Aufruf verketten. Jeder dieser Schritte ist eine Fehlerchance. Ein MCP-Tool kapselt die Sequenz stattdessen. Das Modell ruft ein Such-Tool mit einem Suchstring auf, und der Server kümmert sich um Query-Parameter, Cursor und Rate-Limit-Antworten.
MCP vs. OpenAPI im Überblick
Wer API-Spec vs. MCP für Agenten-Zugriff abwägt, hat diese Aufteilung vor sich.
| OpenAPI | MCP | |
|---|---|---|
| Was es ist | Ein Beschreibungs-Dokument | Ein Laufzeit-Protokoll |
| Gebaut für | Entwickler, Codegen, Doku-Tooling | KI-Modelle und Agenten-Clients |
| Konsumiert zur | Build-Zeit | Inferenz-Zeit |
| Abdeckung | Jeder Endpunkt, vollständig | Kuratierte Tools, selektiv |
| Auth | Dokumentiert das Schema | Führt den Login aus und verwaltet ihn |
| Ergebnis-Handling | Sache deines Client-Codes | Der Server formt Ergebnisse fürs Modell |
Sie ergänzen sich
Hier ist der Teil, den das "versus" versteckt: Viele MCP-Server sind Wrapper um OpenAPI-beschriebene APIs, und das ist ein gesundes Muster. Die Spec ist der bestmögliche Input für den Bau eines Servers. Sie liefert dir Endpunkte, Schemas und Auth-Anforderungen. Dein Job ist, sie auf eine Handvoll Tools einzudampfen, die ein Agent wirklich nutzen kann, Beschreibungen zu schreiben, auf die ein Modell handeln kann, und Zugangsdaten sauber zu behandeln.
Wenn du also eine API besitzt: Behalte die OpenAPI-Spec, deine menschlichen Entwickler brauchen sie weiter. Setz für Agenten einen MCP-Server obendrauf. Und auf der Nutzerseite: Prüf, ob das Tool, das du willst, schon einen mitbringt, bevor du zur rohen Spec greifst. Das [kuratierte MCP-Verzeichnis](/de/discover) zeigt den MCP-Status pro Listing, der Check dauert eine Minute.
Den breiteren Vergleich des Protokolls mit klassischen HTTP-APIs, über das Spec-Format hinaus, findest du in [MCP vs. API](/de/blog/mcp-vs-api).
Häufige Fragen
Kann ich einen MCP-Server aus einer OpenAPI-Spec generieren?
Ja, und Generatoren sind ein vernünftiger Startpunkt. Aber ein Eins-zu-eins-Mapping von Endpunkten auf Tools baut das Kontext-Problem in MCP nach: Aus 200 Endpunkten werden 200 Tool-Definitionen, die das Modell in jeder Session lädt. Generieren, dann kürzen. Behalte die Tools, die echten Agenten-Aufgaben entsprechen, und verschmilz oder streich den Rest.
Ersetzt MCP OpenAPI?
Nein. Sie bedienen verschiedene Konsumenten. OpenAPI bleibt der Vertrag für Entwickler und Code-Generierung, MCP ist die Schnittstelle, die ein Modell zur Laufzeit nutzt. Die meisten gut gebauten MCP-Server stützen sich still auf eine gut dokumentierte API darunter.
Ist OpenAPI für KI-Agenten überhaupt nützlich?
Als Ausgangsmaterial: sehr. Es ist der schnellste Weg zu verstehen, was eine API kann, wenn du Agenten-Tooling baust. Als Laufzeit-Schnittstelle für das Modell selbst: nein. Eine Spec kann keinen Aufruf ausführen, kein Token halten und sich nicht auf die Teile schrumpfen, die eine Aufgabe braucht. Genau dieser Übersetzungsschritt ist der Job eines MCP-Servers.