De API REST a Servidor MCP en 10 Minutos

Si tienes una API REST, tienes el 90% de un servidor MCP. Esto es lo que nadie te dice.

Tus endpoints son tus herramientas. Tus esquemas de peticion son tus esquemas de entrada. Tus formatos de respuesta son tus tipos de salida. El mapeo es casi vergonzosamente directo.

POST /users/create? Eso es una herramienta create_user. GET /orders/:id? Eso es get_order. Los tipos de parametros, las reglas de validacion, las formas de error — ya escribiste todo. Probablemente dos veces, si cuentas la especificacion OpenAPI.

Lo unico que falta es la capa de traduccion. Y — esta es la parte que te va a complicar — buenas descripciones. No "description: crea un usuario." Descripciones con las que un LLM pueda razonar. Esa distincion importa mas de lo que crees.

Las herramientas MCP se mapean casi 1:1 con los endpoints REST. Esto no es casualidad. Ambos responden fundamentalmente a la misma pregunta: que puede hacer este servicio, y como le pido que lo haga?

Las traducciones de esquemas son mecanicas. JSON Schema entra, JSON Schema sale. Los campos requeridos siguen siendo requeridos. Los enums siguen siendo enums. Los objetos anidados siguen anidados. Si entrecierras los ojos, una definicion de herramienta MCP parece una operacion OpenAPI con mejor ergonomia.

Podrias automatizar la conversion. Nosotros la automatizamos. El mapeo estructural es un problema resuelto. No necesitas pensar en ello.

En lo que si necesitas pensar es en todo lo que la estructura no captura. Los contratos implicitos. Las dependencias de orden. El conocimiento de "no llames a este endpoint antes de llamar a aquel" que vive en las cabezas de tu equipo y en ningun otro lugar. Ese es el verdadero trabajo de traduccion.

Aqui es donde fallan la mayoria de las migraciones. Y no es donde esperarias.

Copias los nombres de los endpoints, generas esquemas desde tu spec OpenAPI, y lo despliegas. Todo se ve genial. Las definiciones de herramientas estan limpias. Los tipos son correctos. Te sientes productivo.

Entonces el LLM llama a create_user cuando deberia llamar a update_user. Por que? Porque ambas descripciones dicen "gestiona datos de usuario." Las escribiste para un desarrollador que leeria la ruta URL y entenderia la diferencia. Un LLM no lee rutas URL. Lee descripciones.

Tus descripciones necesitan ser inequivocas, especificas, y escritas para un lector que nunca ha visto tu sistema y nunca lo hara. "Crea una nueva cuenta de usuario con el email y contrasena proporcionados. Devuelve el objeto de usuario creado con un ID generado. Falla si el email ya esta registrado." Esa es una descripcion con la que un LLM puede trabajar.

Este es el verdadero trabajo duro de la migracion. No la fontaneria — el nombrado.

Aqui esta el atajo. Apunta SmeltSec a tu spec OpenAPI o repositorio de GitHub. Eso es todo. Ese es el punto de partida.

Lee tus endpoints, infiere la intencion desde la estructura de tus rutas y documentacion existente, genera herramientas MCP con esquemas correctos, y escribe descripciones que los LLMs pueden realmente interpretar. Luego ejecuta analisis de seguridad para detectar vectores de envenenamiento de herramientas y esquemas de entrada excesivamente permisivos.

Los 10 minutos del titulo son generosos. La mayoria de los repositorios toman menos de 60 segundos. El cuello de botella no es la generacion — eres tu revisando la salida y decidiendo si las descripciones capturan con precision lo que hace cada herramienta.

Podrias hacer todo esto a mano. Pasarias un fin de semana en ello. Acertarias con los esquemas y fallarias con las descripciones, porque escribir buenas descripciones es una habilidad que la mayoria de los ingenieros backend nunca han necesitado desarrollar. Este es el tipo de trabajo aburrido y critico que las herramientas deberian manejar.

Lo sorprendente de convertir a MCP no es la conversion. Es lo que pasa despues.

Tu API de repente tiene nuevos consumidores que no esperabas. Los agentes de IA empiezan a llamar a tus herramientas de maneras que nunca probaste. Componen tus herramientas con otras de servicios completamente no relacionados — una herramienta de calendario llama a tu herramienta de pagos que llama a una herramienta de notificaciones, todo orquestado por un LLM que descubrio el flujo de trabajo por su cuenta.

Ya no estas construyendo una API. Estas contribuyendo a un ecosistema. Tus herramientas se convierten en bloques de construccion en sistemas que no disenaste y no puedes predecir.

Esto es incomodo si estas acostumbrado a controlar toda la superficie de integracion. Es emocionante si te das cuenta de lo que significa: tu servicio acaba de volverse util de maneras que no podrias haber imaginado, para usuarios que nunca conoceras, resolviendo problemas que no sabias que existian.

Esa es la verdadera razon para hacer el cambio. No porque MCP sea mas nuevo o este mas de moda. Porque hace que tu trabajo importe en un mundo mucho mas grande.