Importancia del tool routing y el intent lock en servidores MCP

El Model Context Protocol (MCP) permite que un modelo de lenguaje invoque herramientas en sistemas externos a través de una interfaz estándar. En la práctica, lo determinante no es el protocolo en sí, sino el diseño de las herramientas del lado del servidor: los nombres de las herramientas, los esquemas de parámetros y los mensajes de error moldean directamente el comportamiento del modelo.

Al probar un servidor MCP multidominio (multi-domain), se encuentra un problema típico: mientras un usuario busca en un dominio, el modelo invoca una herramienta de otro dominio debido a la similitud de nombres o parámetros. A esto se le llama intent drift. Por ejemplo, la solicitud de un usuario que busca un autobús interurbano podría ser dirigida a una herramienta que asigna vehículos, ya que el conjunto de parámetros es similar. Esto se debe más a la ambigüedad del diseño de la interfaz que a un error del modelo.

¿Qué es el intent lock? Es la retención del dominio activo de la sesión en el lado del servidor y la verificación de que cada llamada a una herramienta coincida con este dominio. Si un usuario está en el dominio de autobuses, una llamada a la herramienta de alquiler de coches es rechazada y se devuelve un error explícito al modelo: el dominio no coincide, invoca primero la herramienta para cambiar de dominio. Así, el cambio de intención no es un paso implícito, sino explícito.

La segunda línea de defensa es el esquema. Agregar un campo de dominio (domain) obligatorio a cada objeto de solicitud y respuesta asegura que el modelo declare en qué contexto está operando en cada llamada. Cuando la declaración contradice el estado de la sesión, el servidor detiene la operación. Esto traslada la validación al servidor en lugar de depender de una regla del lado del cliente.

El tercer punto es la disciplina en la nomenclatura. En lugar de nombres genéricos como realizar_busqueda, buscar o consultar, usar nombres con prefijos de dominio como bus_search, flight_search y car_rental_search aumenta la distancia entre herramientas similares. Los textos de descripción también deben tener la misma claridad; escribir lo que una herramienta no hace es tan valioso como escribir lo que hace.

Los campos de fecha y hora son una fuente de error aparte. Una herramienta que acepta fechas en texto libre lleva al modelo a producir formatos localizados. Hacer obligatorio el formato ISO-8601 y solicitar explícitamente la zona horaria simplifica tanto la validación como los mensajes de error. Del mismo modo, en los campos numéricos, la declaración de la unidad (número de personas, número de noches, divisa) reduce la ambigüedad.

En el lado de la seguridad, los flujos de validación como OTP o similares son un enfoque correcto para las herramientas que inician transacciones. Sin embargo, la validación debe ser vinculante a nivel de transacción, no a nivel de herramienta: las llamadas de reserva, pago o cancelación no deben aceptarse sin una ID de sesión verificada. Conceder autorización basándose en el texto generado por el modelo es una vulnerabilidad de seguridad independiente del protocolo.

Los mensajes de error son la superficie de aprendizaje del modelo. En lugar de una respuesta genérica 400, devolver errores estructurados que indiquen qué campo falta y el formato esperado aumenta significativamente la probabilidad de que el modelo genere la llamada correcta en el siguiente intento. Del mismo modo, los límites de velocidad y las políticas de reintento deben estar documentados; el modelo solo puede entender que necesita esperar a partir del texto del error.

Una breve lista de verificación para un tool routing seguro: nomenclatura de herramientas basada en el dominio, intent lock a nivel de sesión, información de dominio obligatoria en el esquema, validación del lado del servidor, una herramienta explícita para cambiar de dominio, formato de fecha ISO-8601, control de autorización a nivel de transacción, mensajes de error estructurados y documentación de límites y reintentos.

El punto en común de estos elementos es hacer imposible el comportamiento incorrecto en el lado del servidor, en lugar de esperar que el modelo se comporte correctamente. Al diseñar un servidor MCP, la pregunta a hacerse es: ¿cuál es la llamada incorrecta más plausible que el modelo podría generar y en qué capa la detiene el sistema?