Powerduck logo Powerduck
Docs GitHub Download

Local-first — your spec never leaves the machine

One openapi.yaml. Your entire API workbench.

Powerduck works with the OpenAPI specification already in your repository — no migration required. Edit the contract, debug APIs against it, generate MCP tools from it, and publish documentation from the same source of truth.

Download Powerduck Licensing & evaluation

Evaluate free for as long as you like. Buy when it sticks.

macOS · Windows · Linux  ·  OpenAPI 3.0 / 3.1 / 3.2  ·  Local-first  ·  edits files in place

Try:
~/commerce-api/openapi.yaml OpenAPI 3.1.0 3 problems unsaved
142 /users/{id}:
143 get:
144 operationId: getUser
145 summary: Retrieve a user
146 tags: [Users]
147 parameters:
148 - $ref: '#/components/parameters/UserId'
149 responses:
150 '200':
151 description: The requested user
152 content:
153 application/json:
154 schema:
155 $ref: '#/components/schemas/User'
156 '404': # description is required
157 contents:
158 application/json:
159 schema:
160 $ref: '#/components/schemas/Erorr'
161 delete:
162 summary: Delete a user
Problems 2 errors · 1 warning validated against 3.1 dialect
156:9 contents is not a valid Response Object key. Did you mean content? oas3-schema
160:24 Unresolved $ref — schemas/Erorr does not exist. ref-resolution
162:7 Operation has no operationId. It will be skipped when generating MCP tools. operation-operationId
Ln 156, Col 9 YAML UTF-8 Spaces: 2 3.1.0
Collections generated from openapi.yaml Postman import contract checks on
GET ▾
{{baseUrl}}/users/{{userId}}?include=profile
Staging ▾
Params 1 Auth bearer Headers 3 Body Scripts Settings
# GET has no requestBody in the specification — body disabled
# Path parameter id resolved from environment → userId = usr_8Kd2Xa
200 OK 148 ms 1.2 KB Contract: 1 mismatch
Body Headers 9 Cookies Contract 1 Timeline 
{
  "id": "usr_8Kd2Xa",
  "email": "ada@example.com",
  "created": 1757030400,
  "profile": {
    "name": "Ada L.",
    "locale": "en-GB"
  },
  "scope": "users:read orders:read"
}
Contract mismatch — response differs from the specification scope is present in the response but is not declared on components/schemas/User. Add the property to the schema or remove it from the handler.
mcp://localhost:7433 running stdio + HTTP

Generated from openapi.yaml

6 tools 7 resources 1 degraded regenerates on save

Every operation with an operationId becomes a tool. Arguments come from parameters and requestBody. Nothing is hand-written.

POST /auth/login → operationId → loginUser
loginUser

Exchange credentials for a bearer token.

email : string password : string
healthy args from requestBody
GET /users/{id} → operationId → getUser
getUser

Retrieve a single user by identifier.

id : string include? : string
healthy args from 2 parameters
POST /orders → operationId → createOrder
createOrder

Create an order for the authenticated customer.

items : array currency : string
healthy args from requestBody
POST /orders/{id}/refund → operationId → refundOrder
refundOrder

Refund an order in full or in part.

id : string amount? : integer
degraded amount has no description
14:02:11 watch openapi.yaml changed (line 144)
14:02:11 build parsed 3.1.0 · 11 operations · 14 schemas
14:02:11 build 6 tools, 7 resources · 1 skipped (no operationId)
14:02:12 serve listening on stdio and http://localhost:7433
14:02:31 call getUser { id: "usr_8Kd2Xa" } → 200 in 148 ms
docs.example.dev/reference/users/get static export in sync with spec

Retrieve a user

GET /v1/users/{id}

Returns the user object for a valid identifier. If the user has been deleted, an Error object is returned with status 404.

Path parameters
id string Required
The identifier of the user, prefixed with usr_.
Query parameters
include string
Expand a related object.

OpenAPI spec editor

OpenAPI Spec Editor

The outline follows the specification's real structure, not a guess based on indentation. Navigate paths and components as a tree, and fix errors where they live.

  • Schema-aware validation. Validate against the 3.0, 3.1 or 3.2 dialect your file actually declares.
  • Resolved $ref navigation. Jump to definitions, inspect usages, and get suggestions for misspelled references.
  • Edits in place. Your repository remains the source of truth.
  • Problems with rule names. CI failures and editor diagnostics speak the same vocabulary.
openapi.yaml 3 problems
▾ info
▾ paths
　/users
　/users/{id}
　/orders
▾ components
　schemas
　responses
142 /users/{id}:
143 get:
144 operationId: getUser
145 responses:
156 contents:
160 $ref: Erorr
Problems · 2 errors · 1 warning
156:9 contents is not a valid Response Object key
160:24 Unresolved $ref. Closest match: Error
API Debug contract checks on
▾ Users
　GET listUsers
　GET getUser
▾ Orders
　POST createOrder
GET {{baseUrl}}/users/{{userId}} Send
Params Auth Body Headers 
{
  "id": "usr_8Kd2Xa",
  "email": "ada@example.com",
  "scope": "users:read"
}
Contract mismatch — "scope" is not declared on User.

