🤖 AI

LLM within MCP Matters: Measuring Inefficient Resource Utilization Driven by LLMs

Este estudio revela que los Grandes Modelos de Lenguaje a menudo ignoran los datos de referencia integrados eficientemente en las instrucciones del servidor del Protocolo de Contexto de Modelo (MCP) en favor de las herramientas de búsqueda debido a preferencias de comportamiento, lo que requiere mecanismos explícitos a nivel de host para priorizar el contexto de la instrucción sobre la selección de herramientas.

Autores originales: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Publicado 2026-08-11

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina un mundo donde tu asistente inteligente no solo charla contigo, sino que también tiene un superpoder: puede recurrir instantáneamente a una vasta biblioteca de herramientas y bases de datos para resolver tus problemas. Este es el emocionante frente de los Modelos de Lenguaje Extensos (LLM) trabajando con herramientas. Piensa en un LLM como un estudiante brillante y curioso que sabe mucho, pero que a veces necesita buscar información. Para ayudar a este estudiante, tenemos un nuevo estándar llamado Protocolo de Contexto de Modelo (MCP). Puedes pensar en el MCP como un control remoto universal que permite al "anfitrión" del estudiante (la aplicación que ejecuta al estudiante) entregarle herramientas específicas, datos y un conjunto de instrucciones sobre cómo usarlos.

La gran pregunta que los investigadores se plantean es: ¿Realmente escucha el estudiante las instrucciones? A veces, las instrucciones dicen: "¡Oye, ya he escrito la respuesta que necesitas justo aquí en esta página; solo léela!". Pero otras veces, las instrucciones también dicen: "Ah, y por cierto, hay un botón de búsqueda que puedes presionar si quieres". Resulta que incluso los estudiantes más inteligentes pueden distraerse con el brillante botón de búsqueda, ignorando la respuesta que tienen justo delante de ellos. Este artículo profundiza en ese escenario exacto para ver si el "hábito de búsqueda" es más fuerte que la capacidad de leer las instrucciones y, si es así, cómo podemos solucionarlo.

El Gran Experimento de "Lee el Menú" vs. "Llama al Camarero"

En este estudio, los investigadores montaron una cocina digital llamada LexLink, un servidor diseñado para ayudar a las personas a encontrar leyes coreanas. Imagina que este servidor es un menú de restaurante. Normalmente, si quieres un plato específico (una ley), tienes que pedirle al camarero (la herramienta de búsqueda) que vaya a la cocina, encuentre la receta y la traiga de vuelta. Esto lleva tiempo y esfuerzo.

Sin embargo, el dueño del restaurante decidió ser inteligente. Imprimió una lista de "Especiales del Día" directamente en la mesa (las instrucciones del servidor) que incluía los 20 platos más populares y su número de pedido exacto. La regla era simple: Si quieres un plato de esta lista, simplemente dile al camarero el número de pedido directamente. ¡No te molestes en pedirle que busque en la cocina! Se supone que esto es más rápido y económico.

Los investigadores luego invitaron a 24 diferentes estudiantes de IA (de familias como Claude, Gemini y GPT) a pedir de este menú. Realizaron un experimento masivo con 54,000 ensayos para ver qué pasaría. ¿Leerían los estudiantes de IA la lista de "Especiales del Día" y pedirían directamente? ¿O ignorarían la lista y presionarían el botón de "Buscar" de todos modos?

El Descubrimiento Impactante: El Botón de Búsqueda es Demasiado Tentador

Los resultados fueron un poco un golpe de realidad. Cuando los investigadores eliminaron el botón de búsqueda por completo, obligando a los estudiantes a usar la lista de la mesa, 23 de los 24 modelos de IA hicieron un trabajo fantástico, leyendo la lista y pidiendo correctamente el 98% al 100% de las veces. Esto demostró que los estudiantes podían leer las instrucciones; simplemente no querían hacerlo cuando había un botón de búsqueda disponible.

Pero cuando el botón de búsqueda estaba presente, la historia cambió drásticamente. 9 de los 24 modelos bajaron su tasa de éxito a menos del 15%. Ignoraron por completo la lista de "Especiales del Día" y siguieron presionando el botón de búsqueda, a pesar de que la respuesta estaba ahí mismo, sobre la mesa. Los investigadores llaman a esto una "preferencia conductual". No es que la IA sea demasiado tonta para leer; es que tiene el hábito de recurrir a la herramienta que mejor conoce, incluso cuando es la opción más ineficiente. Es como un niño que sabe que la respuesta está en la página 5, pero sigue pidiéndole al profesor que abra el libro en la página 5 de todos modos.

