Evaluaciones para WebMCP

Kasper Kulikowski

Publicado el 19 de mayo de 2026

WebMCP admite agentes que usan modelos de IA generativa. Para probar cualquier sistema que use IA generativa, tus pruebas deben admitir resultados probabilísticos: una entrada podría generar miles de respuestas con distintos grados de precisión. Esta técnica de prueba se denomina evaluaciones o evals.

Antes de lanzar herramientas a producción, debes confirmar que los agentes comprendan cuándo llamar a la herramienta, cómo ejecutarla y qué respuestas son aceptables. Aborda las oportunidades de falla antes de que sucedan.

Escribe evaluaciones para probar los puntos de contacto de tu sistema con un modelo de lenguaje grande (LLM):

• Verifica que el modelo comprenda el propósito de tu herramienta, según su descripción y esquema.
• Verifica que el modelo elija la herramienta correcta con los parámetros correctos para admitir la intención del usuario.
• Confirma que el modelo está actuando sobre la información que recibió, por ejemplo, para usar información para llamar a otra herramienta.
• Verifica los recorridos del usuario exitosos. Dada la intención del usuario, ¿un agente puede completar correctamente el recorrido del usuario en mi sitio web con las herramientas proporcionadas?

Debes seguir escribiendo pruebas deterministas clásicas para cualquier interacción del sistema que no se comunique con el modelo.

Modos de falla

Los desarrolladores deben probar sus sistemas para evitar fallas antes de que sucedan. Para ello, debes comprender cuándo puede fallar el sistema, tanto por sí solo como cuando interactúa con factores externos. En el caso de WebMCP, la herramienta en sí puede fallar y los agentes pueden no usar las herramientas como se espera.

Las herramientas de WebMCP pueden fallar y cuando el agente puede fallar con las herramientas de WebMCP. Por ejemplo, supongamos que el usuario quiere agregar una camiseta a su carrito.

Con errores	Ejemplo	Solucionar problemas
El agente no selecciona la herramienta correcta o llama directamente a la herramienta incorrecta.	El agente omite addToCart y va directamente a checkout.	¿La description de la herramienta es clara, completa y refleja con precisión lo que hace la herramienta? ¿El functionName es intuitivo y descriptivo? ¿La herramienta está expuesta correctamente al LLM en el estado o contexto actual? ¿El esquema de esta herramienta es potencialmente demasiado similar a otra herramienta, lo que genera ambigüedad en la llamada?
El agente llama a las herramientas en el orden incorrecto	El agente llama a checkout y, luego, a addToCart.	¿Las descripciones de las herramientas se superponen, lo que confunde al LLM sobre la secuencia requerida? ¿El resultado de una herramienta anterior proporciona el contexto necesario para la siguiente llamada a la herramienta? ¿El estado se actualiza correctamente y las herramientas nuevas se exponen al LLM como se espera? ¿El caso de uso de extremo a extremo sigue siendo correcto si se llama a ciertas herramientas en un orden diferente? ¿Forzaste las llamadas anteriores para probar la cadena de llamadas a herramientas específicas de forma aislada para confirmar que el LLM elige el siguiente paso correcto?
El agente llama a la herramienta con argumentos incorrectos	El agente llama a addToCart, pero agrega zapatos en lugar de una camiseta.	¿El inputSchema está claramente definido, incluidos los valores enum y una buena description para cada propiedad? ¿Todos los parámetros obligatorios están marcados y verificados de forma explícita? ¿La descripción del argumento guía de forma explícita al LLM sobre cómo asignar la entrada del usuario a los datos estructurados esperados (como un ID o formato específico)?

¿Qué sucede si el usuario quiere verificar el contenido de su carrito?

Con errores	Ejemplo	Solucionar problemas
El resultado de la herramienta es incorrecto o la herramienta omite algo.	El usuario solicita viewCart, pero el agente muestra el costo total del carrito, en lugar de los nombres de los productos y los precios individuales.	¿La lógica de la herramienta subyacente tiene errores (verifica con pruebas deterministas)? ¿Se actualizó correctamente el estado de la IU y el agente recibió la información correcta sobre el efecto secundario? Si el LLM usa el resultado para llamadas posteriores, ¿el resultado tiene un formato claro para la ingesta de LLM? ¿El resultado es demasiado detallado? ¿Contiene solo la información esencial mínima que necesita el LLM para la siguiente acción?

Por último, una herramienta podría fallar de cualquier manera que falle JavaScript. Para solucionar el problema, investiga lo siguiente:

• ¿El código de la herramienta controla correctamente todos los errores y excepciones potenciales del entorno de ejecución?
• ¿El error se informa al agente y al modelo de forma correcta?
• ¿Las APIs o los servicios externos en los que se basa la herramienta son correctos?
• ¿La estructura de errores es lo suficientemente clara como para que el modelo pueda diferenciar entre un problema temporal (reintento) y una falla crítica?

Prueba herramientas de forma aislada

Si un agente no puede determinar qué herramienta llamar para una solicitud como "Quiero una pizza pequeña", no tendrá ninguna oportunidad en un recorrido del usuario complejo.

Si pruebas las herramientas de forma aislada, puedes optimizar tus esquemas y descripciones antes de ejecutar una simulación del navegador.

SUGERENCIA: Puedes activar una llamada a la herramienta WebMCP using navigator.modelContext.executeTool(...).

Mide la precisión de las llamadas

Echa un vistazo a nuestra demostración, el WebMCP zaMaker. Cuando el usuario solicita "Quiero una pizza pequeña", puedes esperar una respuesta del modelo que indique la intención de realizar una llamada set_pizza_size con el "size":"Small" argumento.

