Lo que hace falta de verdad para exponer una API REST como servidor MCP en Ruby: el SDK, una herramienta que funciona y la parte que decide si un agente la usa bien.
Un servidor que funciona es donde acaba el esfuerzo y empieza la venta. Apunta MCP Showcase hacia él y obtén un playground en vivo que tus clientes pueden probar, con documentación generada para cada herramienta.
Se muestra arriba, junto con si está mantenido oficialmente o es un proyecto de la comunidad, algo que importa más en unos lenguajes que en otros.
Empieza con una sola herramienta, no con toda tu API. Las definiciones de herramientas se envían al modelo en cada petición, y el acierto al elegir baja según crece la lista.
Pasa la URL desplegada por el MCP Inspector para confirmar que el handshake se completa y que las herramientas aparecen como querías.
gem install mcp — community SDKs,
un proyecto de la comunidad: no hay SDK bajo
modelcontextprotocol para Ruby.
Eso importa más de lo que parece. El protocolo se ha movido rápido, sobre todo en transportes, y un port que dejó de seguir revisiones de la especificación funcionará con unos clientes y fallará en silencio con otros. Comprueba la última revisión que siguió la biblioteca antes de construir sobre ella.
Ruby no tiene un SDK mantenido bajo modelcontextprotocol, así que las opciones son gemas de la comunidad de completitud y actualidad variables. Comprueba cuándo siguió la gema una revisión de la especificación por última vez antes de comprometerte: el protocolo ha avanzado más rápido que la mayoría de ports comunitarios, sobre todo en transportes.
Un servidor MCP es una capa fina sobre código que ya tienes. Cada herramienta necesita tres cosas: un nombre, una descripción que diga qué hace y cuándo elegirla, y un esquema de entrada. El SDK de Ruby se encarga del protocolo; lo que escribes tú es la correspondencia entre esos argumentos y tu llamada HTTP existente.
Empieza por un endpoint y no por toda tu API. Las definiciones de herramientas se reenvían al modelo en cada petición, así que cada una es un coste de contexto permanente, y el acierto del modelo al elegir baja según crece la lista. Ocho herramientas bien descritas ganan a ochenta.
Sea cual sea el lenguaje, las descripciones deciden si el agente se comporta. Las lee el modelo, no tus compañeros, y una herramienta descrita en tres palabras se llama a ciegas. Puedes revisar las tuyas con el linter de esquemas MCP y ver qué cuesta la lista por petición con la calculadora de tokens.
Una vez que arranca, queda el problema de que nadie puede saber qué hace. Un cliente potencial no puede leer tu código Ruby y no instalará un cliente para averiguarlo. MCP Showcase apunta a la misma URL y produce un playground en vivo con documentación generada para cada herramienta, de modo que evaluar tu servidor cueste un clic.