Cuando un agente falla en producción, el reflejo más común del equipo técnico es revisar el tool-calling. ¿Invocó bien la función? ¿Llegaron los parámetros correctos? ¿Respondió el servidor MCP? MCP-Atlas, un benchmark reciente sobre competencia real en uso de herramientas (arxiv.org/abs/2602.00933), muestra que ese reflejo apunta al lugar equivocado el 63% de las veces.
El paper en dos minutos
MCP-Atlas evalúa veinte modelos frontier de seis proveedores contra 36 servidores MCP reales de producción —no mocks, no simulaciones— con 1.000 tareas escritas por expertos humanos. Las tareas no especifican qué servidor usar ni qué parámetros pasar: el modelo debe inferir la herramienta correcta entre distractores semánticamente plausibles, encadenar múltiples pasos, y sintetizar un output coherente.
El resultado top: 82.2% de tasa de aprobación con umbral de 0.75 de cobertura de afirmaciones atómicas. El resultado más interesante: los veinte modelos se distribuyen en tres niveles de desempeño claramente diferenciados, y los fallos de los modelos del nivel alto raramente ocurren en la invocación de la herramienta.
La taxonomía diagnóstica del paper (11 categorías) descompone los errores entre fallos de tool-calling y fallos cognitivos. Los fallos cognitivos incluyen: detención prematura después de una ejecución exitosa, síntesis incorrecta del output, comprensión parcial de la tarea. El 63.3% de los fallos diagnosticados cae en esa segunda categoría.
Por qué este hallazgo importa diferente en la región
En Europa y Norteamérica, la conversación sobre agentes MCP gira alrededor del performance en benchmarks públicos como palanca de decisión de compra. El proveedor con mejor score se lleva el POC. Esa lógica funciona cuando los equipos tienen capacidad de evaluación interna sofisticada.
En Chile y el resto de la región, la realidad es distinta. Los equipos técnicos que integran agentes en producción generalmente no tienen presupuesto para hacer evaluaciones propias a la escala de 1.000 tareas. Dependen de benchmarks externos para tomar decisiones, y esa dependencia carga un sesgo grave: los benchmarks públicos más conocidos evalúan invocación de herramientas, no cognición post-ejecución.
El hallazgo del 63% de fallos cognitivos no es un dato académico. Es un problema operacional directo. Un equipo que elige modelo LLM mirando solo el tool-calling accuracy está optimizando para el 37% del problema.
Lo que MCP-Atlas revela sobre cómo evaluar
El diseño del benchmark tiene tres decisiones que deberían volverse estándar en evaluaciones propias:
Servidores MCP reales, no simulados. La brecha entre un servidor mockeado y uno de producción —en latencia, errores, respuestas parciales y edge cases— es enorme. Evaluar contra mocks sobreestima el desempeño de forma sistemática.
Distractores semánticamente plausibles. El modelo debe seleccionar la herramienta correcta de un conjunto que incluye alternativas que se parecen en nombre y descripción. Esto replica con precisión lo que ocurre cuando un agente tiene acceso a 40 o más herramientas en un MCP server real.
División pública/privada de tareas. 500 tareas públicas para desarrollo, 500 privadas para evaluación limpia. Este diseño evita que los proveedores ajusten sus modelos específicamente para el benchmark. En contextos donde el riesgo de sobreajuste de los vendors a benchmarks públicos es alto —y la región tiene menos capacidad de verificación independiente—, esta separación importa especialmente.
Implicaciones operacionales
El error más frecuente observado en implementaciones regionales no es elegir el modelo equivocado: es no medir lo que realmente importa. Los equipos hacen demos donde el agente invoca herramientas correctamente, declaran éxito, y después en producción el agente completa el tool-call pero entrega un resumen incorrecto, se detiene antes de completar el flujo, o pierde el hilo entre pasos.
Eso es exactamente lo que MCP-Atlas llama fallos cognitivos post-ejecución. Y es lo que ningún benchmark de tool-calling muestra, porque esos benchmarks terminan cuando la herramienta se invocó bien.
Un punto débil del paper merece nombrarse: la ausencia de estratificación por dominio. Los 36 servidores MCP cubren distintas categorías funcionales, pero los resultados se reportan agregados. Para un equipo que va a desplegar un agente específicamente para consultas regulatorias o integración con sistemas legacy, el comportamiento agregado de 220 herramientas de producción general dice poco sobre el desempeño en su dominio específico.
Tres ajustes concretos para evaluación
A partir de las lecciones del paper, conviene incorporar tres prácticas en el diseño de evaluaciones propias para agentes MCP en producción:
Primero, incluir tareas de síntesis. Una evaluación no debería terminar cuando el tool-call fue exitoso. Conviene medir si el modelo sintetiza correctamente el output de la herramienta en el contexto de la tarea completa.
Segundo, usar distractores reales. En el MCP server de evaluación, incluir herramientas similares a las que se busca probar pero no exactamente correctas. La capacidad de discriminación semántica es más predictiva del desempeño en producción que el raw tool-calling accuracy.
Tercero, medir detención prematura de forma explícita. Es el fallo más frecuente en modelos del nivel alto según MCP-Atlas, y el más difícil de detectar, porque la invocación fue exitosa: el modelo simplemente no continúa el flujo completo.
La pregunta abierta
Si el 63% de los fallos son cognitivos y los proveedores están optimizando sus modelos para tool-calling accuracy, ¿qué tan lejos está el punto donde los benchmarks públicos dejen de ser informativos para decisiones de arquitectura real?
Para los equipos que evalúan agentes MCP en producción hoy, la respuesta práctica no es esperar a que los benchmarks evolucionen. Es construir evaluación propia que mida lo que MCP-Atlas demuestra que importa.
Fuente: Anonymous Authors. "MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers." arXiv:2602.00933, mayo 2026.