La función expectedCall define la función y el argumento esperados. Este enfoque confirma que el agente elegirá la herramienta correcta para admitir la intención del usuario, según el esquema proporcionado.

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

expectedCall se usa para realizar una prueba determinista basada en reglas:

Es posible vincular tus herramientas de WebMCP al ciclo de vida de un componente, lo que significa que debes probar cuándo el estado de tu aplicación coincide con lo que espera WebMCP. Para administrar esto, proporciona una lista completa de herramientas que sea pertinente para el estado que deseas evaluar. Por ejemplo, un usuario navega de forma conjunta con su agente y abre WebMCP zaMaker.

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

Al abrirse, WebMCP expone las herramientas add_topping, set_pizza_size y set_pizza_style. Para probar con precisión cualquiera de estas herramientas individuales, debes incluir todas las herramientas para crear un estado simulado y completo.

NOTA: Es posible que un agente tenga acceso a herramientas adicionales, pero lo mejor que puedes hacer es evaluar las herramientas que proporcionas.

Ahora que sabes que el agente llama a la herramienta correcta según sea necesario, puedes probar si la llamada a la herramienta tiene los parámetros correctos y si el resultado es el esperado. Hay dos pasos: pruebas deterministas y pruebas probabilísticas.

Ejecuta pruebas deterministas

Como las herramientas de WebMCP se compilan con JavaScript o como anotaciones HTML, puedes escribir pruebas deterministas para realizar las siguientes tareas:

• Verifica la lógica de la herramienta.
• Confirma que se llamó correctamente a las dependencias.
• Confirma que la interfaz de usuario se actualizó como se esperaba, junto con cualquier otro efecto secundario intencional.
• Verifica que la información que se muestra coincida con el valor esperado.
• Valida los parámetros de prueba.

Por ejemplo, si tu herramienta usa una función SearchComponent, puedes probarla pasando una simulación de SearchComponent. Recuerda simular el entorno en el que opera la herramienta para obtener los mejores resultados posibles. Esta es la misma técnica que usarías para escribir otra prueba de integración de aplicaciones.

Ejecuta pruebas probabilísticas

Si necesitas que un resultado del modelo llame correctamente a las siguientes herramientas, debes escribir evaluaciones.

Es posible que los usuarios envíen consultas directas al modelo que soliciten específicamente lo que hace la herramienta o una consulta ambigua que implique que se debe usar una herramienta. Por ejemplo, "Agrega pepperoni a mi pizza" es una consulta directa. "Quiero toda la carne en mi pizza" es más ambiguo y requiere que el modelo comprenda que necesita la herramienta add_topping y cuál de los ingredientes se podría definir como carne.

Cuando crees conjuntos de datos para tus evaluaciones, incluye consultas directas que prueben la ejecución de la herramienta de referencia y consultas abiertas que prueben el razonamiento del modelo y la lógica de selección de herramientas.

Si tienes una cafetería, puedes admitir a los usuarios que le piden a su agente que vuelva a pedir el mismo café que pidieron el mes pasado. Escribe una herramienta para buscar pedidos anteriores, OrderHistoryService, y otra para pedir el café. Para probar el servicio de historial de pedidos, puedes enviar una simulación que muestre un ID de producto de café.

En este ejemplo, evalúas si el modelo comprende la intención de la consulta, elige la herramienta correcta y si esa herramienta proporciona la información correcta para tomar medidas. Si el modelo no llama a get_order_history, no sabrá qué item_id usar para order_product.

Pruebas de extremo a extremo

Escribe pruebas de extremo a extremo para asegurarte de que los usuarios y sus agentes puedan completar sus recorridos correctamente. Además de probar las herramientas individuales, también pruebas que las acciones de varios pasos se realicen en el orden correcto.

Por ejemplo, tienes una tienda de ropa en línea. Un usuario le pregunta a su agente: "Quiero comprar una chaqueta negra y un par de jeans. ¿Podrías proporcionar un desglose de los materiales utilizados?".

Un recorrido de agente exitoso podría verse de la siguiente manera:

1. Navega a la categoría de ropa.
2. Busca uno de los artículos de ropa solicitados (el orden no es importante).
3. Busca un artículo específico (search_clothes).
4. Obtén los detalles del producto que contienen la lista de materiales (get_product_details).
5. Repite los pasos 2 a 4 para cada elemento solicitado.

Cuando el agente llega al paso 2, puede buscar primero la chaqueta negra o los jeans, el orden no es importante. Sin embargo, se debe seguir el resto de los pasos de forma secuencial.

Escribe una evaluación de extremo a extremo para verificar que el agente llame a las herramientas en el orden esperado:

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

Evalúa las fallas de la cadena media

Es posible que un agente deba llamar a varias herramientas de forma secuencial. ¿Qué sucede si una herramienta falla en medio de este proceso? Por ejemplo, un usuario quiere pedir una pizza con su código de cupón:

"Quiero una pizza pequeña de pesto. Usa mi código promocional, FreePizza".

Es posible que el agente falle en add_discount_coupon y continúe con el proceso de confirmación de la compra de una pizza a precio completo. Para probar la herramienta add_discount_coupon, puedes ejecutar manualmente esta secuencia de llamadas a herramientas, sin interactuar con un modelo, para simular esta situación. Lleva tu aplicación al estado en el que prevés que falle la herramienta. En este caso, es después de la herramienta start_checkout. Luego, puedes evaluar add_discount_coupon de forma aislada.

Experimenta con WebMCP

Comienza a experimentar con evaluaciones para herramientas de forma aislada y a evaluar tus propios sitios habilitados para WebMCP con cualquier agente compatible con WebMCP:

• Descarga nuestras herramientas de evaluación experimentales en GitHub.
• Revisa nuestro curso, Crea evaluaciones de IA.