API y MCP: De una fresa madura a la bandeja

La API ofrece las operaciones del sistema; MCP permite presentarlas como herramientas que una aplicación de IA puede descubrir y utilizar. Por ejemplo, el backend ya sabe consultar robots y bandejas. El servidor MCP publica listar_robots_libres y consultar_bandejas. Ante «¿podemos recoger la parcela 7?», el modelo puede proponer consultar esas herramientas y preparar una respuesta con los resultados. Hay que implementar las herramientas y sus permisos: MCP aporta una forma común de conectarlas, no crea por sí solo la lógica de la cosecha.

Si cambia una URL, podemos adaptar el servidor MCP conservando el contrato de la herramienta. Ejemplo: la consulta pasa de GET /robots/libres a GET /flota?estado=disponible. Si listar_robots_libres sigue aceptando la misma parcela y devuelve los mismos datos, el host puede seguir utilizándola sin conocer esa nueva URL. Para añadir otra finca, la herramienta podría aceptar campo_id y el backend comprobar los permisos de ese campo. Si cambian los parámetros, las respuestas o lo que significa «disponible», también hay que revisar el contrato y probar las aplicaciones que lo usan. MCP concentra parte del mantenimiento en el adaptador; no evita todos los cambios.

Un mismo servidor MCP puede servir a distintas aplicaciones compatibles. Por ejemplo, el encargado consulta las bandejas desde un asistente y el equipo técnico revisa tareas fallidas desde otro, reutilizando consultar_bandejas y consultar_tareas. Cada conexión necesita su configuración y sus permisos. Cambiar de modelo dentro de una aplicación depende de ese host, y puede cambiar cómo se eligen las herramientas. Conviene probar una petición concreta, como «resume las tareas pendientes de la finca Norte», y comprobar que el nuevo modelo interpreta bien los campos y los resultados.

Para el recorrido fijo cámara → backend → IA de visión → robot, una API directa encaja bien: llega una foto con su parcela, se analiza y se procesa la tarea siguiendo reglas definidas. MCP aporta más cuando una aplicación de IA necesita elegir entre varias consultas o acciones. Por ejemplo, ante «¿por qué hay menos bandejas listas hoy?», podría consultar el recuento de bandejas y los robots detenidos para explicar los datos disponibles. Si solo necesitamos enviar siempre la misma foto al mismo servicio, añadir MCP puede no compensar. También puede utilizarlo un agente automático: no requiere que siempre haya una persona escribiendo en un chat.

Consultar y actuar requieren permisos distintos. Por ejemplo, consultar_estado_robot puede devolver que R-03 está libre; asignar_tarea debe pasar por el backend, que comprueba batería, parcela, disponibilidad y duplicidades. La aplicación puede pedir confirmación antes de autorizar la tarea, y el sistema debe registrar el resultado. Tras una actualización, probamos casos concretos: robot disponible, batería insuficiente, parcela sin permiso y una tarea repetida que no debe ejecutarse dos veces. MCP Inspector ayuda a probar las herramientas; después se comprueba también la petición completa desde el asistente. Si se permite consultar la base de datos para informes, se limita el acceso a las vistas y permisos necesarios. MCP no aplica todos estos controles por sí solo.