From an OpenAPI spec to a hosted MCP server in under five minutes
"Let's give the agent access to our API" sounds like a weekend project. It is not. Someone has to describe each tool, wire authentication, keep descriptions in sync as endpoints change, host the bridge, and decide who is allowed to call what. By the time it works, the wrapper is a second, shabbier version of the API contract — maintained by hand forever.
It does not have to be built. It can be served from the spec.
What Powerduck Cloud does with one file
Drop an OpenAPI file, paste a URL, or point at a Git repository in the Cloud console, and the same document produces two things at once:
- Hosted reference documentation, versioned and shareable with your team or the public;
- A ready-to-use MCP server, where every operation is a tool an AI agent can discover and call.
Access control and versioning are built in, so exposing the API to an agent does not mean exposing it to the world. Publish a new version of the spec and both the docs and the MCP tools update together.
Why serving tools beats writing wrappers
| Hand-built MCP bridge | Spec-served MCP |
|---|---|
| Each tool described by hand | Tools generated from operations, schemas and examples |
| Drifts from the real API | Always identical to the deployed spec version |
| Custom auth code per deployment | Access control managed in the console |
| Another service to host and monitor | Runs on Powerduck Cloud behind a stable URL |
The agent gets better tools too: descriptions, required fields, enum values and example payloads all come from the contract engineers already maintain, instead of from a summary someone typed once.
The five-minute path
- Open the console and choose Open your API.
- Upload the spec (or import a Postman collection / cURL command).
- Check the generated documentation and the MCP endpoint URL.
- Set visibility and access for the version.
- Add the MCP endpoint to your agent client — Cursor, Claude Desktop, or anything Model Context Protocol compatible.
Prefer to stay fully local?
The desktop app is local-first: your spec stays on your machine, no account required, and it can serve MCP tools locally for agents running on the same machine. Cloud is there when you need a stable shared URL, team access and version history — not a prerequisite for doing the work.
The contract is already the machine-readable description of your API. Let it do the talking.