# We gave a partner’s AI agent 12 of our 47 endpoints. Here is how.

A logistics partner asked whether their coding agents could call our shipping API. Two years ago that request meant a project: a wrapper repository, hand-written tool descriptions, an auth layer, a deploy pipeline, and a human keeping it in sync. This time it took about twenty minutes in [Powerduck Cloud](https://www.powerduck.com/cloud?ref=powerduck.com). Here is the exact sequence.

## 1. Add the specification

From the dashboard I added the document from our Git repository (a file upload or a URL works the same). Large files go straight to object storage through a presigned upload URL — the API server is not in the data path — and each version records its SHA-256. The source document is never modified by anything that follows.

## 2. Expose twelve operations, not forty-seven

The exposed-operations surface lists one row per operation with search and tag grouping. I disabled the internal and administrative endpoints in batches by tag, then unchecked a few draft operations individually, leaving twelve public. The selection is stored separately from the spec — keyed by `operationId` with method and path as fallback — so toggling exposure never edits our file. Plan limits frame the decision: 10 operations on Free, 1,000 on Pro, 10,000 on Team.

## 3. Switch on MCP; docs stay independent

Rendered documentation is enabled by default; the managed MCP endpoint is **off until you switch it on**. The two surfaces have separate gates — a documentation password does not protect MCP and vice versa — which is exactly what I wanted, because humans read docs but agents call tools.

## 4. Issue the agent key

I generated an MCP access key. The full key is shown once; afterwards only the last four characters are visible. Every MCP request must present it as a `Bearer` token, comparison is constant-time, and a missing or wrong key gets a `401`. Rotating it later is one click when the engagement ends. The partner pasted the endpoint and key into their agent config — done.

## 5. Let the server authenticate to us

The MCP server calls our real upstream API on the agent’s behalf, so I configured upstream authentication separately from the agent-facing gate: a `BEARER` token the server injects (write-only — secrets can be saved but never read back), a base URL override pointing at the partner sandbox, and a request timeout. `NONE`, `BASIC` and header/query `APIKEY` are the other supported types.

## 6. Pin them to a version

Every change creates a new immutable version — v1, v2, v3 — with diff and rollback; nothing is overwritten. The partner link is pinned to v1, so when we publish v2 their agents keep working against the contract they integrated with until we choose to move them. Pausing the document takes both docs and MCP offline together if we ever need a kill switch.

## What the old "project" would have guaranteed

|                  | Hand-written wrapper            | Served from the spec                      |
|------------------|---------------------------------|-------------------------------------------|
| New endpoint     | Code, review, deploy the bridge | Publish a version; toggle it on           |
| Drift            | Weeks                           | Impossible — same file                    |
| Agent auth       | Built by us                     | Rotatable bearer key, constant-time check |
| Upstream secrets | In our repo                     | Write-only config in the hosting layer    |
| Partner rollback | Git archaeology                 | Pin or restore an immutable version       |

The MCP server was never a codebase. It was a publication setting on the contract. The [Cloud quickstart](https://www.powerduck.com/docs/cloud/quickstart?ref=powerduck.com) covers the same six steps.