Herramienta gratuita

De OpenAPI a servidor MCP en Python

Ya tienes una especificación OpenAPI. Así se convierte en un servidor MCP que funciona en Python, y estas son las partes que un conversor no puede hacer por ti.

SDK oficial modelcontextprotocol/python-sdk (FastMCP)
Instalación
pip install mcp
Una herramienta MCP que funciona en Python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def get_order(order_id: str) -> str:
    """Look up one order by its id and return its current status."""
    return fetch_order(order_id)

mcp.run(transport="streamable-http")

Generado, en marcha y todavía invisible.

Convertir una especificación te da un servidor. No te da a nadie que quiera usarlo. MCP Showcase convierte el mismo endpoint en un playground en vivo con documentación legible para cada herramienta.

Cómo funciona

link
Convierte la especificación

El conversor de OpenAPI convierte cada operación en una definición de herramienta MCP, en tu navegador y sin subir tu especificación.

play_circle
Cablealo en Python

Toma las definiciones de herramientas generadas e impleméntalas contra tu API con el SDK de Python, con la forma que se muestra arriba.

checklist
Recorta la lista

Una especificación convertida te da una herramienta por operación, y eso casi siempre son demasiadas. Quédate con las que un agente necesita.

De la especificación a Python

La mitad mecánica lo es de verdad: cada operación OpenAPI pasa a ser una herramienta MCP, su summary pasa a ser la descripción y sus parámetros de ruta, consulta y cuerpo se aplanan en un único esquema de entrada. El conversor de OpenAPI hace esa parte en tu navegador, sin subir tu especificación.

Lo que queda tiene forma de Python: implementar esas herramientas contra tu API con modelcontextprotocol/python-sdk (FastMCP) (pip install mcp), con la forma que se muestra arriba.

Los decoradores ocultan el esquema, que suele ser lo que quieres

FastMCP deriva el esquema de entrada de una herramienta de tus anotaciones de tipo y su descripción del docstring. Es el camino más rápido a un servidor que funciona y la razón de que la mayoría de ejemplos MCP sean en Python, pero también significa que lo que lee el modelo es tu docstring. Un docstring vago es una herramienta que el agente elige mal, y nada en tus pruebas lo detectará.

Lo que ningún conversor puede hacer por ti

  • La autenticación. El código generado llama a tu API sin credenciales. Cablear la cabecera, el token o el flujo OAuth es cosa tuya.
  • Reescribir las descripciones. Una summary de OpenAPI está escrita para una persona que lee documentación. Una descripción de herramienta MCP la lee un modelo que decide qué llamar. Son trabajos distintos, y las summaries suelen necesitar reescritura una vez convertidas.
  • Elegir qué exponer. Un conversor te dará una herramienta por operación. Para la mayoría de APIs eso es un orden de magnitud de más.
  • Resolver cuerpos con $ref. Resolverlos necesita tu sección components, así que llegan como objeto genérico.

Por qué importa tanto el número de herramientas

Las definiciones de herramientas se envían al modelo en cada petición, no una vez por sesión. Ochenta operaciones son ochenta descripciones y ochenta esquemas en la ventana de contexto de cada turno, pagados de forma continua y medibles peor al elegir que una lista corta. La calculadora de tokens muestra lo que cuesta una lista dada; el linter de esquemas muestra si las descripciones sobrevivieron a la conversión en un estado utilizable.

Herramientas y guías relacionadas

Generado no es lo mismo que utilizable

Un servidor convertido demuestra que la correspondencia funcionó. A un cliente potencial no le dice nada: no sabe leer Python y no configurará un cliente para averiguarlo. MCP Showcase convierte el mismo endpoint en un playground en vivo con documentación por herramienta que cualquiera puede probar en un navegador.

Preguntas frecuentes

La correspondencia es mecánica: cada operación pasa a ser una herramienta, su summary pasa a ser la descripción y sus parámetros se aplanan en un único esquema de entrada. Lo que no es mecánico: la autenticación, el manejo de errores y decidir qué operaciones merecen estar en la lista de herramientas.

La autenticación, que añades tú. Los cuerpos de petición tras un $ref, cuya resolución necesita tu sección components. Y el criterio: un conversor te dará encantado ochenta herramientas, que es peor que ocho.

Porque las definiciones de herramientas se envían al modelo en cada petición. Ochenta operaciones son ochenta descripciones y ochenta esquemas en el contexto de cada turno, pagados de forma continua, y a la vez hacen al modelo medible peor eligiendo entre ellas.

Sí, y conviene saberlo antes de convertir. Una summary de OpenAPI está escrita para una persona que lee documentación; una descripción de herramienta MCP la lee un modelo que decide qué llamar. Son dos trabajos distintos, y las summaries suelen necesitar reescritura después.

Despliégalo y pasa la URL por el MCP Inspector para confirmar el handshake y la lista de herramientas, y luego por el linter de esquemas para ver si las descripciones han sobrevivido lo bastante bien como para que un modelo elija correctamente.

Más herramientas MCP gratuitas