Herramienta gratuita

De OpenAPI a servidor MCP en Java

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

SDK oficial modelcontextprotocol/java-sdk
Instalación
Maven: io.modelcontextprotocol.sdk:mcp
Una herramienta MCP que funciona en Java
McpServerFeatures.SyncToolSpecification getOrder =
    new McpServerFeatures.SyncToolSpecification(
        new McpSchema.Tool( "get_order",
            "Look up one order by its id and return its current status.",
            ORDER_INPUT_SCHEMA ),
        ( exchange, args ) -> new McpSchema.CallToolResult(
            List.of( new McpSchema.TextContent( fetchOrder( (String)args.get( "orderId" ) ) ) ),
            false ) );

McpSyncServer server = McpServer.sync( transportProvider )
        .serverInfo( "my-server", "1.0.0" )
        .tools( getOrder )
        .build();

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 Java

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

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 Java: implementar esas herramientas contra tu API con modelcontextprotocol/java-sdk (Maven: io.modelcontextprotocol.sdk:mcp), con la forma que se muestra arriba.

Los clientes sync y async son tipos distintos

El SDK de Java expone McpSyncServer y McpAsyncServer como tipos distintos en lugar de una API con un indicador de modo, y el transporte se elige al construir. Si eliges el equivocado, reescribes el cableado, no cambias un ajuste. Spring AI lo envuelve si ya estás en ese ecosistema.

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