Openapi To MCP
Build and deploy an MCP server from an OpenAPI / Swagger spec using the mcp-use...
Install
npx skills add mcp-use/mcp-use --skill openapi-to-mcp -g -a claude-code -y- Repository
- mcp-use/mcp-use10.8k
- Category
- Testing
- Updated
- 5d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Build and deploy an MCP server from an OpenAPI / Swagger spec using the mcp-use TypeScript SDK. Use this skill whenever the user wants to "turn this OpenAPI spec into an MCP server", "make this API usable from Claude/ChatGPT", "wrap this Swagger doc as MCP tools", "expose this REST API to an LLM", "generate MCP tools from a spec", or pastes/attaches an `openapi.yaml`, `openapi.json`, or `swagger.json` and asks for a Claude-compatible version. Trigger even if the user doesn't say "MCP", if they describe an existing HTTP API (REST endpoints, an internal service, a third-party API they have a key for) and want an LLM to call it, this is the right skill. Covers spec ingestion (file path, URL, or pasted), operation-to-tool mapping, auth wiring (apiKey, bearer, basic, OAuth bearer), scaffolding with `create-mcp-use-app`, tool generation with proper zod schemas, live testing in the mcp-use inspector, and deploying to Manufact / mcp-use cloud.
Build an MCP server from an OpenAPI spec
Turn an existing REST API, described by an OpenAPI 3.x or Swagger 2.0 document, into an MCP server. Each operation in the spec becomes one MCP tool the LLM can call. The server runs locally for testing and ships to Manufact / mcp-use cloud with one command.
This skill is the end-to-end recipe: scope → ingest spec → map operations → scaffold → generate tools → wire auth → test → deploy.
Core philosophy: the spec is the contract
The OpenAPI document is the source of truth. Tool names, descriptions, parameter shapes, and auth requirements all come from the spec, they should not be invented. This matters because:
- The LLM trusts descriptions. If the spec says
summary: "Get current weather for a city", that's exactly what the LLM will read when deciding whether to call the tool. Hand-rolled summaries drift; spec-derived summaries stay in sync if the API changes. - Zod schemas mirror OpenAPI schemas. Every parameter, path, query, body, becomes a field in one zod object. Required/optional, enums, min/max, and descriptions all carry over. The LLM uses the schema to figure out what to ask the user for.
- Auth lives outside the spec. OpenAPI declares the auth scheme but never the secret. Secrets come from env vars; the spec tells you which env vars to require.
When in doubt, prefer mechanical fidelity to the spec over creativity. The LLM is doing the creative part, talking to the user, and only needs a faithful, well-typed handle on the API.
Process
1. Scope the request (use AskUserQuestion)
Before writing code, lock five things via the AskUserQuestion tool. All five are about the API and what to build, deployment is a separate question we ask later in step 10, when the user can actually evaluate it against a working server.
