Step 1 — Import what you already have
Paste an OpenAPI spec, point at a GraphQL endpoint, or pick a managed connector. CMD+K parses it and drafts one tool per operation — names, typed inputs, descriptions — in about a minute. This is the moment most teams expect to take a sprint.
Step 2 — Curate ruthlessly
Don’t expose all 27 endpoints. Models pick tools by reading descriptions, and a focused set of 10–15 well-described tools outperforms a full API dump every time. Rewrite descriptions in plain language (“Search a customer’s orders by email or order id”), mark risky operations, and leave destructive endpoints out until you have confirm-flows in place.
Step 3 — Decide who calls are made as
This is the step that separates production from prototype. Options, in increasing strictness: a shared API key (fine for internal read-only data), per-user API keys, or full OAuth where each end user connects their own account and every tool call runs with that identity — attributed, rate-limited, revocable. CMD+K hosts the OAuth 2.1 gateway and consent screens, so “strict” stops meaning “slow.”
Step 4 — Publish, connect, watch the logs
Publishing gives you a live MCP endpoint on our gateway or your own domain, plus a hosted connect page your customers use from Claude and any MCP-speaking client. From day one you get per-tool analytics and per-user logs — which tools get used, by whom, and what failed. That feedback loop is where good MCP servers get great.
Prefer to hand-roll it?
Fair. The official MCP SDKs are solid, and for a weekend project they’re all you need. What you’re signing up to operate is everything around the protocol: token storage, per-user OAuth flows, rate limits, retries, logs, uptime. That’s the layer teams like Mapgrid (illustrative scenario) chose not to own — and why the wizard exists. Try it on the free trial; your spec will tell you in ten minutes whether this is your path.