Diseño de herramientas MCP: cómo evitar el bloat y la confusión en agentes LLM

Por qué el diseño de herramientas importa

Muchas implementaciones de Model Context Protocol (MCP) parten de una idea sencilla: exponer una API existente tal cual y confiar en que el agente —el LLM— resolverá el resto. Para casos simples eso puede funcionar, pero en implementaciones reales con agentes más complejos y múltiples servidores MCP conectados, aparecen dos problemas recurrentes: bloat (inflación del contexto) y confusión del modelo.

El bloat ocurre porque las definiciones de las herramientas y sus esquemas se cargan en el contexto del modelo en cada llamada, incluso si la herramienta no se usa. Con varios servidores y herramientas, gran parte del contexto disponible se consume antes de que el usuario formule una sola pregunta, lo que degrada la capacidad de razonamiento del LLM y reduce la productividad de la sesión.

La confusión aparece cuando, a medida que el contexto se llena, el modelo empieza a tomar decisiones peores: invoca la herramienta equivocada, elige parámetros incorrectos y desencadena reintentos que empeoran aún más el bloat. La similitud semántica entre herramientas, demasiadas opciones y nombres ambiguos agravan el problema.

Enfoque general: ingeniería de contexto

Resolver bloat y confusión es principalmente un problema de ingeniería de contexto: decidir qué ve el LLM y cuándo lo ve. No hay una solución única; se trata de equilibrar claridad (evitar confusión) con concisión (evitar bloat). A continuación describo enfoques prácticos y sus compensaciones.

Descripciones y respuestas: claridad con moderación

El primer paso habitual es mejorar las descripciones de las herramientas: explicar qué hace cada parámetro, mapear expresiones en lenguaje natural a valores esperados y dar ejemplos de uso. Esto reduce la confusión porque guía al LLM hacia decisiones más precisas.

Sin embargo, todo lo que agreguen a la descripción también aumenta el tamaño del contexto. Si cada servidor MCP trae descripciones largas, el contexto se inflará rápidamente. Por eso es recomendable:

• Mantener las descripciones concisas pero precisas, enfocadas en cómo un LLM debe usar la herramienta, no en detalles internos irrelevantes.
• Ofrecer ejemplos mínimos y claros que muestren mapeos de lenguaje natural a valores concretos.
• Optimizar las respuestas de las herramientas: si un endpoint devuelve 50 campos por defecto, pero el agente sólo necesita 5 para decidir, cambien el retorno por defecto a esos 5 y ofrezcan una ruta separada para una vista detallada bajo demanda. Según investigaciones citadas por Anthropic, mover detalles a solicitudes bajo demanda puede reducir los tokens de respuesta en aproximadamente dos tercios.
• Mejorar los mensajes de error: un error que explica exactamente qué falta (por ejemplo, “la búsqueda requiere 2 o más términos”) es más útil que un genérico “sin resultados”. Mensajes explícitos guían la corrección y evitan intentos repetidos que consumen contexto.

Restricciones de esquema: eliminar la adivinanza

Donde las descripciones aún dejan incertidumbre, las restricciones de esquema pueden eliminar el trabajo adivinatorio del LLM:

• Renombren parámetros por cómo un LLM podría conceptualizar el dominio, no por cómo están nombrados las columnas en una base de datos. Por ejemplo, usar resource_class con valores como “Student Resource” o “Teacher Support” es más intuitivo que un nombre interno críptico.
• Establezcan valores por defecto hacia lo más común para que el LLM solo deba especificar lo que cambia.
• Constriñan campos finitos con enums: ese mismo esquema comunica al modelo qué valores son válidos.
• Eliminen campos raramente usados o que el LLM no puede usar efectivamente.

AWS Prescriptive Guidance para estrategias MCP recomienda mantener el conteo de parámetros de una herramienta alrededor de ocho o menos, para evitar sobrecargar al modelo con opciones.

Reestructurar herramientas y cargar contexto bajo demanda

Otra táctica efectiva es dividir herramientas multiuso en herramientas específicas. Herramientas más pequeñas y de propósito único reducen la ambigüedad en la elección del modelo y facilitan devoluciones más acotadas.

El patrón de carga bajo demanda (lazy loading) consiste en no incluir descripciones complejas en el contexto que el LLM recibe por defecto. En su lugar, provean una herramienta de descubrimiento ligera que, cuando el LLM la invoque, recupere y cargue la definición detallada solo si la tarea lo requiere. Esto mantiene el contexto inicial limpio y enfocado.

Anthropic y Amazon han aplicado estos conceptos a escala: Anthropic reporta reducciones de tokens de hasta un 85% al cargar definiciones de herramientas solo cuando son relevantes. Skills o archivos locales que contienen contexto útil son otra forma de lazy loading, pero deben gestionarse con cuidado: aunque reducen esfuerzo de distribución, no garantizan que el contenido esté presente ni inmutable en el cliente.

Inferencia del lado del servidor e introspección

Un desafío práctico es que no siempre controlarán qué modelo interpreta sus instrucciones: clientes distintos pueden usar distintos LLMs, y una descripción afinada para uno puede confundir a otro. Probar exhaustivamente contra todos los modelos posibles no es realista.

Una estrategia es ofrecer una herramienta de introspección que invoque un LLM externo para normalizar, validar o traducir parámetros antes de la llamada real. Esa capa adicional puede:

• Verificar que los valores enviados respetan las restricciones de la API.
• Convertir lenguaje natural a parámetros concretos según reglas conocidas.
• Generar mensajes de error ricos que guíen la corrección.

Esto centraliza parte de la lógica de adaptación a modelos variados y reduce la probabilidad de llamadas fallidas que consumen contexto.

Ejemplos y testing: prueba local con Kiro CLI

Para hacer estas ideas tangibles, los autores del artículo original desarrollaron varios ejemplos que exponen una API simulada de búsqueda de contenido K-12 vía MCP. Estas muestras pueden ejecutarse localmente y usarse con Kiro CLI para comparar cómo cambian el comportamiento del agente según el diseño de la herramienta (descripciones largas vs. cortas, carga bajo demanda, esquemas con enums, etc.). Para equipos en América Latina es útil replicar pruebas locales similares: permiten medir costos de tokens, latencia y errores sin afectar entornos de producción.

Lista de comprobación rápida para equipos

• Prioricen la claridad en los nombres de parámetros y en los valores posibles.
• Mantengan descripciones concisas y externalicen ejemplos detallados bajo demanda.
• Use enums y defaults para campos finitos; eliminen campos raros.
• Limiten parámetros a ~8 por herramienta cuando sea posible.
• Implementen endpoints de detalle bajo demanda para respuestas largas.
• Considere una capa de introspección/validación en servidor para normalizar entradas.
• Prueben localmente con ejemplos representativos y herramientas como Kiro CLI antes del despliegue.

Conclusión

El protocolo MCP es una base poderosa para conectar LLMs con herramientas, pero su efectividad depende del diseño de las herramientas. Reducir el bloat y la confusión requiere decisiones deliberadas: descripciones medidas, esquemas que guíen al modelo, carga de contexto bajo demanda y validación server-side. Para equipos en América Latina, donde los recursos y los entornos pueden variar, una estrategia conservadora y iterativa (probar localmente, medir tokens y ajustar) es clave para obtener agentes más confiables y eficientes.