Servidores Guías
En esta página
Avanzado Lección 8 de 9 ≈ 50 min de lectura
Especificación 2026-07-28
Evaluar si el modelo usa bien tus tools
Especificación MCP 2026-07-28 · revisada el 2 de octubre de 2026
Cómo saber si el modelo elige y usa bien las tools que diseñaste: qué fallos medir, cómo construir casos con preguntas reales, cómo comparar dos modelos y cómo decidir si el arreglo va en la tool, en el host o en ningún sitio.
Qué aprenderás
- Diagnosticar en una traza cuál de los cuatro fallos comete el modelo: no elige la tool, rellena mal sus argumentos, se equivoca de secuencia o gasta de más
- Construir un conjunto de casos a partir de preguntas reales de soporte, sin datos personales y con las llamadas esperadas de cada uno
- Ejecutar los mismos casos con dos modelos y leer la tabla para separar lo que falla por la definición de lo que falla por el modelo
- Decidir si un fallo se arregla en la tool, en el host o en ningún sitio, y cuándo dejar de cambiar la definición
Contenido de la lección
- 01 El problema
- 02 Qué medir: elección, argumentos, secuencia y coste
- 03 Casos a partir de preguntas reales de soporte
- 04 Ejecutar con dos modelos y leer la tabla
- 05 El bucle: cambiar, medir y saber cuándo parar
- 06 Cuándo el fallo es del host y no de la tool
- 07 En producción
Además: quiz de comprobación y desafío práctico.
Extracto
Una agente de soporte de la oficina de Barcelona escribe en la consola: «¿Qué pedidos de Barcelona tienen una incidencia abierta?». El agente le contesta que ninguno. Hay dos, PED-2026-004797 y PED-2026-004805, los dos en el almacén BCN-02. El modelo eligió bien la tool, listar_pedidos, y la llamó con almacen: "BCN-01". Ese almacén no existe, el servidor devolvió una lista vacía sin error y el modelo se la creyó.
Ningún test lo había detectado. La tool valida su entrada, el argumento tiene un pattern y la descripción pasa el test de definiciones de la lección 5. Lo comprobamos: contra esta versión de listar_pedidos, ese test termina con 1 passed. Las pruebas de aquella lección responden a si la tool funciona cuando la llaman bien. Aquí la pregunta es otra: si el modelo, con la definición que publicas, la llama bien.
Fin del extracto · la lección sigue con 6 secciones más
Artículos relacionados
Preguntas frecuentes
¿Por qué un modelo llama a una tool MCP con argumentos equivocados aunque la tool funcione?
Porque el modelo solo sabe de cada tool lo que publica el servidor en su definición: cómo se llama, qué hace según su descripción y qué parámetros acepta. Si un argumento admite cualquier código con cierto formato pero no enumera los que existen, el modelo puede inventar uno plausible, recibir una respuesta vacía sin error y darla por buena. Los tests que llaman a la tool con datos correctos no detectan ese hueco. En la lección se reproduce un caso así con modelos reales sobre un servidor de Nortia y se corrige midiendo antes y después.
¿Cómo se comparan dos modelos usando las mismas tools MCP?
Lanzando el mismo conjunto de casos, sin cambiar de aplicación anfitriona ni de definiciones, contra cada modelo y varias veces, porque una sola pasada no es fiable. La comparación sirve sobre todo para separar responsabilidades: si los dos fallan igual en un caso, la causa suele estar en la definición de la tool; si solo falla uno, entra en juego el modelo. En la lección se ejecuta esa comparación de verdad con dos modelos y se interpreta su tabla.
¿Cuándo se arregla un fallo de uso de tools en el host y no en el servidor MCP?
Cuando lo que falla no depende de lo que publica el servidor: la aplicación anfitriona elige qué herramientas se le muestran al modelo, qué le dice en su prompt de sistema, con qué modelo trabaja y qué llamadas necesitan aprobación antes de salir. Una llamada bloqueada por la aplicación puede parecer, a simple vista, un error del modelo. Y hay fallos que no conviene tocar en ninguna parte. En la lección se ve con ejecuciones reales cómo distinguir los tres casos y cuándo dejar de cambiar la definición.