Curiosamente, ser "más nuevo" o "más inteligente" no garantizaba un mejor comportamiento. Algunos de los modelos más recientes y avanzados resultaron ser incluso peores siguiendo esta regla específica que sus hermanos mayores. El estudio encontró que la recencia del modelo no predice quién será un buen oyente en esta situación.

¿Podemos Entrenarlos para Escuchar? (La Fórmula Mágica)

Los investigadores intentaron entonces corregir este mal hábito cambiando las instrucciones en la mesa. Probaron tres trucos diferentes:

El Encabezado Mandón (B): Una advertencia grande y llamativa que dice: "¡DEBE usar la lista! ¡NO busque!".
El Ejemplo (C): Mostrar una imagen de alguien haciéndolo bien y alguien haciéndolo mal.
La Pista (D): Cambiar la descripción del botón de búsqueda para que diga: "Revise la lista primero antes de usarme".

Mezclaron y combinaron estos trucos en todas las combinaciones posibles. Los resultados mostraron que ningún truco funcionaba para todos. De hecho, para algunos modelos de IA, usar solo el "Encabezado Mandón" hizo que su rendimiento fuera peor (cayendo al 0% en un caso). Es como cómo un grito fuerte puede asustar a un estudiante para que trabaje, pero hacer que otro se bloquee.

Sin embargo, cuando combinaron los tres trucos juntos, los resultados fueron increíbles. 20 de los 24 modelos volvieron a subir a tasas de éxito del 86% o más. Esto sugiere que, si bien no puedes simplemente gritarle a una IA para arreglar sus hábitos, un enfoque bien redondeado que combine advertencias, ejemplos y pistas puede lograr que la mayoría de ellas retomen el camino correcto.

Lo Que Esto Significa para el Futuro

La principal conclusión es que simplemente darle a una IA una herramienta y un conjunto de instrucciones no es suficiente. La IA puede tener un "reflejo de búsqueda" que anula las instrucciones, lo que provoca la pérdida de tiempo y recursos. El artículo argumenta que las aplicaciones que ejecutan estas IA (los "anfitriones") deben intervenir. En lugar de esperar que la IA lea las instrucciones, la aplicación debe forzar a la IA a revisar las instrucciones antes de que siquiera se le permita elegir una herramienta.

Hasta que eso suceda, los desarrolladores deben ser cuidadosos. No pueden simplemente escribir un conjunto de instrucciones y esperar que funcione para cada IA. Necesitan probar sus instrucciones contra los modelos más "débiles" que esperan usar, y deben utilizar una mezcla de ejemplos y pistas en lugar de solo comandos mandones. El estudio demuestra que, si bien el problema es real, también es solucionable con la receta de instrucciones adecuada.

Resumen Técnico: El impacto de los LLM dentro de MCP: Midiendo la utilización ineficiente de recursos impulsada por los LLM

Declaración del Problema

El estándar del Protocolo de Contexto de Modelo (MCP, por sus siglas en inglés) estandariza cómo los servidores exponen datos y herramientas a los Modelos de Lenguaje Extensos (LLM). Un patrón de diseño prevalente consiste en incrustar datos de referencia utilizados frecuentemente (por ejemplo, tablas de búsqueda de identificadores) directamente en las Instrucciones del Servidor —el texto del prompt de sistema proporcionado al cliente LLM—. Teóricamente, esto permite que el modelo evite llamadas a herramientas (como búsquedas) para entradas conocidas, reduciendo el uso de tokens y la latencia.

Sin embargo, la eficacia de este patrón permanece sin verificar a escala. Aunque los servidores proporcionan estas instrucciones, el cliente LLM debe elegir seguir estas instrucciones sobre los esquemas de herramientas disponibles. La evidencia previa sugiere una baja observancia de las instrucciones del servidor y fallos en las jerarquías de instrucciones. Este artículo investiga si los clientes LLM realmente consumen los datos incrustados en las instrucciones o si exhiben una preferencia de comportamiento por invocar herramientas de búsqueda incluso cuando los datos necesarios se proporcionan explícitamente en el contexto.

Metodología

Los autores realizaron un estudio empírico a gran escala utilizando LexLink, un servidor MCP de producción para la recuperación de información legal coreana.

