Volver al blog
Servidores MCP que se usan en varios pasos: el modo iterativo
Integraciones3 min de lectura

Servidores MCP que se usan en varios pasos: el modo iterativo

El problema

El MCP (Model Context Protocol) es un estándar abierto para conectar servidores de herramientas externos a un asistente: una cuenta de GitHub, una base de datos, una herramienta de dibujo. En LIA, añades los tuyos en los ajustes, y sus herramientas se suman a las de LIA.

Muchas de estas herramientas son sencillas: una búsqueda, una respuesta. Otras se usan en varios pasos. En una base de datos, primero hay que listar las tablas antes de consultar la correcta. Un servidor de dibujo a veces pide que se lea su documentación antes de crear nada. Pero en modo Pipeline, el planificador fija todos los parámetros antes de la primera llamada. Ante estos servidores, no le quedaría más remedio que adivinar.

Lo que quería

El formulario de cada servidor permite elegir cómo se controla: usar sus herramientas directamente, dedicarle un agente solo en Pipeline o mantenerlo en ambos modos. Las herramientas directas sirven para llamadas independientes. Un agente dedicado conviene cuando hay que leer documentación y resultados antes de la siguiente llamada. La síntesis del formulario explica las consecuencias en los dos modos.

Cómo funciona

Preguntas: «¿cuántos pedidos están pendientes en mi base de datos?». El asistente dedicado lee la documentación que ofrece el servidor, lista las tablas, localiza la de los pedidos, la consulta y lee el resultado. Si una llamada falla, por ejemplo porque falta un parámetro, lee el mensaje de error y corrige su llamada. Todo cabe en un número de pasos y un tiempo limitados. Cuando el presupuesto se agota, una última pasada redacta lo que ya ha obtenido. Su resultado vuelve después al plan principal, y LIA te escribe la respuesta.

  • Dos modelos. Los servidores que muestran widgets interactivos usan un modelo más capaz; los demás, un modelo más rápido y más barato. El administrador ajusta ambos en la configuración de los modelos.
  • En modo ReAct, LIA puede usar las herramientas directamente o conservar el agente dedicado. Los servidores con widgets interactivos mantienen su agente.

Las salvaguardas

  • Tus confirmaciones. Las decisiones de cuenta, servidor y herramienta determinan si LIA pregunta. Un agente dedicado recibe aprobación una vez antes de su tarea si alguna herramienta la pediría y después la completa. «Nunca preguntar» es tu aprobación permanente explícita para una herramienta; un cambio de declaración la suspende. Una rutina necesita aprobación previa en su formulario para los servidores que de otro modo se detendrían.
  • Cada herramienta conserva su origen. Tus servidores personales y los del administrador siguen separados. Una herramienta sigue vinculada al servidor y a la cuenta que la ofrecen, y un nombre parecido no permite hacer pasar la herramienta de un servidor por la de otro.
  • Una conexión controlada. A un servidor personal se accede por HTTPS, y LIA comprueba la dirección de destino antes de conectarse. Tus credenciales se cifran antes de guardarse.
  • Un coste visible. Las llamadas del asistente al modelo se suman al coste de tu petición, contadas como el resto.

Cuándo activarlo, y sus límites

Elige herramientas directas para llamadas independientes y un agente dedicado cuando la documentación o un resultado anterior determine la siguiente llamada. Mantenerlo en ReAct es opcional salvo en servidores con widgets. Realiza varias llamadas al modelo, cuesta más y no garantiza el éxito; el administrador puede desactivar los agentes dedicados en la instancia.

Para profundizar: Conectar tus propias herramientas a LIA con MCP; Pipeline o ReAct: dos formas de llevar a cabo tu petición.

#mcp#react-agent#iterative#sub-agent#tool-server#extensibility