Guide

Create an MCP server from OpenAPI without code

No SDK, no hand-written server, no boilerplate. There are two genuinely code-free ways to get from an OpenAPI spec to a live, governed MCP endpoint on this platform — one is a console wizard, the other is asking an AI client to do it for you in plain English. Both run the exact same pipeline underneath.

Method 1: The console

  1. Sign up — a tenant and default environment are provisioned automatically.
  2. API Contracts → Upload OpenAPI — paste your spec or point at a URL. No YAML editing, no CLI.
  3. Generate tools — select operations from a list; names, schemas, and risk classes are derived automatically.
  4. Create server → attach tools → Publish — three clicks, and you get a connectable MCP endpoint.

Every step is a form or a button. See how the mapping works if you want the mechanics, or the full tutorial for a screen-by-screen walkthrough.

Method 2: Ask an agent to do it for you

The platform also runs its own MCP server — a "meta" server whose tools don't call your API, they call the platform itself. Connect it into Claude (or any MCP client) the same way you'd connect any other server, and you can create a new MCP server just by describing what you want:

"Create an MCP server from https://example.com/openapi.json, call it Widgets API, boundary public."

The agent calls a tool named create_server_from_openapi, which chains through the identical ingest → generate → create → publish pipeline the console uses, and hands back the install URL — in one message, with no forms in between.

Setting it up

The endpoint is POST https://mcpplatform.dev/mcp/platform. It requires a platform account and a session token — the same token field returned in the JSON response when you sign up or log in via POST /v1/auth/login. Add it to an MCP client as an authenticated HTTP server with that token as a bearer credential, e.g. in Claude Code:

claude mcp add --transport http platform https://mcpplatform.dev/mcp/platform --header "Authorization: Bearer <your session token>"

Once connected, four tools are available:

ToolWhat it does
create_server_from_openapiFull spec (URL or raw text) → published server, one call.
create_single_tool_serverOne endpoint (method/path/base URL) → published server. No spec at all.
list_environmentsReuse an existing environment instead of provisioning a new one.
get_serverLook up a server's tools and install URL by id.

Under the hood a tools/call for create_server_from_openapi looks like this — the agent builds this for you, but it's a plain JSON-RPC call like any other MCP tool invocation:

POST /mcp/platform { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "create_server_from_openapi", "arguments": { "specUrl": "https://example.com/openapi.json", "name": "Widgets API", "boundary": "public" } } } → { "result": { "content": [{ "text": "{ \"mcpServerId\": \"srv_...\", \"installUrl\": \"https://mcpplatform.dev/mcp/srv_...\", \"toolCount\": 5, ... }" }] } }
Heads up: creation calls require a verified email on your account — the tool returns a clear error telling you to verify first if it isn't. This is the same email-verification gate the console enforces before publishing, applied consistently regardless of which path you use.

Which one to use

The console is better when you want to review generated tools, adjust a risk class, or attach tools to an existing server. The meta MCP server is better when you're already in a chat with an agent and just want a server to exist — including the no-spec, single-endpoint path, which is the fastest way to wrap one existing endpoint. See How to add MCP to an existing API for that case specifically.

Start free See the OpenAPI mapping reference