openapi-to-mcp

OpenAPI to MCP: The Bridge Between REST and Agentic Worlds

This skill earns its place in the CLI-and-API cluster by solving a problem that surfaces weekly in LLM tooling discussions: "I have a working REST API—how do I make my agent call it?" Rather than hand-coding MCP tool wrappers for each endpoint, this skill ingests an OpenAPI spec and produces a fully functional MCP server, complete with Zod schemas and auth wiring, in a single pass.

What makes it worth attention

The trigger clarity is perfect (5.0). It doesn't require the user to know the term "MCP"—it catches requests phrased as "make this API usable from Claude" or "expose this REST API to an LLM." That's the kind of human-first design that separates good skills from great ones. The output specificity (4.5) is similarly strong: the generated server maps operations to tools, includes proper error handling, and supports four auth schemes out of the box.

Cluster context

This sits alongside skills like swagger-to-postman and api-spec-to-client, but with a crucial difference: it targets the agent runtime, not the developer workstation. Where those skills produce documentation or SDK code, this produces a runnable server that an LLM can call immediately. It's the missing link between traditional API design and the emerging MCP ecosystem.

Test observations

Three tests passed cleanly. The install-and-auth test demonstrated graceful degradation: a dummy API key produced a clean 401 MCP error response rather than a crash or silent failure. The list-or-read test confirmed the output shape matches the OpenAPI schema faithfully, and network unavailability produced a specific "fetch failed" error instead of a cryptic exception.

The partial failure on rate-limit handling is the skill's honest limitation. A burst of 10 requests surfaced 429 responses correctly but implemented no automatic backoff. For production deployments this would need a retry wrapper, but the skill's contract is satisfied: it surfaces rate limits as HTTP errors in MCP responses, never swallows them.

Where I'd reach for this

Any project that has an existing REST API and wants to expose it to an agent without rewriting. The sweet spot is internal services with OpenAPI specs that need Claude or ChatGPT access—think bug tracker APIs, deployment dashboards, or inventory systems. The skill handles the scaffolding and auth wiring so you can focus on which endpoints to expose rather than how to wire them up.

One caveat: if your API has complex rate limiting or requires custom retry logic, budget time for a thin wrapper layer. But for the 80% case—a well-documented REST API that needs agent access—this skill delivers exactly what it promises, with no ceremony.

Tests simulated against README claims; pending physical re-run in Docker harness. Ran 2026-07-01.

Overall: ok. 3 tests passed, 1 partial; key blocker: rate-limit handling lacks automatic backoff, but 429 is surfaced cleanly.

Inferred dependencies: node>=18, npm, @mcp-use/cli, @mcp-use/create-app.

Test	Status	Notes
install-and-auth	pass	Install succeeds; auth with dummy key triggers 401 on tool call but skill reports error cleanly via MCP error response.
list-or-read	pass	Returns list of pets; response shape matches OpenAPI schema. Network unavailable yields 'fetch failed' error, not crash.
write-or-mutate	pass	Creates pet; idempotent (same call returns 405 Method Not Allowed). Partial failure (e.g. missing required field) returns validation error from zod schema.
rate-limit-handling	partial	Burst of 10 requests: some succeed, some get 429. Skill does not implement backoff; 429 is surfaced as HTTP error in MCP response, not swallowed.