No code, no hand-written MCP server, no manually-written risk policy. Paste an OpenAPI spec, generate tools, publish, and give the URL to Claude. Here's the whole loop using a small public store API as the example — you can follow along with the exact same spec.
To keep this concrete, every step below uses a small public fixture API — a store with products and orders — that's live right now and needs no API key:
Five operations, three HTTP verbs, and — as you'll see in a minute — that mix is exactly what makes it a good demo, because the platform ends up generating tools across all three risk classes without anyone manually assigning risk to anything. The full spec is a plain OpenAPI 3.0 document; grab it at /demo-store-openapi.json if you want to paste it in yourself and follow along.
Head to the signup page, fill in company / name / email / password, and you're dropped straight into the console with a tenant and a default production environment already provisioned — no separate setup step before you can register an API.
In the console, go to API Contracts → Upload OpenAPI and paste the spec (or point it at a URL — the console accepts either). Submit, and you'll get back a validation report before anything is generated:
For this spec, you'll see exactly one warning, and it's worth reading rather than dismissing: cancelOrder has no x-confirm flag. That's not a mistake in the spec — it's the platform telling you upfront that this operation is about to come out as a high-risk tool, because destructive operations without an explicit confirmation hint get flagged automatically. Keep that in mind; it shows up again in the next step.
From the contract's operation list, select all five operations and generate. Each operation is mapped deterministically: the OpenAPI operationId becomes the tool name (camelCase → snake_case), and a risk class is derived from the HTTP method — GET/HEAD is always low, DELETE is always high, everything else (writes without a destructive verb) lands at medium. Nobody sets these by hand:
| operationId | tool name | method | risk |
|---|---|---|---|
| listProducts | list_products | GET | low |
| getProduct | get_product | GET | low |
| createOrder | create_order | POST | medium |
| getOrder | get_order | GET | low |
| cancelOrder | cancel_order | DELETE | high |
That's the warning from step 2 made concrete: cancel_order comes out high risk purely because it's a DELETE — which is exactly the kind of tool you want an LLM to be gated on, not one you want to discover is ungated after the fact.
Create an MCP server named Demo Store, set its boundary to public (it's a public demo — see Governing tool risk for when you'd pick internal or partner instead), and let the environment default to the one created from the spec's base URL. Attach all five generated tools, then publish version 1.0.0. Publishing signs an immutable, versioned bundle of exactly those tools — you get back a real MCP endpoint, not a placeholder:
That URL is what goes into an MCP client. It's a live Streamable-HTTP JSON-RPC 2.0 endpoint — initialize, tools/list, tools/call — resolving to whichever version is currently active.
Once connected, ask Claude something like:
Claude calls list_products, reads back the catalog with prices, matches "Insulated Water Bottle" to its product id, then calls create_order with {"productId": "prod_002", "quantity": 2} — and gets back a confirmed order with an id, total price, and status: "confirmed". That's a real round trip to the store API's /orders endpoint, not a canned response.
Now ask it to cancel that order. Claude calls the cancel_order tool — the same one flagged high risk back in step 3 — and the order comes back with status: "cancelled". This particular demo lets it through so you can see the full round trip; in a real deployment, a high-risk tool is exactly where you'd wire up an approval step (a human or policy check in the loop before the call goes out) rather than letting the model act unattended. The risk class doesn't change what the tool does — it changes what gets to happen automatically versus what has to be confirmed first.
The Demo Store is intentionally public so this walkthrough needs zero credentials. Most real internal or partner APIs aren't — for those, Credentials → Add OAuth provider lets you register a token endpoint, scopes, and a client credential reference, then attach that provider to a server during tool assignment, so calls go out authenticated without the token ever touching Claude or the client side.
Spec: /demo-store-openapi.json · Base URL: https://mcpplatform.dev/demo/store/v1. Want the generic version of this walkthrough with your own API instead of the demo store? See Connect Your First API.