In der heutigen Zeit, in der Künstliche Intelligenz und große Sprachmodelle (LLMs) immer bedeutender werden, sind Schnittstellen zur Anbindung externer Tools und Dienste von zentraler Bedeutung. In diesem Zusammenhang wird immer wieder über die Notwendigkeit von MCP (Model-Content-Protocol) diskutiert. Ist MCP tatsächlich eine überfällige Innovation oder handelt es sich dabei um eine Technologie, die vor allem aus soziologischen Gründen verwendet wird, während technisch keine klaren Vorteile gegenüber bestehenden Standards wie OpenAPI existieren? Dieser Frage sollte man auf den Grund gehen. Zunächst einmal sollte man verstehen, dass MCP eine Art Protokoll beziehungsweise Standard ist, der es Maschinen erleichtern soll, direkt mit APIs und Tools zu kommunizieren. Dabei geht es primär darum, Werkzeuge zu bewerben (Advertising) und aufzurufen (Calling). MCP bietet strukturierte JSON-Deklarationen, die vergleichbar mit OpenAPI-Spezifikationen sind.
Tatsächlich kann MCP-JSON direkt in Prompts eingefügt und von LLMs gut verarbeitet werden, was dessen Flexibilität unterstreicht. Trotzdem stellt sich die Frage, warum ein weiterer Standard neben OpenAPI notwendig sein soll, zumal letztere sich über Jahre als De-facto-Standard der API-Dokumentation und -Beschreibung etabliert hat. Technologisch betrachtet gibt es überraschend wenig Gründe, warum MCP zwingend sein müsste. OpenAPI deckt bereits die meisten Anwendungsfälle ab und ist äußerst ausdifferenziert. Tatsächlich kann die API-Struktur von OpenAPI operationId nennen, die sich häufig als Funktion im Server-Backend 1:1 abbilden lässt, was die nahtlose Integration erleichtert. MCP hingegen versucht häufig, mehrere zusammenhängende Operationen in einem einzigen Aufruf zusammenzufassen, um die Komplexität für den LLM zu reduzieren. Ein Beispiel wäre ein asynchroner Task mit mehreren API-Endpunkten, der bei MCP gebündelt wird.
Das mag intuitiv einfacher oder sicherer erscheinen, ist aber technisch ebenfalls mit OpenAPI machbar. Die vermeintliche technische Überlegenheit von MCP ist also eher eine Frage der Umsetzung und des Designs als der reinen Funktionalität. OpenAPI kann asynchrone Aufrufe ebenso darstellen, beispielsweise durch Nutzung von Server-Sent Events (SSE). Diese Technik ist zwar relativ neu, wird aber bereits von modernen Systemen unterstützt. Vielmehr stehen hier soziale und organisatorische Faktoren im Vordergrund, wenn es darum geht, warum bestimmte API-Designs bevorzugt oder vermieden werden. Ein interessantes soziales Phänomen im API-Design ist die Erwartung an schnelle Antwortzeiten. Längere Latenzen bei API-Aufrufen gelten häufig als Problem oder Anzeichen für Fehler im System. Deshalb bevorzugen viele Entwickler Teams eher synchrone oder klar abgegrenzte Operationen mit kurzer Laufzeit, was bei asynchronen Prozessen aufwendiger sein kann.
Dies führt dazu, dass manche technische Möglichkeiten trotz vorhandener Funktionalität kaum genutzt werden, weil sie nicht der gewohnten Arbeitsweise entsprechen. MCP adressiert diese Herausforderung, indem es ein einheitliches Framework und Ökosystem bietet, das speziell auf die Anforderungen von LLM-gestützten Anwendungen zugeschnitten ist. Ein weiteres wesentliches Argument für MCP liegt in der Standardisierung. Während OpenAPI sehr umfassend und flexibel ist, führt diese Vielfalt auch zu Inkonsistenzen in der Umsetzung. Entwickler unterschiedlicher Teams interpretieren REST-Operationen und HTTP-Methoden (GET, POST, PUT, DELETE) mitunter unterschiedlich, was zu Verwirrung und erhöhtem Koordinationsaufwand führen kann. MCP hingegen bringt eine klar definierte Struktur mit, die gezielt für Tool-Aufrufe optimiert ist. Die Folge ist eine stärkere Vereinheitlichung, die gerade im Bereich Künstlicher Intelligenz und LLMs den Entwicklungsprozess vereinfachen kann.
Die geringe Größe und der Fokus von MCP sind hier entscheidende Vorteile. Während OpenAPI ein sehr breites Spektrum an Funktionalitäten abbildet, konzentriert sich MCP auf die essenziellen Komponenten, die für den Tool-Aufruf relevant sind. Das macht das Protokoll übersichtlicher, leichter zu implementieren und besser mit LLMs kompatibel. Obwohl technisch eine Umwandlung zwischen MCP und OpenAPI problemlos möglich ist, bevorzugen viele Entwickler MCP auch aus praktischen Gründen – etwa, weil die Ökosysteme, Werkzeuge und Dokumentationen spezifisch auf ihre Bedürfnisse zugeschnitten sind. Abschließend lässt sich festhalten, dass MCP aus rein technischer Sicht nicht zwingend notwendig ist, da alle wesentlichen Funktionalitäten bereits durch OpenAPI abgedeckt sind. Dennoch spielt die Psychologie und Organisation der Entwicklergemeinschaft eine große Rolle für die Akzeptanz eines solchen Standards.
Wenn MCP einheitliche Konzepte bietet und so den Entwicklungsprozess vereinfacht, schafft es eine wichtige Brücke zwischen Technologie und Praxis. In einem Umfeld, das sich durch schnelle Innovation, steigende Komplexität und die verschränkte Nutzung von KI-Tools auszeichnet, erweist sich Standardisierung als unschätzbare Hilfe. Ob letztlich MCP oder OpenAPI die Oberhand gewinnt, hängt weniger an technischen Kriterien, sondern vielmehr an den Bedürfnissen und Gewohnheiten der Entwickler und Unternehmen. Die aktuelle Dynamik deutet darauf hin, dass MCP nicht wegen seiner technischen Überlegenheit, sondern wegen seiner klaren Ausrichtung und Gemeinschaftsstützung eine bedeutende Rolle spielt. Diese sozialtechnologische Sichtweise eröffnet spannende Perspektiven auf die Zukunft der API-Kommunikation und zeigt, wie wichtig neben der Technologie auch menschliche Faktoren für die Gestaltung digitaler Ökosysteme sind.
