openapi-to-mcp

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.

• Spec source: a file path in the workspace, a URL (e.g., https://api.example.com/openapi.json), or pasted into chat. If pasted, save it to openapi.yaml or openapi.json first.
• Server base URL: take it from servers[0].url in the spec if present; otherwise ask. Multiple servers entries are common (prod / staging) — confirm which one.
• Auth scheme: read components.securitySchemes. If multiple, ask which to use. If the API needs an API key or token, ask which env var should hold it (API_KEY, OPENAI_API_KEY, etc.). Don't ask for the secret itself — never put it in the conversation or commit it.
• Operation filter: large specs (Stripe, GitHub) have hundreds of endpoints. Ask whether to expose all operations, a tag (pets, users), or a hand-picked list. Default to "all" for specs under ~30 operations; ask above that. See references/mapping-rules.md for filtering patterns.
• Widgets: ask whether any operations should render a widget in the chat (a React component shown inline next to the LLM's reply), or whether this is a pure tools-only server. The default for an OpenAPI wrapper is tools-only — the LLM reads JSON and talks. Pick widgets only when the user wants a richer UI for specific responses (a map for a geocoding endpoint, a chart for a metrics endpoint, a card list for a search result). This answer drives the scaffold template in step 3: tools-only → --template blank, any widgets → --template mcp-apps (which ships the resources/ widget infrastructure pre-wired). If the user wants widgets on most operations, the mcp-apps-builder skill is usually a better fit than this one — flag that and confirm before proceeding.