29.03.2025 AI Engineering5 Minuten Lesezeit

OpenAI übernimmt MCP: Ein De-facto-Standard überschreitet Herstellergrenzen

OpenAI kündigte am 26. März 2025 Unterstützung für Anthropics Model Context Protocol an und lieferte sie zunächst im Agents SDK aus. Damit überschreitet MCP die Herstellergrenze. Wir klären, was das Protokoll standardisiert, welche Probleme es offenlässt, wie die Konvergenz Integrationsstrategien verändert und was die zeitgleiche Revision für Remote-MCP-Server bedeutet.

Das N-mal-M-Integrationsproblem

Jeder KI-Assistent, der auf externe Systeme zugreift, benötigt Konnektoren zu Ticketsystemen, Datenbanken, Versionsverwaltung und internen APIs. Solange ein gemeinsames Protokoll fehlte, definierte jeder Modellanbieter eine eigene Tool-Calling-Schnittstelle, für die wiederum eigene Adapter nötig waren. Die Kosten wuchsen quadratisch: N Clients mal M Systeme ergaben N mal M Einzelintegrationen, jeweils mit eigenem Schema, eigener Fehlerbehandlung und eigenem Wartungsaufwand. So wurde nicht die Modellqualität, sondern die Integration zum Engpass agentischer Systeme.

Anthropic veröffentlichte das Model Context Protocol (MCP) am 25. November 2024 als Open Source, um den Aufwand von N mal M auf N plus M zu reduzieren. Jedes System stellt einen MCP-Server bereit; jeder Client implementiert das Protokoll einmal und kann anschließend mit allen Servern kommunizieren. Block, Apollo, Zed, Replit, Codeium und Sourcegraph gehörten zu den frühen Anwendern. Eine strukturelle Schwäche blieb jedoch bestehen: Der größte Modellanbieter unterstützte den Standard seines engsten Wettbewerbers nicht.

Ein Agent erreicht seine Tools über MCP — eine Standard-Schnittstelle. 1/4

Was OpenAI am 26. März ankündigte

Am 26. März 2025 kündigte OpenAI-CEO Sam Altman MCP-Unterstützung für die OpenAI-Produkte an: "People love MCP and we are excited to add support across our products." Die Unterstützung erschien am selben Tag im quelloffenen Agents SDK. Unterstützung für die ChatGPT-Desktop-App und die Responses API wurde ohne Datum als "coming soon" angekündigt. Weitere Details will OpenAI in den kommenden Monaten nennen.

Der Umfang ist präzise. Ein Agent auf Basis des Agents SDK kann heute jeden bestehenden MCP-Server unverändert nutzen, lokal oder remote. ChatGPT selbst kann es noch nicht. Die Governance des Protokolls verbleibt beim Open-Source-Projekt, das Anthropic pflegt. OpenAI verpflichtet sich damit auf einen Standard, den es nicht kontrolliert. Das ist der bemerkenswerte Punkt: Die Entscheidung tauscht Kontrolle gegen Ökosystemzugang und signalisiert, dass die Protokollebene keine Wettbewerbsfläche mehr ist.

Was MCP standardisiert

MCP ist ein Client-Server-Protokoll auf Basis von JSON-RPC 2.0. Ein Server stellt drei Primitive bereit: Tools, also Funktionen, die das Modell aufrufen darf; Resources, also Daten, die der Client lesen darf; und Prompts, also wiederverwendbare Vorlagen. Client und Server handeln ihre Fähigkeiten bei der Initialisierung aus. Die Transporte sind austauschbar: stdio für lokale Kindprozesse, HTTP-basierte Transporte für entfernte Server. Das Protokoll ist bidirektional: Server können über Sampling auch Vervollständigungen vom Client anfordern, was bislang wenige Clients implementieren.

Ebenso wichtig ist, was MCP nicht standardisiert. Es sagt nichts über Modellverhalten, Tool-Qualität, Orchestrierung, Gedächtnis oder Agent-zu-Agent-Kommunikation. Es ist ein Verkabelungsstandard. Die nächstliegende Analogie ist das Language Server Protocol: eine Server-Implementierung pro Datenquelle statt einer Implementierung pro Client, mit einem bewusst schlanken Protokoll dazwischen.

Konvergenz verändert das Integrationskalkül

Ein Protokoll wird zum Standard, wenn der größte Wettbewerber seines Urhebers es übernimmt. Das Language Server Protocol überschritt diese Linie, als Editoren jenseits von Visual Studio Code es implementierten; MCP überschritt sie in dieser Woche. Die Abfolge seit November zeigt, wie schnell die Konvergenz eintrat und wie dicht die letzte Woche war:

