Anthropic acquires Stainless: how the MCP and SDK layer is narrowing

What happened

Anthropic has announced its acquisition of the New York firm Stainless. Stainless, founded in 2022 by former Stripe engineer Alex Rattray (with a deal value reported by The Information at more than 300 million US dollars), automates the generation of SDKs, CLIs and MCP servers from OpenAPI specifications — across TypeScript, Python, Go, Java and Kotlin. Until now Anthropic, OpenAI, Google, Cloudflare, Replicate, Runway and Meta (Llama Stack) have all relied on the tool. Anthropic announces that it will wind down all hosted Stainless products, including the SDK generator itself; SDKs already generated remain owned by their existing customers, but new generation runs are no longer possible there.

Reading the move

The acquisition is not a classic talent-buy but a grab on a shared infrastructure layer. SDK and MCP server generation is the rail that turns model APIs into self-acting agents — the library that makes the tool call, maintains the capability schemas, holds the MCP servers against the API spec. Anthropic, which authored the MCP specification itself and donated it to the Linux Foundation Agentic AI Foundation in December 2025, is now pulling the generator that produces those servers at scale under its own roof. From the competition’s perspective, a supplier has been taken off the market; from the ecosystem perspective, a previously horizontal layer is shifting into the vertical of a single vendor.

What it means for the Mittelstand

Anyone in the German Mittelstand who has integrated AI or agent functionality into their own products should be clarifying three questions today. First: which SDKs in our stack come from the Stainless generator? Those SDKs remain legally usable; Anthropic has confirmed that existing customers fully own the generated libraries and may modify them. Operationally, however, they lose the automatic spec-to-SDK update; every API change at the provider must now be tracked manually or with a different tool. Second: which MCP servers in our data path come from the Stainless workflow? The situation is analogous: existing servers keep running, but maintenance and extension lose their automation rail.

The third question is the harder one: which data flows through these components, and is this layer cleanly mapped in the Data Protection Impact Assessment? SDKs and MCP servers are not harmless connectors — they encapsulate authentication, tool-calling logic and therefore often the path of personal data or business secrets to a US model. An acquisition that pulls a supplier out of the stack is also a reason to re-check the third-country position of this layer and to keep it cleanly listed in the record of processing activities under Art. 30 GDPR. For NIS-2-regulated companies the further question is whether the component is captured on the supplier list under § 30 BSIG-neu; the acquisition changes the risk-bearer.

Practically, this does not mean switching immediately. It means knowing your own inventory and consciously setting the decision fork: keep maintaining existing SDKs, switch to an alternative toolchain (self-hosted OpenAPI generators or the provider’s own SDK pipeline), or keep MCP servers hand-maintained.

What it means for technical development

Architecturally the step confirms a finding that has been in motion since the donation of MCP to the Linux Foundation: the standard specification and the implementation toolchain are two layers, and the second is consolidating right now. MCP as a specification is open and sits with the Agentic AI Foundation. Generating performant MCP servers against real API specs is the step that turns the standard from a PDF into a running process — and with the Stainless acquisition this step leaves the open workbench and becomes a piece of the Claude Platform package.

The same applies structurally to the SDK layer. With tool calling, streaming, structured output schemas and agent loops, SDKs have become a differentiating part of the platform — latency, reliability and fidelity to the spec decide how well an agent works in practice. If the standard generator of these libraries moves to a single vendor, that vendor gains a position beyond the model.

Concrete recommendation

In this order: first, inventory which SDKs and MCP servers in your stack come from the Stainless generator — the package.json headers, pyproject.toml comments and MCP server manifests usually carry this visibly. Second, clarify for each of these components how the update path will look on future API changes at the respective provider (manual maintenance, the provider’s own generator, or an alternative toolchain). Third, check with your data protection officer whether the affected components are correctly mapped in the record of processing activities and in the DPIA, now that the risk-bearer has shifted. Architectural decisions about migration or in-house build sensibly follow only after this inventory, and only once Anthropic concretises the sunset date for the hosted Stainless products in the coming weeks.

This article reflects our technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• Anthropic — Anthropic acquires Stainless (18 May 2026)
• TechCrunch — Anthropic has acquired the dev tools startup used by OpenAI, Google, and Cloudflare (18 May 2026)
• Stainless — Stainless is joining Anthropic (18 May 2026)
• VentureBeat — Anthropic launches enterprise “Agent Skills” and opens the standard (May 2026, context on the MCP/agent strategy)