29.03.2025 AI Engineering 5 Minuten Lesezeit

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

Am 26. März 2025 kündigte OpenAI Unterstützung für Anthropics Model Context Protocol an, zunächst verfügbar im Agents SDK. Wir analysieren, was das Protokoll standardisiert, was es bewusst offenlässt, warum herstellerübergreifende Konvergenz die Integrationsstrategie verändert und was die zeitgleiche Spezifikationsrevision für Remote-MCP-Server bedeutet.

Das N-mal-M-Integrationsproblem

Jeder KI-Assistent, der auf externe Systeme zugreift, braucht Konnektoren: zu Ticketsystemen, Datenbanken, Versionsverwaltung, internen APIs. Solange kein gemeinsames Protokoll existierte, definierte jeder Modellanbieter eine eigene Tool-Calling-Schnittstelle, und jede Schnittstelle verlangte eigene Adapter. Die Kosten waren quadratisch: N Clients mal M Systeme bedeuteten N mal M Einzelintegrationen, jede mit eigenem Schema, eigener Fehlerbehandlung und eigenem Wartungsaufwand. Nicht die Modellqualität, sondern der Integrationsaufwand wurde zum Engpass agentischer Systeme.

Anthropic veröffentlichte das Model Context Protocol (MCP) am 25. November 2024 als Open Source, um diese Kosten auf N plus M zu reduzieren. Ein System stellt einen MCP-Server bereit; ein Client implementiert das Protokoll einmal und spricht mit jedem Server. Block, Apollo, Zed, Replit, Codeium und Sourcegraph gehörten zu den frühen Anwendern. Eine strukturelle Schwäche blieb: Der größte Modellanbieter unterstützte das Protokoll seines engsten Wettbewerbers nicht.

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 ist die Konsequenz konkret. Ein MCP-Server um ein internes System bedient nun Claude, Agenten auf Basis des OpenAI-SDK, Copilot Studio und MCP-fähige Entwicklungswerkzeuge aus einer einzigen Codebasis. Die Tool-Ebene wird herstellerneutral. Der Modell-Lock-in verschwindet nicht — Prompts, Evaluationen und Kostenprofile bleiben anbieterspezifisch —, aber Konnektor-Code ist keine Wechselhürde mehr. Wir setzen bei neuen Integrationen inzwischen standardmäßig auf MCP-Server und behalten direkte API-Aufrufe für latenzkritische Pfade bei.

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 Schlussfolgerung ist nicht spekulativ. Kapseln Sie interne Systeme jetzt als MCP-Server, halten Sie Geschäftslogik aus der Protokollschicht heraus und behandeln Sie Client-Unterstützung als Commodity, die die Anbieter liefern. Konvergenz belohnt Organisationen, die gut definierte Server besitzen, nicht Organisationen, die Konnektoren besitzen. Die Konnektor-Ära der KI-Integration endete in dieser Woche; die Server-Ära hat eine Spezifikation, ein Autorisierungsmodell und — seit dem 26. März — jeden großen Client.

Quellen

• Anthropic: Introducing the Model Context Protocol (Nov 25 2024)
• TechCrunch: OpenAI adopts rival Anthropic's standard for connecting AI models to data (Mar 26 2025)
• Model Context Protocol Specification 2025-03-26: Key Changes (Mar 26 2025)
• Cloudflare: Build and deploy Remote Model Context Protocol servers (Mar 25 2025)
• OpenAI Agents SDK: Model Context Protocol documentation (Mar 26 2025)