# mcpify [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/furkan708/mcpify  
**GitHub Stars:** 2  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/mcpify

## Description
Turn any OpenAPI REST API into an MCP server so AI agents can call it — zero dependencies

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "mcpify": {
    "command": "uvx",
    "args": ["--from","mcpify-openapi","mcpify"]
  }
}
```

## Documentation

## What mcpify does

The mcpify MCP server turns an OpenAPI 3.x document into an MCP tool surface. Each operation in the specification becomes a callable tool, with input schemas derived from its parameters and request body. Internal `$ref` references are resolved while the tool definitions are built.

The source specification can be a local file or a URL. A single configuration can expose several APIs through one MCP server, with collision-safe tool renaming and separate settings for authentication, caching, retries, filters, and rate limits. YAML specifications require the optional YAML extra; the core runtime uses Python’s standard library.

The CLI also supports inspecting and validating the generated surface before serving it. `list` shows available operations and can estimate their context cost. `doctor` checks for issues such as missing operation IDs or summaries and can probe the upstream API. `diff` compares two specifications, identifies changed operations, and can fail when breaking changes are found.

## How the mcpify MCP server works

At startup, mcpify reads the OpenAPI document and exposes the resulting operations through MCP. Calls are sent to the corresponding REST endpoints using the URL and authentication settings supplied at runtime. Credentials are read from environment variables rather than stored in the specification or passed into model-visible tool definitions.

Local clients can use stdio. For shared access, `serve --http PORT` provides MCP Streamable HTTP, returning SSE when requested by a client and JSON otherwise. HTTP access can be protected with bearer tokens. Multiple upstream APIs can be served together, and `status` checks their health in parallel.

The server can reduce context and response size with lazy tool loading, field projection, and structurally valid truncation. It can cache using ETags, retry idempotent requests for selected gateway errors, honor `Retry-After` for rate limiting, and apply per-upstream request limits. Audit records contain the tool, API, status, latency, and an argument fingerprint rather than raw arguments.

## Setup and configuration

Install the `mcpify-openapi` package with `pipx`, run it on demand with `uvx`, install from source, or use the published container image. The basic command is:

```bash
mcpify serve https://example.com/openapi.json
```

`mcpify init` can create a configuration file. The `--base-url` option overrides the API location. Authentication supports bearer, basic, header, and query styles, with the common style selected from the specification. OAuth2 client credentials are also supported; access tokens are fetched, cached, refreshed, and retried once after a mid-request 401 response.

Read and write access can use separate credentials. `--read-only` removes mutating operations, while allow and deny filters and per-token RBAC provide additional surface controls. The `--redact` option masks values whose keys identify secrets, including values in error responses.

## Tools and capabilities

- Generate MCP tools from OpenAPI operations.
- Preview tools and estimate their context cost with `list --cost`.
- Test calls from a terminal with `try`.
- Serve a schema-shaped mock API for CI with `mock`.
- Create a shareable serving script with `output-server`.
- Expose metrics, OpenTelemetry spans, health probes, and a local dashboard when enabled.
- Hot-reload configuration with `--reload`.

## Limitations and notes

The input must be an OpenAPI 3.x specification. Runtime dependencies are not required for the standard installation, but YAML support needs the optional `mcpify[yaml]` package. Authentication credentials must be supplied through the environment or related runtime configuration; they are not taken from the model or embedded in the specification. HTTP sharing, OAuth2, redaction, observability, and other operational controls are optional rather than required for a basic stdio deployment.

_Full upstream README: https://allmcps.com/mcp/mcpify/readme_