Download for macOS
Skill

openapi-to-mcp

@mcp-use Updated 2026-10-22

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.

agent-pluginsagentic-frameworkaiapps-sdkchatgptclaude-codeclaude-connectorsllms

Install

With your agent

Install OMGSkills skill "mcp-use/mcp-use:openapi-to-mcp" into this agent's normal skills directory: use the OMGSkills MCP get_skill tool, install only the pinned_install commit and path, verify SKILL.md against pinned_install.skill_md_sha, and stop if MCP or the pin is unavailable. Do not overwrite or change existing skills without asking me.

Manual command

git clone https://github.com/mcp-use/mcp-use /tmp/mcp-use && ln -s /tmp/mcp-use/skills/openapi-to-mcp ~/.claude/skills/openapi-to-mcp

From README

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.