Cloudflare Open-Sourced Forge. Your API Spec Is Now the Product Your Agents Read.

Cloudflare just open-sourced Forge, and the timing tells you most of the story. Anthropic acquired Stainless on May 18 and then wound down its products, including the SDK generator that OpenAI, Google and Cloudflare all relied on. Those companies kept the SDKs they already had. They lost the machine that kept them current. Eleven days after Google's announcement, Cloudflare shipped Forge under Apache 2.0.

If you don't ship a public SDK, it's tempting to file this under "someone else's problem". Don't. The interesting part isn't the generator. It's what the generator is feeding.

One spec, five outputs

Forge reads an API definition and produces SDKs, a CLI, docs and MCP servers from the same source. Cloudflare's own build started in April, on a TypeScript schema. It now powers the new cf CLI, which covers 3,000+ API operations. The old Wrangler tool covered around 280.

That jump is the point. When the CLI, the docs and the tool definitions all come out of one spec, they can't drift apart. Nobody has to remember to update the MCP server after the API changes. It changes because the spec changed.

Most teams we talk to run the opposite setup. The OpenAPI file is a stale artifact someone exports once a quarter. The docs are hand-edited. The MCP server was written in a weekend by one engineer who has since moved teams. Three sources of truth means zero sources of truth.

Why this matters more now that agents are callers

Cloudflare's CTO put it plainly: if that layer is stale or incomplete, an agent doesn't just get a worse developer experience. It can misunderstand what your service does.

A human with an outdated SDK hits an error, checks the docs, and works around it. An agent takes the tool description at face value. If the description says an endpoint accepts a field that was removed two releases ago, the agent will keep sending it, keep failing, and sometimes keep retrying in ways that cost you money.

So the spec is no longer documentation. It's the interface contract that machines act on without asking questions. That raises the bar for how you maintain it.

What we'd do on Monday

You don't need to adopt Forge to learn from it. Three things are worth doing this week:

1. Find your real source of truth. Ask where a new endpoint gets defined first. If the answer is "in the code, and then someone updates the spec", you have a drift problem.
2. Generate, don't hand-write, the boring layers. Client libraries, reference docs and MCP tool definitions are mechanical. Put a check in CI that fails the build when the generated output no longer matches the spec.
3. Don't build the pipeline on a hosted service you can't fork. Stainless customers found out what a single-vendor dependency costs when the vendor gets acquired. Open source with a permissive license isn't a guarantee of quality, but it does mean you can keep the lights on yourself.

There's a fair counterpoint. Generated SDKs are rarely as pleasant as hand-tuned ones, and a 3,000 operation CLI can be overwhelming to browse. Both are true. But a clunky client that's always correct beats a beautiful one that's three versions behind, especially when the caller is a model.

The takeaway

The layer between your API and everything that calls it just became the part that decides whether agents can use your product at all. Treat the spec like production code. Version it, test it, and make it the only place an endpoint is ever defined.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!