The team is shipping a set of inventory APIs. Developers need documentation. AI coding assistants need accurate interface structure. On the business side, people want to ask an AI about stock levels and order progress.

Prepare those separately and you end up with three sets of material: web documentation, interface explanations pasted into prompts, and hand-written tool definitions. Change one field and every copy has to chase it.

The audience list grew, but the underlying facts stayed the same — operation names, input parameters, response structures, and auth requirements. One OpenAPI file can serve all of them.

During development, the spec is what the agent reads

Inside the local workspace, you design endpoints with the assistant, review the patch cards, and then run requests, mocks, and scenarios against the same document. The specification is used and tested while the API is being built, and the dev MCP server hands it to coding agents for contract queries and implementation checks. By delivery time, the confirmed content is already written and exercised — ready to be reused rather than rewritten.

Deliver to people: readable, hosted documentation

Developers need parameter descriptions, response structures, examples, and calling instructions. Powerduck renders the specification into readable documentation, and Cloud provides the hosting path. From the documentation surface, a one-click host action opens Cloud in the browser, where you finish the import and choose what to publish. You confirm the version and the exposed content; the team never maintains a separate documentation-site deployment for each API project.

Every change is a new immutable version rather than an overwrite, so a link pinned to a release keeps pointing at the same contract while the current link follows the latest. That answers the integration question — "which version are we building against?" — with a URL instead of a meeting.

Deliver to agents: an MCP server generated from the spec

When the consumer is an AI client, a web page is not direct enough. The agent also needs to know which tools exist, what each one accepts, and how to actually call them. The OpenAPI-to-MCP conversion generates those tool definitions from the specification and connects them to the running API; Cloud can publish the MCP service as a managed Streamable HTTP endpoint with its own access key.

Start with inventory lookup. Once a client discovers the tool, it can query stock for a given product using the contracted parameters and answer from the real response. Nobody re-describes each parameter by hand — the existing API definition takes on a second delivery job.

Keep the two MCP use cases straight

Development-time MCP helps agents understand the contract and verify implementations. Runtime MCP exposes the already-running API as tools. One answers "how should this endpoint be built and checked"; the other performs "call this endpoint and get the result." Publishing decisions follow from that split: which contract details do developers see, which operations are exposed to callers, and what identity and permissions apply.

Generating tools neither implements backend business logic nor grants permission to call it. Real operations still need the correct service URL, authentication, and business authorization. Writes such as stock adjustments and refunds deserve explicit confirmation and access controls on top of whatever the generator produces.

From a development artifact to a deliverable capability

The full path connects end to end:

local OAS → assisted design → mocks and scenario verification → hosted documentation / published MCP.

The local file carries the evolving project agreement; the published version carries the confirmed external delivery. People and agents reach the result in the form each one needs. It is the change worth watching in AI-era API tooling: the specification no longer just explains code after the fact — it participates in design, implementation, verification, and invocation.

Start with a stable group of read-only endpoints, complete the descriptions and structures, verify them, and prepare the documentation and MCP service together. The next developer who integrates your API can read it, and the AI they work with can actually use it.