Your API is already live, already has consumers, and you're not about to touch its code to make it agent-friendly. The right approach isn't to modify it at all — it's to put a governed MCP server in front of it, and start with far less surface area than the whole thing.
An MCP server on this platform is a separate layer that calls out to your API's existing base URL when a tool is invoked — it's a caller, not a modification. Your API keeps serving its existing clients exactly as before; it just gains one more consumer that happens to be policy-gated, credential-brokered, and audit-logged on the way in.
You don't need a full OpenAPI spec, and you don't need to expose everything on day one. If there's one read endpoint you'd be comfortable letting an agent hit — a lookup, a status check — wrap exactly that one, either in the console or by asking an agent to do it:
In the console: Tools → New Tool → Define manually. Hand-author the name, HTTP method, path, input fields, and risk class — no spec, no contract, nothing to upload.
By asking an agent: connect the platform's own meta MCP server (see creating servers without code for setup) and use its create_single_tool_server tool, which takes just a method, path, and base URL — no spec required:
Either path produces a live, published, single-tool MCP server pointed at your real API — because it's a GET, it's automatically classified low-risk, so there's nothing to gate before an agent can call it.
Skip the manual step and register the whole contract instead — you still choose exactly which operations become tools, and can leave the rest ungenerated until you're ready. See converting OpenAPI to MCP or converting an older Swagger 2.0 doc.
If your API needs a token or API key, you don't put that credential in the agent's hands. Register it once under Credentials → Add OAuth provider (or a stored secret) and attach it to the environment — the runtime brokers a short-lived downstream credential per call, so the agent never sees the raw key, and your existing auth setup doesn't change.
Once the first tool is live and audited, adding the next one is the same choice again: manual, spec-driven, or asked-for-by-an-agent, each operation individually risk-classified as you go. Nothing forces you to expose the rest of the API on any particular timeline — the governed surface grows exactly as fast as you're comfortable with, one tool at a time. For gating write and destructive operations once you get there, see Governing tool risk.