Mcpify
Focused, production-ready CLI: turn any OpenAPI REST API into an MCP server.
- Transport
- Not stated
- Package
- —
- Registry id
- io.github.furkan708/mcpify
No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.
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 runtime dependencies:
mcpify serve https://your-company.com/openapi.json
# try it right now, nothing installed (uvx pulls from PyPI on demand)
uvx --from mcpify-openapi mcpify list examples/petstore.json --cost
Focused, production-ready, CLI-first: one job (OpenAPI → MCP). Everything else — governance, credentials, token economics, operations — is opt-in and stays out of the way until you need it:
- Safe for agents by default — lazy context budget (
--lazy), secret masking (--redact), blast-radius limits (--read-only, per-token RBAC) - Ready for real deployments — stdio + HTTP/SSE, OAuth2 and split read/write credentials, health probes, audit trail, metrics, multi-API serving, hot reload
- Proven, not promised — 520 tests across twenty-eight suites, a hostile-spec corpus, live-CI checks, zero runtime dependencies
Why you'll like it
From spec to server
- 60 seconds to working — point it at any OpenAPI 3.x spec (file or URL)
- Every operation becomes a first-class MCP tool — input schemas are generated from
parameters+requestBody, internal$refs are resolved - Spec versions diffed from the tool view —
mcpify diff old.yaml new.yamlreports added/removed/changed operations with per-change breaking verdicts and a migration guide;--fail-on-breakingis a CI gate mcpify doctor— tells you if your spec is agent-friendly before you ship: missing operationIds, missing summaries, instruction-like tool text, overlong descriptions;--probedials the API once — with your real credential (--auth-env) when you want auth proven end-to-end, and--fail-on-http-errorfor a strict CI gatemcpify try/mcpify mock/mcpify output-server— call the tools without an agent client, serve a schema-shaped fake API for CI, or bake a serve command into a shareable script
Credentials & policy
- Credentials never touch the spec or the model — pulled from your environment at call time; the spec's own security declarations pick the flags (bearer, basic, header, query)
- OAuth2 client-credentials built in — tokens are fetched, cached, refreshed and re-fetched on a mid-flight 401 (RFC 6749, stdlib only);
--write-oauth2-*gives non-GET calls a second client identity so reads and writes authenticate as different clients - Least-privilege by default —
--write-auth-envsplits the static credential (reads on your read key, writes on a dedicated key),--read-onlyfilters the surface,--deny/--allowhides mutating GETs, per-token RBAC gives each bearer token its own allow/deny scopes --redact password,token— values whose key names a secret are masked with***at every level of every response (error bodies included, case-insensitive); the model never sees them- Audit trail without content exposure — one JSON line per call: tool, API, status, latency, an argument fingerprint (never raw arguments);
--pluginloads your Python module for auth/request/result hooks
Token economics
From the project's README.