For teams giving an LLM a handle on their REST API
Spec to MCPoperationId, parameters, requestBody, securitySchemes. The mapping happens right here; the scope and the edge cases get a review.
Paste one OpenAPI 3 or Swagger spec - JSON or YAML. Your browser reads it, inlines its $refs, and maps every operation to one MCP tool by the skill's rules: the name from the operationId, the description from the summary, and one flat zod schema from the path, query, header and body fields. It writes .env.example from the security schemes, index.ts with an allowlist, and a setup.sh that drops the whole server into a create-mcp-use-app project. Where the skill's templates would fail this spec - a key in the query, a form body, a PDF response, a path parameter nobody declared - it says so.
The spec free
The scan free
What the scan found
The skill's mapping and ship checklist
The generated server free
setup.sh writes index.ts (with the OPERATION_ALLOWLIST), the skill's src/operations.ts, src/schema.ts, src/auth.ts, src/client.ts and scripts/load-spec.ts, .env.example and the dereferenced spec into a project made with npx create-mcp-use-app@latest my-mcp --template blank. Two changes to the templates: client.ts imports readFileSync, since the ESM project has no require(), and its DEBUG_HTTP log prints header names only, never the key. Everything a finding marks "by hand" is still the template's behavior.
Before you connect it: the page writes these files; it does not run, build or test the server. Every exposed tool can do whatever the key in .env can do on the real API, so give the server its own least-privilege key or OAuth scopes (read-only if the tools only read), keep write and delete operations out of the allowlist unless you want an agent calling them, and never commit .env.
setup.sh
The review metered
Pricing as soon as the session is ready...
Sign inThe reply could not be read. Here it is as it came back:
Caveats
Caveats
The page's check of this reply
Saved reviews
How it works - and what it cannot see
The page reads JSON and the YAML specs are written in (block maps and lists, quoted strings, flow [] and {}, | and > blocks), inlines every local $ref the way swagger-parser does (a cycle becomes z.unknown()), and runs the skill's mapping exactly as its templates do at runtime - so the tool names, descriptions and zod schemas on this page should match what the server registers (the page mirrors the templates; it does not run them). This free read never leaves the browser; the metered review and build send the spec to the model.
It cannot see which tools the person should expose, whether a write operation needs confirmation, or how the upstream really answers - that is the review, which sets the scope and writes the test plan. The page reads the build's files as text - it does not compile, run or call them - and checks: every tool in scope registered, streamable HTTP, every env var declared, the auth header each scheme needs, no secret in code.