Stainless

Stainless: What Comes Out Of An OpenAPI Spec

• SDKs in seven languages — TypeScript, Python, Go, Java, Ruby, C# and PHP.
• Documentation that tracks the API rather than being maintained separately.
• MCP servers as a first-class output, so agents can call the API too.
• One source of truth: everything derives from the OpenAPI specification.
• Joining Anthropic, announced on the homepage with a linked statement.

Stainless: Generated SDKs That Read Like Handwritten Ones

The positioning is a single sentence with a claim inside it: best-in-class interfaces for developers and agents, because great agent experience is built on great developer experience.

The deliverables are robust, idiomatic SDKs, documentation that keeps up with your API, and state-of-the-art MCP servers, all derived from an OpenAPI spec.

The word carrying the weight is idiomatic, and it is where generated SDKs have historically failed.

Older generators produced code that was technically correct and obviously machine-made: Java-shaped method names in Python, no type hints, exceptions that did not follow language conventions, and a call signature nobody would have written by hand.

Developers can tell within thirty seconds, and the reaction is not aesthetic — it is a reasonable inference that if the interface was not designed, the error handling probably was not either.

The example on the homepage is instructive, because it is the client library for a well-known AI provider written the way a person would write it: an environment-variable key, an options object, an awaited call. That is the standard being claimed.

Developers can spot a generated SDK in thirty seconds, and the reaction is not aesthetic. If the interface was not designed, they assume the error handling was not either.

Idiomatic Code In Seven Languages

Seven languages is the specific number, and each one carries its own conventions that a generator has to honour rather than translate.

Python expects snake_case, type hints and context managers. TypeScript expects discriminated unions and precise generics. Go expects explicit error returns rather than exceptions. Java expects builders. Ruby expects blocks.

A generator that emits the same structure into every language produces seven libraries that each feel foreign in their own ecosystem, which is the outcome that gave code generation its reputation.

Doing it properly means encoding real knowledge of each language's idiom, and that is engineering work rather than templating work — which is why this is a product rather than a script.

The practical payoff for an API provider is coverage. Maintaining seven hand-written SDKs means seven repositories, seven release processes and seven sets of maintainers who each need to care. Most companies manage two well and let the rest decay. Documentation platforms such as GitBook solve the neighbouring half of the same problem.

Why Do Hand-Written SDKs Fall Behind?

The failure is not neglect. It is that an SDK is a copy of an interface, and copies drift from originals unless something forces them not to.

The sequence is always the same. An API adds a field. The TypeScript SDK gets updated because the team that shipped the change uses it. Python follows a week later. Go and Ruby are maintained by whoever volunteered eighteen months ago, and one of them has left.

Six months on, four libraries expose four slightly different versions of the same API, and the documentation describes a fifth.

The cost lands on developers who cannot tell whether a missing parameter is a limitation of the API or of the client library they happen to be using, and it lands as support tickets and abandoned integrations.

Generating from a specification removes the possibility rather than the temptation. The spec changes, everything regenerates, and there is no window in which the pieces disagree. This is the same argument for keeping documentation generated too, and the reason both appear in one product.

• Treat the OpenAPI spec as the artefact that must be correct.
• Regenerate on every API change rather than on a release cadence.
• Check the generated code reads idiomatically in each language you ship.
• Ship an MCP server alongside the SDKs, not months later.
• Confirm long-term plans with the vendor given the Anthropic announcement.

MCP Servers As A First-Class Output

The framing on the homepage is that great agent experience is built on great developer experience, with MCP servers listed beside SDKs and documentation rather than as an add-on.

That ordering reflects something that has changed genuinely quickly.

For twenty years the consumer of an API was a developer reading documentation and writing code. Increasingly it is an agent that needs a machine-readable description of what operations exist, what they require and what they return — which is what MCP standardises.

An API without an MCP server is now invisible to a growing class of consumer, in roughly the way a site without structured data became invisible to certain search features.

Generating the MCP server from the same specification is the obviously correct approach, because the alternative is hand-maintaining yet another surface that will drift. It also means an API's agent interface improves whenever its spec does, without anyone deciding to work on it. Teams already versioning what they send to models, as PromptLayer does for prompts, will recognise the pattern: put the definition in one place and generate every consumer from it.

Joining Anthropic: What The Announcement Says

The homepage carries a short statement: Stainless is joining Anthropic, to continue our mission to make software better for everyone, with a link to the full announcement.

We report this as a fact published on the company's own site, and nothing beyond it.

It matters to a reader because SDK generation is infrastructure. Choosing it means an API's public interface — the thing customers integrate against and cannot easily migrate away from — depends on a vendor's continuity.

Any acquisition raises ordinary, answerable questions: whether the product remains available to companies unrelated to the acquirer, what happens to existing contracts, and what the support commitment looks like. None of those are answered on the homepage, and all are reasonable to put to the company directly.

The customer list gives some context for the stakes: Cloudflare, Letta, Lithic, Modern Treasury, MUX, OpenAI, Replicate, Turbopuffer and Weights & Biases are named on the site. That is a serious set of API-first companies, and the sort of list that suggests the generated output holds up in production. Developer-facing tools like Dosu occupy adjacent ground without touching the client libraries themselves.

Publishing An API Developers Will Adopt

An API is adopted or abandoned in the first twenty minutes, and almost all of that is determined by the client library and the documentation.

This order gets those right before anything else.

1. Get the OpenAPI specification correct — everything downstream inherits its mistakes.
2. Generate for the two languages your users actually use before adding five more.
3. Read the generated code as a developer in that language would.
4. Wire regeneration into the API release process, not a separate schedule.
5. Ship the MCP server at the same time as the SDKs.
6. Ask the vendor about continuity before making it load-bearing.

Stainless: Outputs And Customers