The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Openapi listing page.
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 Model Context Protocol (MCP) tools automatically. No code generation, no config files, no boilerplate. Your AI assistant gets callable tools for every API endpoint in seconds.
1. Run it (no install required):
2. Add it to Claude Desktop (claude_desktop_config.json):
3. Ask Claude to use it:
"List all available pets in the store"
Claude sees MCP tools like find_pets_by_status, get_pet_by_id, add_pet and calls them directly.
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.
Each API endpoint becomes one MCP tool:
operationId (converted to snake_case) or from method + pathAdd any API to Claude Desktop by editing your config file:
Location:
~/Library/Application Support/Claude/claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.json| Option | Short | Default | Description |
|---|---|---|---|
--spec <url|path> | -s | required | OpenAPI spec URL or local file path |
--config <path> | -c | JSON config file path | |
--base-url <url> | from spec | Override the API base URL | |
--prefix <name> | Prefix for all tool names (e.g. github -> github_list_repos) | ||
--include <patterns> | all | Comma-separated operationIds to include | |
--exclude <patterns> | none | Comma-separated operationIds to exclude | |
--timeout <ms> | 30000 | HTTP request timeout in milliseconds | |
--max-retries <n> | 3 | Max retries on 429/5xx responses | |
--header <name:value> | -H | Custom header (repeatable) | |
--transport <type> | stdio | Transport type: stdio or sse | |
--port <n> | 3000 | Port for SSE transport | |
--help | -h | Show help | |
--version | -v | Show version | |
--license-key <key> | Pro license key (or $MCP_OPENAPI_LICENSE_KEY env) | ||
--server <selector> | 0 | Select API server by index, partial URL, or exact URL | |
--no-doc-warnings | Suppress doc quality warnings on startup | ||
--dynamic-discovery | auto (100+) | Enable dynamic tool discovery for large APIs |
Bearer token:
| Option | Description |
|---|---|
--auth-type bearer | Use Bearer token authentication |
--auth-token <token> | The token value (supports $ENV_VAR syntax) |
API key:
| Option | Description |
|---|---|
--auth-type api-key | Use API key authentication |
--auth-name <name> | Header or query parameter name |
--auth-value <value> | The API key value (supports $ENV_VAR syntax) |
--auth-in <header|query> | Where to send the key (default: header) |
OAuth2 client credentials:
| Option | Description |
|---|---|
--auth-type oauth2 | Use OAuth2 client credentials flow |
--auth-client-id <id> | OAuth2 client ID |
--auth-client-secret <secret> | OAuth2 client secret |
--auth-token-url <url> | Token endpoint URL |
--auth-scopes <scopes> | Comma-separated scopes |
Instead of CLI flags, you can use a JSON config file:
CLI arguments take precedence over config file values.
| 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:
https://...)./api.yaml, /absolute/path/spec.json)On startup, mcp-openapi checks each tool's documentation quality. If endpoints have sparse descriptions (under 50 characters), you'll see a warning:
This helps you identify which API endpoints might cause poor LLM tool-calling accuracy. Suppress with --no-doc-warnings.
OpenAPI specs can define multiple servers (production, staging, dev). Select which one to use:
If the selector doesn't match, you'll see all available servers listed.
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.
Or via config file:
mcp-openapi includes optional Pro features for teams and power users, gated by a license key.
Shape API responses with JMESPath expressions before they reach the LLM — reducing token usage and improving accuracy:
Instead of hard-truncating large responses at 50KB, Pro enables intelligent truncation:
"showing 10 of 847 items")Interested in Pro? Star the repo and open an issue to get early access.
You can also use mcp-openapi as a library in your own MCP server:
Contributions are welcome. Here is how to get started:
Before submitting a PR:
pnpm lint and fix any issuesMIT
mcp, model-context-protocol, openapi, swagger, claude, ai, llm, api, tools, rest-api, ai-tools, mcp-server