🔌 mcpify
🌐 English | Türkçe
Turn any OpenAPI REST API into an MCP server — so Claude Code, Cursor, and every other MCP client can call your API directly. One command. Zero dependencies.
Your company has a REST API. Your AI agent needs to call it. Until now that meant hand-writing a custom MCP server for every API. With mcpify:
mcpify serve https://your-company.com/openapi.json
That's it — every endpoint just became a tool your AI agent can discover, understand, and call.
📖 Deep docs: Usage guide — auth patterns, scoping, Docker, troubleshooting · Architecture · Contributing · Changelog · Security
📰 The launch story: How a live weather API broke this tool — and made it better
✨ Why you'll like it
- ⚡ 60 seconds to working — point it at any OpenAPI 3.x spec (file or URL)
- 🔐 Credentials never touch the spec or the model — pulled from your
environment at call time (
--auth-env), sent asAuthorization: Bearer, a custom header, or a query parameter - 🧰 Every operation becomes a first-class MCP tool — input schemas are
generated from
parameters+requestBody, internal$refs are resolved - 🎚️ Scope it down —
--read-only(GET only),--tag payments,--include /v1/orders,--exclude /admin, plus a policy layer for real-world APIs:--deny REGEXhides mutating GETs,--allow REGEXre-includes read-style POST endpoints. Deny always wins. - 🩺
mcpify doctor— tells you if your spec is agent-friendly before you ship - 🪶 Zero dependencies — one pure-Python file tree; YAML specs need an
optional
pip install 'mcpify[yaml]' - 🎯 Agent-grade surface. Tool annotations derived from HTTP semantics
(clients auto-approve read-only tools), structured output via MCP
outputSchema/structuredContent, remediation-grade errors that teach the next call, dry-run request previews, and a--lazysearch-then-call mode that cut api.weather.gov's listing by 95.5% (38,882 → 1,741 chars) - 🧪 115 tests — unit, hostile-spec corpus, and full MCP protocol end-to-end over stdio against a real local HTTP API, including the live api.weather.gov document (69 tools, 16 enum'd parameters)
🚀 Quick start
# run without installing (uvx — pulls from PyPI on demand)
uvx --from mcpify-openapi mcpify list ./openapi.json --read-only
# or install (installs the `mcpify` command)
pipx install mcpify-openapi
# ...as a container (GHCR, published on every release)
docker run -i ghcr.io/furkan708/mcpify:latest serve ./openapi.json --read-only
# ...or from source
git clone https://github.com/furkan708/mcpify.git
cd mcpify && pip install .
# 1. preview the tools that will be generated
mcpify list examples/petstore.json
# 2. validate the spec is agent-friendly
mcpify doctor examples/petstore.json
# 3. serve it over MCP
mcpify serve examples/petstore.json --base-url https://petstore.example.com/v1
With authentication
# Bearer token read from the environment (never hardcoded)
export PETSTORE_KEY="sk-..."
mcpify serve petstore.json \
--base-url https://petstore.example.com/v1 \
--auth-env PETSTORE_KEY \
--auth-style bearer \
--read-only
| Flag | Meaning |
|---|---|
--auth-env VAR |
environment variable holding the credential |
--auth-style bearer|header|query |
how it is sent |
--auth-name NAME |
header / query name for non-bearer styles (e.g. X-API-Key) |
🤖 Plug it into your agent
Claude Code:
claude mcp add my-api -- mcpify serve openapi.json --read-only
Claude Desktop / Cursor / any MCP client (claude_desktop_config.json):
{
"mcpServers": {
"petstore": {
"command": "mcpify",
"args": ["serve", "~/specs/petstore.json", "--auth-env", "PETSTORE_KEY"]
}
}
}
Now ask your agent: "list the pets, then create one named Milo" — it discovers list_pets and create_pet, fills the arguments, and performs real HTTP calls.
🔍 How operations become tools
| OpenAPI | mcpify |
|---|---|
operationId |
tool name (sanitized; falls back to method_path) |
summary / description |
tool description the agent reads |
parameters (path/query/header) |
individual typed arguments with enums |
requestBody (JSON) |
a body object argument |
$ref pointers |
resolved inline (components → real schemas) |
servers[0].url |
default base URL (override: --base-url) |
The agent only ever sees the tool list and your API's JSON responses — mcpify adds no middleware, caches nothing, and sends credentials nowhere except your API.
🩺 Doctor
$ mcpify doctor my-api.json
openapi: 3.0.3
title: Acme API
paths: 23
tools: 41 operations
servers: https://api.acme.com
warning: 12/41 operations have no operationId (names fall back to method_path)
warning: 30/41 operations have no summary (agents see no description)
📖 CLI reference
mcpify list <spec> [--tag T] [--include P] [--exclude P] [--read-only] [--json]
mcpify serve <spec> [--base-url URL] [--name N] [--auth-env VAR]
[--auth-style bearer|header|query] [--auth-name NAME]
[--timeout S] [--read-only] [--tag T] [--include P] [--exclude P]
mcpify doctor <spec>
Notes & limitations
- JSON specs work out of the box; YAML specs need
pip install 'mcpify[yaml]' - Only local
$refpointers are resolved (bundle external docs first — most tools do anyway) - Request bodies are exposed as a single
bodyobject argument — predictable over clever - Spec versions: OpenAPI 3.x and Swagger 2.x roots are accepted; 3.x is the happy path
🛡️ Hardened against the real world
mcpify is audited on every release against a 10-category checklist of MCP best practices and published production failure modes — not just our own examples:
- Hostile-spec corpus (12/12): circular
$refs, multipart uploads,allOfschemas, server URL variables, relative base URLs, oversized responses — every scenario derived from a documented real-world failure, fixed, and locked in by a regression test. Sources include the arXiv study of REST→MCP generation across 18 real APIs. - Live integration: the real api.weather.gov spec loads in CI — the case that found (and fixed) our last crash-class bug.
- MCP lifecycle enforced: tools are unreachable until the client
completes the
initializehandshake. - Blast-radius controls: read-only mode, deny/allow policy layer,
40k-char response truncation,
--timeout, credentials never logged.
Full checklist with per-item status: docs/AUDIT-CHECKLIST.md
🧪 Tests
pip install pytest pyyaml
pytest -v
The e2e suite boots a real local HTTP API and drives the full MCP protocol over stdio — initialize → tools/list → tools/call — and asserts on the HTTP requests that hit the wire.
🗂️ Project Structure
mcpify/
├── mcpify/
│ ├── spec.py # OpenAPI loading, $ref resolution, operation walking
│ ├── tools.py # operation -> MCP tool, argument -> HTTP request
│ ├── http_client.py # execution (urllib, HTTP errors become tool results)
│ ├── api_server.py # MCP stdio server (JSON-RPC 2.0)
│ └── cli.py # list / serve / doctor
├── examples/petstore.json
└── tests/
🗺️ Roadmap
-
--output-server FILE— generate a standalone, shareable server script - Per-operation rate limiting
- OAuth2 client-credentials flow
📄 License
MIT — see the LICENSE file for details.
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file mcpify_openapi-1.2.0.tar.gz.
File metadata
- Download URL: mcpify_openapi-1.2.0.tar.gz
- Upload date:
- Size: 41.2 kB
- Tags: Source
- Uploaded using Trusted Publishing? Yes
- Uploaded via:
twine/7.0.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
ca849291c52ac1c64ae1d68c0535e75b652f9fbbfd29fc365f9258106df02c97
|
|
| MD5 |
f9e829aa5f974a4db854d820811955c3
|
|
| BLAKE2b-256 |
94ae63c2538f91598fcb6d6d9afb40646be945d5613f4938bbe149e2551dc8cd
|
Provenance
The following attestation bundles were made for mcpify_openapi-1.2.0.tar.gz:
Publisher:
release.yml on furkan708/mcpify
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
mcpify_openapi-1.2.0.tar.gz -
Subject digest:
ca849291c52ac1c64ae1d68c0535e75b652f9fbbfd29fc365f9258106df02c97 - Sigstore transparency entry: 2634130478
- Sigstore integration time:
-
Permalink:
furkan708/mcpify@2fa5ab36b9e6fc600b351d1188c5c251cf0d597e -
Branch / Tag:
refs/tags/v1.2.0 - Owner: https://github.com/furkan708
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
release.yml@2fa5ab36b9e6fc600b351d1188c5c251cf0d597e -
Trigger Event:
push
-
Statement type:
File details
Details for the file mcpify_openapi-1.2.0-py3-none-any.whl.
File metadata
- Download URL: mcpify_openapi-1.2.0-py3-none-any.whl
- Upload date:
- Size: 26.6 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? Yes
- Uploaded via:
twine/7.0.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
14981ee3f7f9eb295ec94340bbd00cfd167271a277da9d3fd587db8aac732329
|
|
| MD5 |
0c89fb739acd84b45841e629ac76ad5f
|
|
| BLAKE2b-256 |
ce09f34a3ea2116c3441c62e55844f395abca79e15f00758e467bf0aeb4a6a28
|
Provenance
The following attestation bundles were made for mcpify_openapi-1.2.0-py3-none-any.whl:
Publisher:
release.yml on furkan708/mcpify
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
mcpify_openapi-1.2.0-py3-none-any.whl -
Subject digest:
14981ee3f7f9eb295ec94340bbd00cfd167271a277da9d3fd587db8aac732329 - Sigstore transparency entry: 2634130555
- Sigstore integration time:
-
Permalink:
furkan708/mcpify@2fa5ab36b9e6fc600b351d1188c5c251cf0d597e -
Branch / Tag:
refs/tags/v1.2.0 - Owner: https://github.com/furkan708
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
release.yml@2fa5ab36b9e6fc600b351d1188c5c251cf0d597e -
Trigger Event:
push
-
Statement type: