Anthropic übernimmt Stainless: Wie sich die MCP- und SDK-Schicht gerade verengt

Was ist passiert

Anthropic hat die Übernahme der New Yorker Firma Stainless bekanntgegeben. Stainless, 2022 von Ex-Stripe-Engineer Alex Rattray gegründet (laut The Information ein Deal-Wert von über 300 Mio US-Dollar), automatisiert die Generierung von SDKs, CLIs und MCP-Servern aus OpenAPI-Spezifikationen — quer durch TypeScript, Python, Go, Java und Kotlin. Bisher haben sich neben Anthropic auch OpenAI, Google, Cloudflare, Replicate, Runway und Meta (Llama Stack) auf das Tool gestützt. Anthropic kündigt an, alle gehosteten Stainless-Produkte einzustellen, darunter den SDK-Generator selbst; bereits generierte SDKs bleiben im Eigentum der bisherigen Kunden, neue Generierungsläufe sind dort nicht mehr möglich.

Einordnung

Die Übernahme ist kein klassischer Talent-Buy, sondern ein Zugriff auf eine geteilte Infrastruktur-Schicht. SDK- und MCP-Server-Generierung ist die Schiene, über die Modell-APIs zu sich selbst bewegenden Agenten werden — die Bibliothek, die den Werkzeug-Aufruf macht, die Capability-Schemas pflegt, die MCP-Server gegen die API-Spec hält. Anthropic, das die MCP-Spezifikation selbst gestiftet und im Dezember 2025 an die Linux Foundation Agentic AI Foundation übergeben hat, holt damit den Generator, der diese Server in der Breite herstellt, unter ein eigenes Dach. Aus Sicht der Konkurrenz wird ein Lieferant aus dem Markt genommen; aus Sicht der Ökosystem-Debatte verschiebt sich eine bislang horizontale Schicht in die Vertikale eines einzelnen Anbieters.

Bedeutung für den Mittelstand

Wer im DACH-Mittelstand AI- oder Agenten-Funktionalität in eigene Produkte integriert hat, sollte heute drei Fragen klären. Erstens: Welche SDKs in unserem Stack stammen aus dem Stainless-Generator? Diese SDKs bleiben rechtlich nutzbar; Anthropic hat zugesichert, dass bestehende Kunden die generierten Bibliotheken vollständig besitzen und modifizieren dürfen. Operativ verlieren sie aber die automatische Spec-zu-SDK-Aktualisierung; jeder API-Wechsel beim Anbieter muss künftig manuell oder mit einem anderen Tool nachgezogen werden. Zweitens: Welche MCP-Server in unserem Datenpfad stammen aus dem Stainless-Workflow? Hier ist die Lage analog: die bestehenden Server laufen weiter, aber Pflege und Erweiterung verlieren ihre Automatisierungs-Schiene.

Die dritte Frage ist die heiklere: Welche Daten laufen durch diese Komponenten, und ist diese Schicht in der Datenschutz-Folgenabschätzung sauber abgebildet? SDKs und MCP-Server sind keine harmlosen Connectors — sie kapseln Authentifizierung, Tool-Calling-Logik und damit häufig den Pfad personenbezogener Daten oder Geschäftsgeheimnisse hin zu einem US-Modell. Eine Übernahme, die einen Anbieter aus dem Stack zieht, ist auch ein Anlass, die Drittland-Position dieser Schicht erneut zu prüfen und im Verarbeitungsverzeichnis nach Art. 30 DSGVO sauber zu führen. Bei NIS-2-pflichtigen Unternehmen kommt die Frage hinzu, ob die Komponente in der Lieferanten-Liste nach § 30 BSIG-neu erfasst ist; die Übernahme verändert den Risikoträger.

Praktisch heißt das nicht, sofort zu wechseln. Es heißt, das eigene Inventar zu kennen und die Entscheidungs-Gabelung bewusst zu setzen: bestehende SDKs weiter pflegen, auf eine Alternativ-Toolchain (selbstgehostete OpenAPI-Generatoren oder die anbietereigene SDK-Pipeline) umstellen, oder MCP-Server handgepflegt halten.

Bedeutung für die technische Entwicklung

Architektonisch bestätigt der Schritt einen Befund, der seit der MCP-Stiftung an die Linux Foundation in Bewegung ist: Die Standard-Spezifikation und die Implementierungs-Toolchain sind zwei Schichten, und die zweite konsolidiert sich gerade. MCP als Spezifikation ist offen und liegt bei der Agentic AI Foundation. Die Generierung performanter MCP-Server gegen reale API-Specs ist der Schritt, der den Standard von einer PDF in einen laufenden Prozess verwandelt — und dieser Schritt verlässt mit der Stainless-Übernahme die offene Werkbank und wird ein Stück des Claude-Platform-Pakets.

Für die SDK-Schicht gilt strukturell dasselbe. Mit Tool-Calling, Streaming, strukturierten Output-Schemas und Agent-Loops sind SDKs zu einem differenzierenden Bestandteil der Plattform geworden — Latenz, Zuverlässigkeit und die Treue zur Spec entscheiden, wie gut ein Agent in der Praxis funktioniert. Wandert der Standard-Generator dieser Bibliotheken zu einem einzigen Anbieter, gewinnt dieser eine Position jenseits des Modells.

Konkrete Handlungsempfehlung

In dieser Reihenfolge: Erstens, inventarisieren Sie, welche SDKs und MCP-Server in Ihrem Stack aus dem Stainless-Generator stammen — die package.json-Header, pyproject.toml-Kommentare und MCP-Server-Manifeste tragen das in der Regel sichtbar. Zweitens, klären Sie für jede dieser Komponenten, wie der Update-Pfad bei API-Änderungen des jeweiligen Anbieters künftig aussieht (manuelle Pflege, anbietereigener Generator, alternative Toolchain). Drittens, prüfen Sie mit Ihrem oder Ihrer Datenschutzbeauftragten, ob die betroffenen Komponenten im Verarbeitungsverzeichnis und in der DSFA korrekt verortet sind, jetzt da der Risikoträger sich verschoben hat. Architektur-Entscheidungen über Migration oder Eigenbau folgen sinnvoll erst nach diesem Inventar, und erst dann, wenn Anthropic in den kommenden Wochen das Sunset-Datum für die gehosteten Stainless-Produkte konkretisiert hat.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• Anthropic — Anthropic acquires Stainless (18.05.2026)
• TechCrunch — Anthropic has acquired the dev tools startup used by OpenAI, Google, and Cloudflare (18.05.2026)
• Stainless — Stainless is joining Anthropic (18.05.2026)
• VentureBeat — Anthropic launches enterprise „Agent Skills“ and opens the standard (Mai 2026, Kontext zur MCP-/Agent-Strategie)