Tool routing e intent lock en servidores MCP

El Model Context Protocol (MCP) permite que un modelo de lenguaje invoque herramientas en sistemas externos mediante una interfaz estandarizada. En la práctica, no es el protocolo en sí el factor determinante, 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 evaluar un servidor MCP multidominio (multi-domain), suele surgir un problema habitual: mientras el usuario realiza una búsqueda en un dominio determinado, el modelo invoca una herramienta correspondiente a otro debido a la similitud en nombres o parámetros. A este fenómeno se lo conoce como intent drift. Por ejemplo, la solicitud de un usuario que busca pasajes de micro de larga distancia puede derivar en una herramienta de asignación de vehículos corporativos por compartir parámetros semejantes. Esto no se debe tanto a un fallo del modelo, sino a la ambigüedad en el diseño de la interfaz.

¿Qué es el intent lock? Consiste en registrar el dominio activo de la sesión del lado del servidor y verificar dicha coincidencia en cada invocación de herramienta. Si el usuario se encuentra en el dominio de micros y se produce una llamada a una herramienta de alquiler de autos, esta se rechaza y se le devuelve al modelo un error explícito: el dominio no coincide, invocá primero la herramienta de cambio de dominio. De esta manera, el cambio de intención deja de ser implícito y pasa a ser un paso explícito.

La segunda línea de defensa es el esquema. Incorporar un campo obligatorio de dominio en cada objeto de solicitud y respuesta obliga al modelo a declarar en qué contexto opera en cada invocación. Si la declaración se contradice con el estado de la sesión, el servidor frena la operación. Esto traslada la validación al servidor en lugar de delegarla en una regla del lado del cliente.

El tercer aspecto clave es la disciplina en la nomenclatura. Utilizar nombres con prefijos de dominio como bus_search, flight_search o car_rental_search, en lugar de términos genéricos como buscar o consultar, amplía la distancia conceptual entre herramientas similares. Las descripciones deben mantener la misma precisión; explicitar qué no hace una herramienta resulta tan valioso como detallar qué hace.

Los campos de fecha y hora constituyen otra fuente frecuente de errores. Una herramienta que acepta fechas en texto libre propicia que el modelo genere formatos regionalizados. Exigir ISO-8601 y requerir explícitamente el huso horario simplifica tanto la validación como los mensajes de error. Del mismo modo, especificar unidades en campos numéricos (cantidad de personas, número de noches, moneda) mitiga la ambigüedad.

En materia de seguridad, los flujos de validación basados en OTP o métodos equivalentes son el enfoque adecuado para herramientas transaccionales. Sin embargo, la validación debe ser vinculante a nivel de transacción y no limitarse al nivel de herramienta: no deben aceptarse llamadas de reserva, pago o cancelación sin un identificador de sesión autenticado. Otorgar autorizaciones confiando únicamente en el texto generado por el modelo constituye una vulnerabilidad crítica, al margen del protocolo.

Los mensajes de error representan la superficie de aprendizaje del modelo. En lugar de una respuesta genérica 400, devolver errores estructurados que especifiquen qué campo falta y cuál es el formato esperado incrementa notablemente la probabilidad de que el modelo genere la llamada correcta en el siguiente intento. Asimismo, las políticas de límites de tasa y reintentos deben documentarse con claridad; el modelo solo puede comprender la necesidad de esperar si se lo comunica el propio mensaje de error.

Lista de verificación para un tool routing seguro: nomenclatura de herramientas basada en dominios, intent lock a nivel de sesión, campo de dominio obligatorio en el esquema, validación del lado del servidor, herramienta explícita para cambio 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 aspectos radica en hacer inviable el comportamiento erróneo desde el servidor, en vez de limitarse a confiar en que el modelo actúe correctamente. Al diseñar un servidor MCP, la pregunta que tenés que hacerte es: ¿cuál es la llamada incorrecta más verosímil que el modelo podría generar y en qué capa la detiene el sistema?