AWS publica 6 enfoques para optimizar herramientas MCP y ahorrar contexto

El 12 de julio de 2026, AWS publicó una guía técnica sobre los problemas de diseño de herramientas MCP y propuso 6 enfoques prácticos para resolverlos, desde optimizar las descripciones hasta analizar parámetros en el servidor con IA. La investigación se basa en pruebas reales con una API de búsqueda de contenido educativo (K-12).

Por qué las herramientas MCP reducen la calidad de los modelos

Model Context Protocol ayuda a los LLM a usar herramientas externas, pero las definiciones suelen estar mal diseñadas. AWS identificó dos problemas principales:

Bloat (hinchazón): cada servidor MCP carga las definiciones de sus herramientas en la ventana de contexto, aunque no se usen. Con varios servidores activos, la ventana se llena de definiciones antes de que el usuario haga la primera pregunta.

Confusion (confusión): un contexto sobrecargado degrada el razonamiento del modelo. El LLM confunde herramientas parecidas, se equivoca con los parámetros e interpreta mal las restricciones. La similitud semántica entre herramientas y los nombres de parámetros poco claros agravan el problema.

6 enfoques: todo el espectro de soluciones

AWS probó seis implementaciones con consultas reales como «Encuentra un examen de fracciones para 7.º grado» y «Necesito contenido alineado con TEKS»:

• V1 (Raw Passthrough): expone la API del backend tal cual, con muchos errores de parámetros
• V2 (Rich Descriptions): docstrings detallados con ejemplos, que mejoran la precisión pero aumentan el tamaño
• V3 (Schema & Defaults): parámetros renombrados (`discipline` → `subject`), enums `Literal`, valores por defecto razonables; un buen compromiso
• V4 (Lazy Loading): los detalles (taxonomía) quedan tras una herramienta aparte; ofrece una base mínima, pero requiere consultas adicionales
• V5 (Server-side Introspection): Amazon Nova 2 Lite analiza los parámetros en el servidor; el comportamiento es estable, pero añade llamadas de inferencia
• V6 (Agent-as-Tool): un único parámetro `question: str` con toda la lógica dentro; máximo control, pero exige infraestructura

Recomendaciones clave de AWS

AWS Prescriptive Guidance recomienda limitar los parámetros de una herramienta a «aproximadamente ocho o menos». La investigación de Anthropic mostró que pasar a una salida detallada bajo demanda reduce los tokens de respuesta en cerca de dos tercios.

Además: redactar mensajes de error específicos y accionables (no solo «no results», sino una descripción exacta de qué probar). Usar nombres de parámetros propios del dominio en lugar de nombres de columnas de la base de datos reduce de forma notable la confusión del modelo.

Cómo elegir el enfoque para tu caso

No existe una solución universal. La elección depende del número de parámetros (pocos → V3, muchos → V4-V5), la estabilidad del vocabulario, los requisitos de latencia y si hace falta uniformidad entre distintos modelos. Para la mayoría de las tareas de búsqueda y filtrado basta con V3. Las aplicaciones especializadas (taxonomías complejas, razonamiento de varios pasos) se benefician de V4-V5.

Qué significa

Las herramientas MCP suelen ralentizar hoy a los agentes LLM, pero AWS ha demostrado que el problema se puede resolver con ingeniería de contexto. Los ingenieros cuentan ahora con un playbook práctico para equilibrar contexto y precisión, en lugar de añadir descripciones a ciegas.