mcpify
Convierte cualquier especificación OpenAPI 3.x en un servidor MCP funcional con un solo comando.
Documentación
mcpify
Convierte cualquier especificación OpenAPI 3.x o Swagger 2.0 en un servidor MCP funcional con un solo comando.
Apúntalo a una especificación (un archivo o una URL) y cada operación de la API se convierte en una herramienta MCP. No hay código que generar ni nada que conectar: mcpify lee la especificación, expone una herramienta por operación y envía cada llamada de herramienta a la API real.

mcpify ls openapi.yaml # preview the tools a spec exposes
mcpify openapi.yaml # serve it as an MCP server
Instalación
Homebrew:
brew install aloki-alok/tap/mcpify
O el script de instalación:
curl -fsSL https://raw.githubusercontent.com/aloki-alok/mcpify/main/install.sh | sh
O con Go (1.26+):
go install github.com/aloki-alok/mcpify@latest
O descarga un binario precompilado desde la página de versiones, o compila desde el código fuente:
git clone https://github.com/aloki-alok/mcpify
cd mcpify
go build -o mcpify .
Uso
Previsualiza en qué se convierte una especificación, sin iniciar nada:
mcpify ls https://petstore3.swagger.io/api/v3/openapi.json
Sirve una especificación:
mcpify ./petstore.yaml
En una terminal esto abre un menú corto: ejecuta un servidor local y obtén una URL de conexión (la opción predeterminada, solo presiona Enter), imprime una configuración de cliente para pegar, o lista las herramientas. Cuando un cliente MCP inicia mcpify a través de una tubería, sirve stdio directamente, por lo que el mismo comando funciona dentro de una configuración de cliente. Pasa --stdio para forzar el servicio stdio también en una terminal.
Sirve a través de HTTP en una dirección fija:
mcpify --http :8080 ./petstore.yaml
El endpoint MCP es http://localhost:8080/mcp. La URL raíz sirve una página de texto plano corta que describe el servidor, para cualquiera que la abra en un navegador.
Reenvía la autenticación y anula la URL base del upstream:
mcpify --base https://api.example.com -H "Authorization: Bearer $TOKEN" spec.json
Con -H, el secreto resuelto termina en la línea de comandos, donde los listados de procesos, el historial del shell y las configuraciones de cliente impresas pueden verlo. --header-env lo mantiene fuera de los tres: mcpify lee el valor de la variable de entorno nombrada al inicio, y las configuraciones llevan la referencia en lugar del secreto:
export API_TOKEN="Bearer ..."
mcpify --header-env "Authorization=API_TOKEN" spec.json
Expón solo operaciones de lectura (GET y HEAD):
mcpify --read-only spec.yaml
Reduce una especificación grande a las herramientas que realmente quieres. --include mantiene operaciones cuyo nombre de herramienta, operationId o ruta coinciden; sin un * esto es una verificación de subcadena sin distinción de mayúsculas, con uno es un glob path.Match (cadena completa, sensible a mayúsculas, * no cruza un /) contra cada uno de los tres. --tag mantiene operaciones que llevan esa etiqueta OpenAPI (sin distinción de mayúsculas, coincidencia exacta). Ambos son repetibles, y una operación se mantiene si coincide con cualquier --include o cualquier --tag:
mcpify --tag pet --tag store spec.yaml
mcpify --include "*Pet*" spec.yaml
mcpify --include order spec.yaml
Actualiza a la última versión en el lugar:
mcpify upgrade
Conéctate a un cliente MCP
Cualquier cliente que inicie un servidor a través de stdio funciona. Por ejemplo:
{
"mcpServers": {
"petstore": {
"command": "mcpify",
"args": ["--base", "https://api.example.com", "/path/to/openapi.json"]
}
}
}
Cómo se asignan los argumentos
Los parámetros de ruta, consulta, cabecera y cookie de cada operación se convierten en argumentos de herramienta. Un cuerpo de solicitud JSON cuyo esquema es un objeto se aplana para que sus campos también sean argumentos de nivel superior; un parámetro gana si comparte un nombre. Otras formas de cuerpo (un array, un escalar) se toman como un único argumento body. mcpify enruta cada argumento de vuelta al lugar correcto cuando construye la solicitud upstream.
Opciones
| Bandera | Significado |
|---|---|
--base <url> | URL base del upstream, anulando el servers de la especificación |
-H, --header "Name: value" | cabecera enviada en cada solicitud upstream (repetible) |
--header-env "Name=VAR" | como -H, valor leído de la variable de entorno VAR (repetible) |
--http <addr> | sirve a través de HTTP en addr (endpoint MCP en /mcp) |
--stdio | sirve stdio incluso en una terminal, omitiendo el menú |
--read-only | expón solo operaciones GET y HEAD |
--include <pattern> | mantén solo operaciones cuyo nombre de herramienta, operationId o ruta coincidan (repetible) |
--tag <tag> | mantén solo operaciones con esta etiqueta OpenAPI (repetible) |
--timeout <dur> | tiempo de espera de solicitud upstream (predeterminado 30s) |
Alcance
OpenAPI 3.0 y 3.1, en JSON o YAML. Una operación se asigna a una herramienta. Los cuerpos de solicitud son JSON. Las URL de servidor con plantilla se resuelven desde sus valores predeterminados de variable, o anula la base con --base. La autenticación es de paso: las cabeceras que proporciones se reenvían al upstream.
Swagger 2.0
Las especificaciones Swagger 2.0 también funcionan. mcpify las convierte en las mismas herramientas que obtendrías de una especificación 3.x: la URL del servidor proviene de schemes + host + basePath (prefiriendo https), los parámetros de ruta, consulta y cabecera se asignan directamente, el esquema de un parámetro de cuerpo se aplana de la misma manera, y los $ref en definitions se incorporan. Las operaciones que toman formData (cargas de archivos y campos de formulario) se omiten con una nota, ya que mcpify solo envía cuerpos JSON; el resto de la especificación aún se sirve.
Licencia
MIT