The team already runs order lookup, inventory lookup, and shipment tracking. Now the business wants an AI assistant: give it an order number and get a summary of the order status and shipping progress.

The business APIs exist, yet the development backlog grows anyway. Define tool names. Hand-write input parameters. Describe every field. Translate parameters into HTTP requests. Shape the responses. Then, when one API field changes, the tool definitions change with it. Before long, one interface has two descriptions that have to be maintained in lockstep.

When an API is already described in OpenAPI, those descriptions should keep doing the work.

Generate the MCP server from the specification

Powerduck's OpenAPI-to-MCP conversion turns the spec's operations into MCP tools, reusing the parameter structures, descriptions, and referenced resources. For order lookup, the specification already states the orderId path parameter, the method, the response shape, and the auth requirements. After generating the MCP server, any MCP-capable client can discover the tool and call it to query an order when the calling conditions are met.

That removes a layer of hand-written wrappers. Maintenance attention goes back onto the API itself: are the names clear, are the parameters complete, are the descriptions good enough for a caller — human or agent — to make the right choice. The generated server connects to the services you already run; your API still does the actual order lookup and business processing.

Get the reads right before expanding the surface

A first version of the support assistant only needs order and shipment queries. A customer asks whether an order has shipped; the agent fetches the order through the tool, fetches the shipment, and answers from the actual responses. Cancellations and refunds — the write operations — get evaluated separately, with their own permission and confirmation design.

That sequencing has a practical payoff. Prove first that the tool descriptions are clear, the parameters pass through correctly, and upstream authentication works. Then widen the surface. MCP solves the connection problem; it does not replace business authorization. A tool being discoverable does not mean every caller should be allowed to execute it. Upstream auth, MCP access keys, and per-operation exposure are separate gates for exactly this reason.

Local verification and hosted delivery are separate decisions

Connecting an AI client on your own machine uses the local MCP runtime. Providing a remote service for partners or hosted agents uses the HTTP deployment, or a managed MCP endpoint published through Powerduck Cloud, which can host the documentation on the same document. Partners read how the API works and connect to the enabled MCP service in whatever tooling they use.

The local specification stays the maintained source. Edit and verify there, then publish the confirmed version, so experimental in-progress work never becomes an external service commitment by accident.

Two MCP use cases, two different jobs

Both come up in a Powerduck workflow, and keeping them straight makes the architecture obvious:

SituationWhat MCP does
AI helping build the APIQueries contract facts, surfaces auth requirements, and verifies the implementation against a test service
AI using the running APICalls the business service according to the generated tool definitions

The first teaches the agent about the API you are building. The second puts the API you already run into an agent's tool system. We wrote about the delivery mechanics for a partner-facing version in exposing 12 of 47 endpoints as a hosted MCP server.

Give an existing API another kind of entrance

APIs used to have frontends, mobile apps, and other services as consumers. AI clients are now on that list. If you already have a reasonably complete OpenAPI file, start with two or three read-only operations: tighten the descriptions, generate the MCP server, connect a client, and verify one real query. Let the tooling absorb the duplicated adapter work, and spend your attention on the business rules and the calling experience.