Herramienta gratuita

De OpenAPI a servidor MCP en C#

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

SDK oficial modelcontextprotocol/csharp-sdk
Instalación
dotnet add package ModelContextProtocol
Una herramienta MCP que funciona en C#
[McpServerToolType]
public static class OrderTools
{
    [McpServerTool, Description("Look up one order by its id and return its current status.")]
    public static async Task<string> GetOrder(
        IOrderService orders,
        [Description("The order id to look up")] string orderId)
        => await orders.FetchAsync(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 C#

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

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 C#: implementar esas herramientas contra tu API con modelcontextprotocol/csharp-sdk (dotnet add package ModelContextProtocol), con la forma que se muestra arriba.

Atributos más inyección de dependencias

Las herramientas se marcan con atributos y se resuelven mediante el contenedor de inyección estándar de .NET, así que una herramienta puede recibir servicios inyectados como parámetros junto a los argumentos que aporta el modelo. Es cómodo y es también la forma más fácil de exponer sin querer un servicio interno a través de la firma de una herramienta: revisa qué es realmente alcanzable desde cada una.

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 C# 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