Für die Integrationsstrategie hat diese Konvergenz eine konkrete Folge. Ein MCP-Server vor einem internen System bedient Claude, Agenten auf Basis des OpenAI-SDK, Copilot Studio und MCP-fähige Entwicklungswerkzeuge aus derselben Codebasis. Damit wird die Tool-Ebene herstellerneutral. Modell-Lock-in verschwindet zwar nicht — Prompts, Evaluationen und Kostenprofile bleiben anbieterspezifisch —, doch Konnektor-Code verliert seine Funktion als Wechselhürde. Für neue Integrationen setzen wir deshalb standardmäßig auf MCP-Server; direkte API-Aufrufe bleiben latenzkritischen Pfaden vorbehalten.

Datum	Ereignis
25.11.2024	Anthropic veröffentlicht MCP als Open Source mit SDKs und Referenzservern
19.03.2025	Microsoft kündigt MCP-Unterstützung in Copilot Studio an
25.03.2025	Cloudflare ermöglicht Deployment von Remote-MCP-Servern
26.03.2025	MCP-Spezifikationsrevision 2025-03-26: Streamable HTTP und OAuth 2.1
26.03.2025	OpenAI liefert MCP-Unterstützung im Agents SDK aus

Was MCP nicht löst

Konvergenz beim Transport löst die harten Probleme nicht. Tool-Beschreibungen und Tool-Ergebnisse sind nicht vertrauenswürdige Eingaben für das Modell. Prompt Injection über einen bösartigen oder kompromittierten Server bleibt ein offenes Problem, und kein Protokoll kann es beheben. Die Spezifikation stellt ausdrücklich fest, dass MCP diese Sicherheitsprinzipien "nicht auf Protokollebene erzwingen kann", und delegiert Einwilligungsflüsse, Autorisierung und Zugriffskontrolle an die Implementierer.

Es gibt zudem keine zentrale Registry; die Server-Suche erfolgt manuell. Es gibt keinen Standard für die Versionierung von Tool-Semantik, keinen Service-Level-Mechanismus, kein Abrechnungsmodell — und bis zum 26. März gar kein Autorisierungs-Framework. Wer einen MCP-Server als Produktions-API behandelt, muss Authentifizierung, Auditing, Rate Limiting und Monitoring selbst ergänzen. Das Protokoll liefert nichts davon.

Remote-Server am Horizont

Die meisten MCP-Server laufen heute lokal über stdio, gestartet von einem Desktop-Client. Dieses Modell skaliert nicht über Entwicklerrechner hinaus. Die am 26. März veröffentlichte Spezifikationsrevision zielt genau auf diese Grenze: Streamable HTTP ersetzt den bisherigen HTTP-plus-SSE-Transport und erlaubt zustandslose reine HTTP-Server mit optionalem Upgrade auf Server-Sent Events; ein neues Autorisierungs-Framework auf Basis von OAuth 2.1 definiert, wie entfernte Clients delegierten Zugriff erhalten.

Die Infrastruktur zog zuerst. Am 25. März stellte Cloudflare das Deployment von Remote-MCP-Servern auf der Workers-Plattform bereit, inklusive einer OAuth-Provider-Bibliothek und mcp-remote, einem Adapter, der rein lokale Clients mit entfernten Servern verbindet. Remote-MCP verändert das Betriebsmodell: Ein Server ist kein Prozess auf einem Entwicklerrechner mehr, sondern ein gehosteter, authentifizierter, mandantenfähiger Dienst mit Verfügbarkeitspflichten.

Ausblick von Ende März 2025

Unsere Erwartungen, festgehalten am Tag der Ankündigung, damit sie später überprüfbar sind. Die verbleibenden großen Modellanbieter werden MCP innerhalb von Monaten übernehmen; ein Protokoll mit Rückhalt der beiden führenden Anbieter wird kaum noch verdrängt. Server-Registries und Discovery-Mechanismen werden entstehen, zunächst fragmentiert. Um den neuen Transport wird sich eine Kategorie verwalteter Hosting-Angebote für Remote-MCP-Server bilden. Sicherheitswerkzeuge werden der Adoption hinterherlaufen, und der erste prominente MCP-Sicherheitsvorfall wird sie beschleunigen.

Die strategische Konsequenz folgt direkt aus dem heutigen Stand: Kapseln Sie interne Systeme als MCP-Server, halten Sie Geschäftslogik aus der Protokollschicht heraus und behandeln Sie Client-Unterstützung als austauschbare Anbieterleistung. Konvergenz belohnt Organisationen mit klar definierten Servern, nicht solche mit einem Bestand proprietärer Konnektoren. Seit dieser Woche besitzt die Server-Ära der KI-Integration eine Spezifikation, ein Autorisierungsmodell und — seit dem 26. März — Unterstützung durch jeden großen Client.