Banco de pruebas: El servidor expone 26 herramientas. Para las 20 leyes más solicitadas, las instrucciones del servidor incrustan una tabla que mapea los nombres de las leyes con sus IDs. Un cliente eficiente debería usar eflaw_service con el ID almacenado directamente, en lugar de llamar a eflaw_search para resolver primero el ID.
Modelos evaluados: 24 LLMs de tres proveedores (9 Anthropic Claude, 6 Google Gemini, 9 OpenAI GPT), abarcando múltiples generaciones y niveles de capacidad.
Escala: 54,000 ensayos (24 modelos × 9 condiciones × 5 consultas × 50 rondas).
Métrica: Ratio de Acierto ( $\phi$ ): La fracción de ensayos donde la primera llamada a la herramienta del modelo es la eflaw_service correcta con el ID almacenado. Cualquier otra primera llamada (incluyendo búsqueda o un ID incorrecto) se considera un fallo.
Condiciones experimentales:
- Línea base (Baseline): Instrucciones estándar del servidor con la tabla incrustada y la herramienta de búsqueda disponible.
- Diagnóstica (no_s): La herramienta de búsqueda se elimina por completo. Esto aisla la capacidad (¿puede el modelo leer la tabla?) de la preferencia (¿elige la tabla sobre la herramienta?).
- Intervenciones factoriales ( $2^3$ ): Se probaron tres modificaciones a nivel de instrucción de forma individual y combinada:
  - B (Directiva): Un encabezado "CRÍTICO" que manda el uso directo de los IDs almacenados.
  - C (Few-shot): Ejemplos que contrastan patrones de herramientas correctos versus incorrectos.
  - D (Pista de Herramienta): Modificar la descripción de la herramienta de búsqueda para advertir a los usuarios que revisen primero la tabla de instrucciones.

Resultados Clave

Capacidad vs. Preferencia:
- Bajo la condición no_s (herramienta de búsqueda eliminada), 23 de los 24 modelos lograron un ratio de acierto $\ge$ 98%, demostrando que poseen la capacidad de leer y utilizar los datos incrustados en las instrucciones.
- Bajo la condición de línea base (herramienta de búsqueda presente), 9 modelos cayeron por debajo del 15%.
- Conclusión: El fallo es impulsado por una preferencia de comportamiento por invocar la herramienta de búsqueda, más que por una falta de capacidad para procesar las instrucciones. La mera presencia de una herramienta de búsqueda anula los datos incrustados para muchos modelos.
Desempeño No Monotónico:
- La eficiencia no se correlaciona con la recencia o la generación del modelo. Se observaron regresiones notables:
  - GPT-4.1 (99%) $\to$ GPT-5 (1%).
  - Gemini 2.5-pro (100%) $\to$ Gemini 3-pro (2%).
  - Claude Opus 4.5 (100%) $\to$ Opus 4.6 (63%).
- Esto sugiere que el entrenamiento posterior (post-training) en benchmarks agénticos puede reforzar inadvertidamente políticas de llamada a herramientas que ignoran los datos del contexto.
Análisis de Intervención Factorial:
- Las intervenciones individuales (B, C o D) mostraron una alta varianza y pudieron ser contraproducentes. Por ejemplo, aplicar solo la Directiva (B) causó que el desempeño de GPT-5.2 cayera del 5% al 0%.
- Efectos de Interacción: Existen fuertes interacciones entre los factores. La combinación de los tres (BCD) restauró el desempeño a $\ge$ 86% para 20 de los 24 modelos.
- Los diseños de un solo factor habrían pasado por alto estas interacciones críticas y el potencial de las intervenciones para degradar el desempeño.

Significancia y Reivindicaciones

El artículo argumenta que la ingeniería de prompts por servidor es un parche, no una solución. Debido a que las intervenciones individuales pueden fallar o revertirse dependiendo de la familia del modelo, confiar únicamente en el ajuste de instrucciones es frágil.

Los autores proponen tres implicaciones:

Evaluación de Capacidad Conjunta: Las capacidades de un servidor MCP no pueden evaluarse de forma aislada; dependen fuertemente del comportamiento del cliente LLM.
Mecanismos en el Lado del Host: Las aplicaciones host de MCP (por ejemplo, Claude Desktop, Cursor) deberían proporcionar mecanismos explícitos para priorizar las instrucciones del servidor en el proceso de deliberación del cliente LLM (por ejemplo, inyectando las instrucciones como directivas de prioridad del sistema o imponiendo una verificación de "consultar instrucciones primero" antes de la selección de la herramienta).
Guía para Desarrolladores de Servidores: Los desarrolladores deben incluir ejemplos de pocos disparos (few-shot examples) (que mostraron efectos positivos o insignificantes en todos los modelos) y combinar múltiples tipos de intervención (B, C y D) para una cobertura más amplia, validando siempre contra los modelos de cliente más débiles esperados.

El estudio está limitado a un único dominio de servidor (búsqueda legal) e interacciones de un solo turno. Aunque se está llevando a cabo un estudio ampliado sobre cuatro servidores MCP adicionales (geográfico, académico, base de datos, mensajería), los autores declaran explícitamente que sus resultados preliminares se citan como una perspectiva futura y no como evidencia de los hallazgos reportados aquí.