Prueba un backend de datos MCP con trabajo real de agentes
Ejecuta el mismo modelo con un backend de datos MCP y con búsqueda web, luego puntúa respuestas, llamadas a herramientas, costo y latencia con tus propias preguntas.

Estás decidiendo si un backend de datos MCP superará a la búsqueda web en tus propias preguntas. Una página de un proveedor puede hacer que la respuesta parezca ya resuelta. Un modelo impulsado por Drillr MCP obtuvo 94,06% en Vals Finance Agent. En el ranking Finance Agent v2 de Vals, Muse Spark 1.2 lidera con 60,60%, por delante de Claude Opus 5 con 58,63% y Gemini 3.5 Flash con 57,86%. Esos números no son tu flujo de trabajo. Esa brecha es la razón para probar.
Bajo el sistema de puntuación All-Pass más estricto de Vals, el modelo líder bajó a 50,88%, y el resto se mantuvo por debajo del 48%. Esa caída es la advertencia: un benchmark puede variar mucho cuando cambian las reglas. Y aun así no muestra tu factura, tu fecha límite de presentación ni tu desordenada hoja de cálculo.
La prueba interna de Drillr pasó Sonnet 5 por Drillr MCP y por búsqueda web general con las mismas 200 preguntas, usando una rúbrica fija y contando cada llamada a herramienta. Las filas públicas de Drillr para Drillr MCP y búsqueda web usaron Claude Opus 4.6 en el conjunto de pruebas público de Finance Agent v1.1. Drillr diseñó y calificó ese benchmark interno, y publicó los hallazgos como investigación de la empresa, no como una auditoría externa ni una certificación externa. La ejecución detrás de esas cifras de Drillr tuvo lugar el 14 de agosto de 2026. Trata esos números como una plantilla, no como un veredicto. El método vale la pena replicar.
Realiza una prueba de dos brazos con tus propias preguntas
Pregúntate si el backend cambia la respuesta, no si se ve impresionante. Mantén el modelo constante y compara un backend estructurado contra la búsqueda web.
- Elige 20 preguntas reales de tu flujo de trabajo. No dejes que el agente las elija; si puede pedir las fáciles, la prueba se convierte en un truco de confianza. El resultado debe parecer una lista que realmente harías este mes, no una demo de un proveedor.
- Congela el modelo, el prompt, el formato de respuesta y el orden de las preguntas. La prueba funciona cuando puedes cambiar la fuente de datos sin alterar nada más.
- Ejecuta el mismo modelo con un backend de datos MCP. Busca respuestas que usen los datos del backend en lugar de solo conocimiento general.
- Ejecuta el mismo modelo con búsqueda web general. Deberías ver navegación, pero sin acceso a tu backend privado.
- Puntúa cada respuesta contra una rúbrica fija antes de leer la siguiente. Una segunda verificación es que otra persona pueda puntuar la misma respuesta y llegar al mismo veredicto.
- Cuenta cada llamada a herramienta, incluidos reintentos y llamadas fallidas. Ese conteo muestra si el backend ahorra esfuerzo o solo añade pasos.
- Compara precisión, costo y latencia en cada ejecución. Termina con una decisión clara sobre tus preguntas, no sobre las de un proveedor.
Puntúa la respuesta, no la demo
Una buena rúbrica debe ser aburrida. Una rúbrica es un contrato que firmas antes de la ejecución. Debe verificar la corrección, la citación de la fuente, la usabilidad sin limpieza y los detalles inventados. Si el backend da un número limpio pero el modelo lo explica mal, la respuesta sigue siendo débil. Si la búsqueda web encuentra el dato correcto pero añade texto extra, la respuesta sigue siendo débil.
Mantén la rúbrica fija antes de ejecutar la prueba. Cambiarla después de ver los resultados debilita la prueba. Juzga si la ruta de datos cambia el trabajo, no el encanto del modelo.
Mantén la prueba lo suficientemente pequeña para repetirla
Registra el costo y la latencia de cada respuesta, aunque los números sean pequeños. Un backend más preciso pero más lento o más caro puede seguir ganando en un cierre mensual. Puede perder en una verificación rápida. Dimensiona la prueba para que puedas repetirla después de un cambio de modelo, un cambio de backend o un cambio en tus preguntas.
Cuando tengas los resultados, escribe un veredicto breve: qué configuración fue mejor en tus preguntas y por cuánto. Si la respuesta no es clara, la prueba fue demasiado pequeña, demasiado vaga o demasiado fácil. Vuelve a ejecutarla con preguntas más difíciles de tu mes real.