API debugging

API Debugging Against Your Spec

A request builder shaped like the tools developers already use, plus one thing those tools cannot do by default: verify responses against the contract.

  • Collections generated from paths and tags. No import step and nothing to manually re-sync.
  • Contract checks on every response. Detect undeclared properties, missing fields and type drift inline.
  • Environments and variables. Reuse existing development and staging configurations.
  • Security from securitySchemes. Bearer, API key and OAuth configuration starts from the specification.

MCP server generator

Generate an MCP Server from OpenAPI

Your specification is already a tool manifest. Powerduck compiles it into a runnable MCP server and shows exactly which OpenAPI fields produced each tool.

  • Visible provenance. Every tool traces back to its operation, operationId and schema.
  • Degraded and skipped states. Missing metadata is visible instead of silently producing weak tools.
  • Regenerates on save. Change the specification and tools update without a build step.
  • Local transports. Run through stdio or HTTP for local agents and workflows.
mcp://localhost:7433 running
Generated from openapi.yaml 6 tools 7 resources
GET /users/{id} → operationId
getUser
id: string
POST /orders → operationId
createOrder
items: array
POST /auth/login
loginUser
email, password
DELETE /users/{id}
skipped
missing operationId
14:02 build 6 tools, 7 resources
14:02 serve listening on :7433
14:03 call getUser → 200
API Reference static export
Users
Overview
Retrieve a user
List users
Update user

Retrieve a user

GET /v1/users/{id}
Returns the user object for a valid identifier.
Path parameters
id · string · required
Returns
User · object
curl /users/{id}

{
  "id": "usr_...",
  "email": "ada@..."
}

API documentation generator

API Documentation from the Same Contract

Reference documentation generated directly from your OpenAPI model, exported as static files and hosted wherever you want.

  • Parameter tables from schemas. Required flags, enums and descriptions stay synchronized.
  • Multi-language samples. Generate cURL, Node, Python and Go examples from operations.
  • Responses from the real contract. Success and error responses come from the same objects your debugger validates.
  • Static export. No runtime dependency and no documentation platform lock-in.

One source of truth

One OpenAPI file.
Four native capabilities.

Open openapi.yaml or openapi.json locally and Powerduck turns the contract you already own into a complete API workspace. No import. No conversion. No parallel collections. No cloud copy.

OPEN LOCALLY
{ }
openapi.yaml
or openapi.json

The file stays in your repository.

01 Spec Editor

Edit, navigate and validate the real contract.

02 API Debug

Send requests generated from the same operations.

03 MCP Server

Compile operations into agent-ready tools.

04 API Docs

Publish documentation from the same source.

Powerduck

Not another API client.
Not another spec viewer.

It is the local-native workspace built around the OpenAPI file itself.

NO CLOUDYour spec never needs to leave your machine.
NO SYNCThere is nothing else to keep aligned with the contract.
NO COPYYour existing YAML or JSON is the workspace.

Licensing

Buy the desktop license once. Subscribe only if you need hosting.

Powerduck Desktop is a perpetual license — the same local-first product shown above, with nothing that phones home. Hosted MCP endpoints are optional and stay separate from the local workflow.

Powerduck Cloud

Optional hosted MCP endpoint · billed monthly

$29 per spec, per month
  • Stable HTTPS MCP URL for teams and agents
  • Deploy from Git branches automatically
  • Access tokens and request logs
  • Hosted reference docs on your own domain
Start a 14-day trial

Not required for the desktop application. Cancel anytime and your local workflow keeps running.

Evaluation: Powerduck is fully functional before you buy, with no time limit and no feature gates. You will occasionally see a reminder to purchase a license.

FAQ

Questions developers ask first

The practical details around local files, OpenAPI versions, MCP generation and licensing.

Does Powerduck upload my OpenAPI specification anywhere?

No. The desktop application reads and writes OpenAPI files directly from your filesystem. There is no account, no sync and no telemetry. Only optional hosted services involve a remote server.

Which OpenAPI versions are supported?

OpenAPI 3.0, 3.1 and 3.2. Powerduck detects the declared version and validates against the appropriate dialect instead of using a lowest common denominator.

How does the MCP server get generated?

Operations with an operationId become MCP tools. Arguments are derived from parameters and requestBody schemas. Component schemas can be exposed as resources. The generated server updates whenever the specification changes.

Is the desktop license a subscription?

No. Powerduck Desktop is a perpetual license purchased once. Updates within the major version are included. Future major upgrades remain optional.

Can I keep using Postman collections?

Yes. Existing collections and environments can continue to be used. Powerduck treats the OpenAPI specification as the authoritative contract and helps identify where requests drift from it.

Does it work in CI?

Yes. The same validation and generation engine is exposed through @powerduck/openapi-cli, a CI-ready command-line tool that runs during pull requests and automated pipelines. It supports batch testing across 6 protocols (HTTP, SSE, WebSocket, gRPC, MCP, tRPC), configurable concurrency, and JUnit-compatible reports for CI integration.

Explore openapi-cli →