Turn any OpenAPI/Swagger spec into MCP tools — so Claude and other AI assistants can call your REST APIs.
Point mcp-openapi at any OpenAPI 3.x or Swagger 2.0 spec URL and it generates tools automatically. No code generation, no config files, no boilerplate. Your AI assistant gets callable tools for every API endpoint in seconds.
Turn any OpenAPI/Swagger spec into MCP tools. Zero config, zero code.
Claude sees MCP tools like find_pets_by_status, get_pet_by_id, add_pet and calls them directly.
Why mcp-openapi?
Most MCP-to-API bridges require you to write tool definitions by hand or generate code from a spec. mcp-openapi skips all of that.
Feature
mcp-openapi
Hand-written MCP servers
Generic HTTP tools
Zero config setup
Yes
No
Partial
OpenAPI 3.x + Swagger 2.0
Yes
N/A
N/A
Flat parameter schemas (LLM-optimized)
Yes
Manual
No
Smart tool naming from operationId
Yes
Manual
No
Auth (API key, Bearer, OAuth2)
Built-in
DIY
DIY
Retry with exponential backoff
Built-in
DIY
DIY
Response truncation for LLM context
Built-in
DIY
No
Flat parameter schemas are the key differentiator. Instead of passing nested JSON objects (which LLMs frequently get wrong), mcp-openapi flattens path, query, header, and body parameters into a single flat object. This dramatically improves tool-calling accuracy.
CLI arguments take precedence over config file values.
Supported Specs
Format
Versions
File types
OpenAPI
3.0.x, 3.1.x
.json, .yaml, .yml
Swagger
2.0
.json, .yaml, .yml
Specs can be loaded from:
Remote URLs (https://...)
Local file paths (./api.yaml, /absolute/path/spec.json)
v0.3.0 Features
Doc Quality Warnings
On startup, mcp-openapi checks each tool's documentation quality. If endpoints have sparse descriptions (under 50 characters), you'll see a warning:
[mcp-openapi] WARN: Doc quality: 11 of 47 tools have sparse documentation (<50 chars)
[mcp-openapi] WARN: Affected: getUser, createOrder, deleteItem, updateCart, listTags, ...
[mcp-openapi] WARN: LLM accuracy may be reduced for these endpoints.
This helps you identify which API endpoints might cause poor LLM tool-calling accuracy. Suppress with --no-doc-warnings.
Server Filtering
OpenAPI specs can define multiple servers (production, staging, dev). Select which one to use:
# Use first server (default behavior)
mcp-openapi --spec api.json --server 0
# Match by URL keyword
mcp-openapi --spec api.json --server prod
# Exact URL
mcp-openapi --spec api.json --server https://api.example.com/v2
If the selector doesn't match, you'll see all available servers listed.
Dynamic Tool Discovery
For large APIs with 100+ endpoints, registering all tools at once can overwhelm the LLM's context. Dynamic discovery solves this by registering 3 meta-tools instead:
Meta-tool
Description
search_operations(query)
Search tools by keyword in names, descriptions, and tags
list_by_tag(tag?)
Browse tools by OpenAPI tag, or list all tags
get_tool_details(tool_name)
Get full parameter schema for a specific tool
The LLM explores the API through these meta-tools, then calls specific endpoints by name.
# Explicit opt-in
mcp-openapi --spec large-api.json --dynamic-discovery
# Auto-enabled when spec has 100+ endpoints
mcp-openapi --spec https://api.github.com/openapi.json