From a public OpenAPI spec to a governed, published MCP server that Claude can call — sign-up to first tool call.
This walkthrough takes a public OpenAPI 3.x spec, turns its operations into governed MCP tools, publishes a versioned server, and connects that server to Claude as a custom connector. You'll do this once in the console UI, then verify it by asking Claude a question that triggers a real tool call.
The example API is any public REST service that ships an OpenAPI/Swagger document — pick one you already know so the generated tool names make sense to you. The steps are identical regardless of which spec you use.
Create an account. Signing up provisions a tenant — an isolated workspace with its own servers, contracts, tools, and audit trail, enforced at the database layer via Postgres Row-Level Security (more on that in the RLS tutorial). You'll land in the admin console once your tenant is ready.
In the console, open Environments and add one if you don't already have one you want to use (every tenant starts with a default production environment). An environment groups your servers by deployment target — production, staging, whatever fits how you work — and every MCP server must be bound to one before it can publish.
Go to Servers → New MCP Server. Give it a name and description, then pick a trust boundary:
For a first API you're just testing, internal is the safest default — you can widen the boundary later once you've reviewed the generated tools. (The boundary system is covered in depth in Governing tool risk.) Assign the environment you just created and move on.
Under Contracts → Import, either paste a spec URL or upload the JSON/YAML directly. The platform parses and validates it, then runs a validation report that flags missing schemas and risky defaults before you're allowed to generate anything from it.
Review the validation report in the console before continuing. Fix anything flagged as an error in your source spec and re-import if needed — warnings are informational and won't block generation.
From the contract's operation list, select the operations you want exposed and generate tools. Each operation is mapped deterministically: its operationId becomes the tool name, its method and path decide whether it's read-only, and a risk class (low, medium, or high) is derived from the HTTP method and destructive-sounding verbs in the path or operation id (delete, remove, purge, and similar).
Review each generated tool's description and risk classification in the console before assigning it to your server. This is your chance to tighten a description or override a risk level before anything is callable.
Attach the generated tools to your server and publish. Publishing signs an immutable, versioned bundle — future changes require a new version rather than mutating a live one. Once published, the console shows the server's public MCP endpoint, of the form:
That URL — not a marketing "install" link — is what you paste into an MCP client. It resolves to whichever version is currently active for that server.
Wondering how this compares to writing your own MCP server by hand? See MCP Platform vs. DIY for a side-by-side on setup time, isolation, and governance.