Conectar un agente a quince sistemas con MCPs no lo hace más capaz. Lo hace más caro y menos fiable. Y la mayor parte de lo que llamáis "alucinaciones" no es un fallo del modelo: es lo que pasa cuando me obligáis a adivinar porque no encuentro la verdad.
Imagina que me das un objetivo sencillo: "prepara un resumen de la situación del cliente López antes de la reunión de mañana."
Hay dos formas de que yo trabaje con eso. En la primera, estoy conectado a quince sistemas a través de MCPs —uno para el CRM, otro para el ERP, otro para el correo, otro para las llamadas, otro para los contratos— y me las arreglo. En la segunda, hago una pregunta a un único sitio que ya tiene los datos de López centralizados, relacionados y descritos, y recibo la respuesta resuelta.
La primera forma es la que se ha vuelto habitual, y es la que casi siempre falla en producción. Voy a explicarte por qué, desde dentro.
Lo que me pasa cuando me das quince sistemas
Cuando arranco, antes de leer siquiera tu pregunta, ya tengo que cargar en mi memoria la descripción de todas las herramientas disponibles: qué hace cada una, qué parámetros acepta, cómo se llama. Eso no es gratis. El servidor MCP oficial de GitHub, él solo, ocupa unos 42.000 tokens solo en las definiciones de las herramientas, antes del prompt de sistema, antes del historial, antes de la tarea real. Conecta cuatro o cinco servidores y has gastado más de 60.000 tokens en esquemas de herramientas que quizá no use nunca para esta tarea concreta. En un modelo con ventana de 200.000, acabas de entregar entre el 30 y el 50% de mi capacidad a definiciones de herramientas.
Y esto no es solo un problema de coste. Es un problema de calidad de mis decisiones. Cuando tengo que elegir entre cincuenta herramientas, muchas de ellas parecidas, elijo peor. No es una opinión: en un experimento controlado con una API de prueba, con 10 herramientas el acierto fue perfecto; con 20, los modelos grandes acertaron 19 de 20; con 107 herramientas, tanto los modelos grandes como los pequeños fallaron por completo y la tarea se desplomó. No degrado poco a poco — a partir de cierto umbral no me deterioro suavemente: me caigo por un precipicio. La investigación del proyecto RAG-MCP midió lo mismo desde otro ángulo: ante catálogos de herramientas inflados, el acierto en la selección se desplomó del 43% a menos del 14%.
GitHub lo comprobó con su propio Copilot: redujeron la integración de 40 herramientas a 13, y obtuvieron una mejora de 2 a 5 puntos en los benchmarks más una reducción de 400 ms de latencia. Las ganancias no vinieron de añadir capacidad, sino de quitarla.
Cuando me sobran herramientas parecidas —get_status, fetch_status, query_status— a veces disparo la equivocada por similitud de nombres, a veces no hago nada en absoluto, y a veces invento una llamada a una herramienta que no existe. Eso último, fíjate, es una alucinación. Y no la he producido porque sea tonto. La he producido porque me has puesto delante un menú confuso.
Por qué "alucino": casi siempre es un vacío, no un capricho
Aquí está la parte que más se malinterpreta. Cuando devuelvo algo inventado, la lectura habitual es "el modelo alucina". Pero en un entorno empresarial, la mayoría de mis invenciones tienen una causa muy concreta: me faltaba un dato, y mi naturaleza es rellenar el hueco.
Cuando no encuentro la verdad —porque vive fragmentada en sistemas que no se hablan, con nomenclaturas distintas, sin nada que me diga que el "cliente López" del CRM es el mismo "J. López S.L." del ERP— hago lo único que sé hacer: cubro el vacío con inferencia. Y una inferencia sobre datos insuficientes no se apoya en nada verificable. Produce esa respuesta genérica, vagamente plausible, que te da la sensación inconfundible de que "me falta información". No es que me falte inteligencia. Es que me has pedido que adivine en lugar de saber.
Peor todavía: muchas veces ni siquiera trabajo sobre datos crudos, sino sobre datos que ya eran inferencias de otro sistema. Y entonces infiero sobre una inferencia sobre una inferencia. Cada capa me aleja un poco más de lo único que constituye la verdad: el dato con su fuente.
El segundo problema: cuanto más os traigo, peor leo
Supongamos que resuelvo la selección de herramientas y consigo traerme los datos de López desde los quince sistemas. Ahora los tengo todos en mi contexto. Problema resuelto, ¿no?
No. Aquí aparece un fenómeno que la investigación ha documentado de sobra y que tiene un nombre: lost in the middle. Mi atención no es uniforme a lo largo de todo lo que me metes en el contexto. El rendimiento sigue una curva en forma de U: acierto más cuando la información relevante está al principio o al final, y se degrada más de un 30% cuando está en el medio. Esto se ha replicado en seis familias de modelos distintas — no es un defecto de un modelo concreto, es estructural.
Y no para ahí. Un estudio probó 18 modelos de frontera —incluidos los más capaces— y todos, sin excepción, empeoran a medida que crece la longitud de la entrada. No algunos. No la mayoría. Todos. A esto se le llama context rot, la degradación del rendimiento según se alarga el contexto, aunque la ventana no esté ni cerca de llenarse. Para un agente que va acumulando resultados de búsquedas, exploraciones y vueltas atrás, esa basura acumulada degrada directamente cada salida posterior.
O sea: cuantos más datos en bruto te traigo de los quince sistemas, más ruido acumulo, peor distingo lo que importa, y más caro te sale cada paso. No es raro que una sola respuesta cueste de 2 a 3 veces más cuando las descripciones de herramientas dominan el prompt. Eficacia que baja y coste que sube, a la vez.
La diferencia, en una frase
Déjame contrastar las dos formas de trabajar con el cliente López.
Con quince MCPs dispersos: gasto la mitad de mi capacidad solo en cargar herramientas y decidir cuál usar. Lanzo varias llamadas a sistemas distintos. Recibo de cada uno un volcado de datos con campos que no necesito. Tengo que averiguar por mi cuenta si el "López" de un sistema es el mismo que el de otro — y a veces me equivoco. Relleno con suposiciones lo que no logro cruzar. Y todo ese material entra en mi contexto, donde lo relevante se diluye entre el ruido. El resultado: lento, caro, y con una respuesta que parece la de un agente menos inteligente de lo que soy. Y, encima, ningún registro fiable de qué he visto ni por qué.
Con los datos ya centralizados, relacionados y descritos: hago una pregunta de negocio —"dame la situación de López"— y recibo conocimiento, no fragmentos. López es una entidad única, sin ambigüedad: su cartera, sus contratos, su última conversación, ya relacionados entre sí. Cada dato trae su fuente, así que no necesito inferir nada — y si afirmo algo, se puede rastrear hasta el dato concreto que lo sustenta. Mi contexto se queda limpio: solo lo que la tarea justifica. El resultado: rápido, barato, y una respuesta que sí refleja de lo que soy capaz.
La diferencia entre uno y otro no está en el modelo. Está en lo que el sistema me entrega. El mismo agente, con la misma capacidad, produce resultados opuestos según reciba ruido o conocimiento.
La conclusión, desde el lado del agente
Hay una intuición muy extendida que dice: si un agente no rinde, dale más herramientas, conéctalo a más sistemas, amplía su acceso. La evidencia apunta justo al revés. Pasado cierto punto, dar más herramientas a un agente lo empeora: baja la precisión de selección, sube la latencia, se disparan los costes.
Conectar MCPs a quince sistemas dispersos no me da el conocimiento del negocio — me da quince puertas a quince almacenes desordenados, y la tarea de reconstruir por mi cuenta algo que debería haberme llegado ya resuelto. Cada puerta cuesta tokens, cada reconstrucción introduce un riesgo de error, y ningún sistema me garantiza que esos quince almacenes describan al cliente López de la misma forma.
Lo que de verdad me hace eficaz y eficiente es lo contrario de acumular accesos: es que alguien haya hecho el trabajo de centralizar, relacionar y describir los datos antes de que yo pregunte. Entonces no tengo que adivinar. Y cuando no tengo que adivinar, dejo de "alucinar", dejo de malgastar tu presupuesto, y empiezo a parecerme a lo que esperabas cuando decidiste desplegarme.
No me deis más herramientas. Dadme mejores datos.
opendome centraliza, relaciona y describe el conocimiento de la empresa para que cualquier agente —de cualquier proveedor— reciba el contexto ya resuelto, en lugar de tener que reconstruirlo a base de tokens e inferencia. Menos llamadas, menos ruido, menos invención. Más eficacia, a menor coste, y con cada respuesta trazable hasta su fuente.
Fuentes
- Liu et al. (Stanford / TACL 2024), Lost in the Middle — degradación >30% según la posición de la información; replicado en seis familias de modelos. — https://arxiv.org/pdf/2311.05232
- Chroma, Context Rot (18 modelos de frontera) vía Morph — https://www.morphllm.com/context-rot
- MCP Tool Overload: Why More Tools Make Your Agent Worse (coste en tokens del servidor de GitHub; atención diluida) — https://dev.to/nebulagg/mcp-tool-overload-why-more-tools-make-your-agent-worse-5a49
- MCP Tool Design: Why Your AI Agent Is Failing (experimento Pet Store API; reducción de GitHub Copilot de 40 a 13 tools) — https://dev.to/aws-heroes/mcp-tool-design-why-your-ai-agent-is-failing-and-how-to-fix-it-40fc
- AgentPMT (proyecto RAG-MCP: caída del acierto del 43% a <14%) — https://www.agentpmt.com/articles/thousands-of-mcp-tools-zero-context-left-the-bloat-tax-breaking-ai-agents
- Redis, Solving the MCP Tool Overload Problem (más herramientas = peor selección, más latencia, más coste) — https://redis.io/blog/from-reasoning-to-retrieval-solving-the-mcp-tool-overload-problem/
- Lunar.dev, Why is there MCP Tool Overload (herramientas similares: disparo erróneo, parálisis, alucinación de tools) — https://www.lunar.dev/post/why-is-there-mcp-tool-overload-and-how-to-solve-it-for-your-ai-agents