AI Tools

OpenAPI to SDK, CLI and MCP Server: What Google's Open-Source Generator Changes

Google and Speakeasy open-sourced an OpenAPI generation suite for typed SDKs, agent-native CLIs and documentation MCP servers. Here is what it changes for API and AI-agent developers.

AiFolder Editorial Team

AiFolder Editorial Team

9 min read
OpenAPI to SDK, CLI and MCP Server: What Google's Open-Source Generator Changes

Google and Speakeasy have open-sourced an OpenAPI generation suite that can turn API specifications into typed SDKs, standalone CLIs, and documentation MCP servers. The interesting part is not another code generator: one API contract can now feed both human developers and AI coding agents through deterministic tooling.

Freshness check: September 19, 2026. Google announced the open-source release on September 17. This article separates capabilities documented by Google and Speakeasy from tests AiFolder has not yet independently reproduced. We will add benchmark results after running the suite against a controlled API specification.

What was released?

Google says it partnered with Speakeasy to open-source Speakeasy's OpenAPI client suite under AGPLv3 after a proprietary SDK-generation provider it depended on was acquired and shut down. Google describes three especially relevant outputs:

  • Multi-language SDK generation for Python, TypeScript, Go, Java, C#, PHP and Ruby, including static typing, SSE streaming, retries and pagination.
  • An agent-native CLI generator that produces standalone command-line tools an AI coding agent can invoke instead of repeatedly writing temporary HTTP scripts.
  • A documentation MCP server generator that exposes OpenAPI specifications and Markdown documentation through Model Context Protocol so coding agents can query maintained API information.

The generated code remains yours to license under terms such as MIT or Apache 2.0, according to Google's announcement. Modifications to the AGPL-licensed generator itself have different obligations, so teams should review the license before embedding or modifying the compiler.

Why this matters for AI agents

An LLM can already read API documentation and write an HTTP request. That does not mean it will choose the current endpoint, construct every parameter correctly, implement pagination consistently, or remember an API's error model.

A formal OpenAPI contract gives tooling a deterministic description of endpoints and schemas. Generating an SDK or CLI from that contract moves some integration work away from probabilistic code generation. An agent can then use a stable interface while the generator handles repetitive plumbing.

The MCP angle addresses a related problem: documentation freshness. Instead of relying only on model training data or a large documentation dump in the prompt, an agent can query maintained API specifications and documentation through tools.

The architecture in one line

OpenAPI spec
    |
    +--> typed SDK
    |
    +--> CLI --> developer or coding agent
    |
    +--> documentation MCP server --> AI agent

This makes OpenAPI more than an API documentation format. It can become a source contract for interfaces consumed by both software and agents.

Where deterministic generation beats asking an LLM

Types and schemas

If a specification defines a required field as a string union, a deterministic generator can encode that contract consistently. Asking an LLM to recreate client types from prose introduces an unnecessary interpretation step.

Pagination and retries

These behaviors are repetitive but important. Google's release specifically calls out pagination and retries in generated libraries. They are good candidates for repeatable generation rather than hand-written agent code.

Streaming

Modern AI APIs frequently use server-sent events. Google says the open-source generators support SSE, which makes the release particularly relevant to AI API providers.

Current documentation

A documentation MCP server can expose maintained schemas and docs to an agent. This does not guarantee correct code, but it reduces one common failure mode: inventing an old method or parameter from stale model knowledge.

What this does not solve

Generating interfaces does not make an API integration automatically correct or safe.

  • An inaccurate OpenAPI specification can produce inaccurate generated interfaces.
  • An MCP server still needs appropriate authentication, authorization and tool permissions.
  • An agent can call a perfectly generated tool with the wrong business intent.
  • Generated code still needs compilation, tests, review and versioning.
  • AGPL licensing of the generator deserves review for organizations modifying or redistributing the generator itself.

Think of generation as removing repetitive integration work, not removing engineering responsibility.

How AiFolder will test OpenAPI-to-agent tooling

Generic examples are not enough to tell whether generated code is pleasant to maintain. AiFolder's benchmark will use one controlled OpenAPI specification containing authentication, nested objects, pagination, error responses, optional fields and an SSE endpoint.

For each generated output we will record:

  • whether it builds without manual edits;
  • type accuracy and null/optional-field handling;
  • pagination and retry behavior;
  • SSE behavior;
  • authentication ergonomics;
  • generated-code size and readability;
  • how many manual changes are needed before tests pass;
  • what tools and documentation the generated MCP interface exposes to an agent.

We will also give a coding agent the same API task in two conditions: raw OpenAPI/docs and generated CLI + MCP documentation. Useful measurements include completion rate, incorrect endpoint or parameter usage, token consumption, retries and human corrections.

A practical workflow for API teams

  1. Keep the OpenAPI specification versioned with the API.
  2. Lint and validate the specification before generation.
  3. Generate the SDK or CLI in CI rather than relying on a developer's workstation.
  4. Run compile, contract and integration tests against generated output.
  5. Expose only the documentation and actions an AI agent actually needs.
  6. Require authentication and least-privilege authorization for consequential MCP tools.
  7. Regenerate and retest whenever the API contract changes.

OpenAPI to MCP is not the same as OpenAPI to executable actions

Google's September 17 announcement specifically describes a documentation MCP server generator: it turns OpenAPI specifications and Markdown documentation into an MCP server that agents can query. Do not silently interpret that as every endpoint becoming an unrestricted executable MCP action.

This distinction matters for security and for evaluating competing OpenAPI-to-MCP products. Documentation retrieval, generated CLIs and action tools have different permission boundaries.

Why the open-source part matters

The release was prompted by a supply-chain problem. Google says its previous proprietary generation provider was acquired and abruptly announced its shutdown while Google was preparing the Gemini Interactions API for general availability. Google then migrated its generation pipeline with Speakeasy.

That makes this release relevant beyond AI hype. SDK generation can be infrastructure. If a closed generator disappears, an API provider may face broken release pipelines and client-library delays. Source availability gives teams another way to inspect, run and maintain that infrastructure.

Should you generate an MCP server from every API?

No. Start with the job the agent needs to perform. A read-heavy documentation assistant may only need searchable API documentation. An operational agent may need a carefully scoped subset of executable tools. Turning hundreds of endpoints into agent actions without considering permissions and context can make the system harder to govern rather than easier.

Frequently asked questions

Can OpenAPI generate an MCP server?

Yes, multiple tools now bridge OpenAPI and MCP. In this release, Google specifically describes Speakeasy's documentation MCP generator, which turns OpenAPI specifications and Markdown documentation into an MCP server for agent queries.

Can the same OpenAPI spec generate an SDK and CLI?

Speakeasy's open-source suite includes multi-language SDK generation and an agent-native CLI generator, so one API contract can feed multiple developer interfaces.

Does generated MCP make an AI agent safe?

No. Generation can make interfaces more consistent, but authentication, authorization, sandboxing, approval policies, logging and business-level validation remain separate concerns.

Why not let an AI agent write the SDK?

AI is useful for custom work, but formal schema transformation benefits from deterministic output and repeatability. Google says its own approach uses deterministic generation for the core transformation while AI agents accelerate custom portions.

Related AiFolder guides

Sources and methodology

Checked September 19, 2026. Primary source: Google Developers Blog: Why client SDK generation belongs in the open. We also checked the Speakeasy GitHub repository for the current open-source project and supported workflow. Product claims above are attributed where they have not yet been independently reproduced by AiFolder.