# Spec to MCP

> One OpenAPI 3.x or Swagger 2.0 spec (JSON or YAML) turned into an mcp-use MCP server, following the deterministic
> mapping rules of the skill from mcp-use/mcp-use. Paste the spec (or drop it); the browser reads it, inlines its local
> $refs, and maps every operation to one tool: the name from the operationId in snake_case (or method_path, collisions
> suffixed with the method), the description from the summary, description and tags, and one flat zod schema from the
> path, query, header (header_*) and JSON body fields. It writes .env.example from the servers and security schemes,
> index.ts with an OPERATION_ALLOWLIST (deprecated and internal operations left out), the skill's own templates and a
> setup.sh that writes them all into a create-mcp-use-app project. It flags where the templates fail the spec: apiKey in
> a query, form or multipart bodies, binary responses, undeclared path parameters, missing descriptions, large specs,
> external refs. Metered runs write the review and the build. Built on the SkillSafe skill @mcp-use/openapi-to-mcp,
> from mcp-use/mcp-use (Apache-2.0).

https://spec-to-mcp.skillsafe.ai/

## What is free
- The mapping: every tool with its name, route, parameters (required marked), description and zod schema, and why a tool is left out.
- The findings with an id (M1, M2, ...), an area, a severity, the line, what the page saw, the fix, and whether the page already handled it; the skill's checklist marked from them.
- The generated files: setup.sh (index.ts, src/operations.ts, src/schema.ts, src/auth.ts, src/client.ts, scripts/load-spec.ts, .env.example, openapi.dereferenced.json), the tools and findings as CSV, everything as JSON.

## The metered lanes
Two tasks on gpt-terra, metered per run, routed by `task`. Input string fields: `task` (review or rewrite), `unit`, `spec`, `carry` (rewrite only: the review's decisions and scope) and `facts` (the page's read).
- `review` replies with `summary`, `scope` (the tools to expose and why), `findings`, `cleared`, `extra` (up to five issues a read cannot see, on real lines), `plan`, `tests` (mcp-use client commands and inspector prompts, with the failure paths) and `caveats`.
- `rewrite` (the Build) replies with `summary`, `files` (index.ts, src/client.ts, src/auth.ts, .env.example), `changes`, `kept` and `caveats`.
The page holds every reply to its read: each id accounted for exactly once, the scope within the mapped tools, a test planned for every tool, and the build's files read as text for the scope, streamable HTTP, declared env vars, auth headers, encodings and secrets. The page never runs, builds or tests the server; use a least-privilege key or OAuth scopes for it.

## Links
- API tutorial: https://spec-to-mcp.skillsafe.ai/api.html
- Source skill: https://skillsafe.ai/skill/@mcp-use/openapi-to-mcp

Independent tool: not affiliated with or endorsed by Anthropic (Model Context Protocol), the OpenAPI Initiative or the Linux Foundation (OpenAPI), or mcp-use / Manufact.