Herramienta gratuita

De OpenAPI a servidor MCP en TypeScript

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

SDK oficial modelcontextprotocol/typescript-sdk
Instalación
npm install @modelcontextprotocol/sdk zod
Una herramienta MCP que funciona en TypeScript
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "my-server", version: "1.0.0" });

server.tool(
  "get_order",
  "Look up one order by its id and return its current status.",
  { orderId: z.string().describe("The order id to look up") },
  async ({ orderId }) => ({ content: [{ type: "text", text: await fetchOrder(orderId) }] })
);

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 TypeScript

Toma las definiciones de herramientas generadas e impleméntalas contra tu API con el SDK de TypeScript, 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 TypeScript

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 TypeScript: implementar esas herramientas contra tu API con modelcontextprotocol/typescript-sdk (npm install @modelcontextprotocol/sdk zod), con la forma que se muestra arriba.

Tu esquema Zod es el contrato que ve el modelo

El SDK de TypeScript construye el JSON Schema a partir de Zod, así que `.describe()` en cada campo no es documentación para tus compañeros: es lo que le dice al modelo qué poner ahí. Los esquemas escritos sin eso validan perfectamente y dejan al agente adivinando en cada parámetro.

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 TypeScript 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