Evaluaciones para WebMCP

Kasper Kulikowski

Fecha de publicación: 19 de mayo de 2026. Última actualización: 28 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 diferentes grados de precisión. Esta técnica de prueba se denomina evaluaciones o evals.

Antes de lanzar herramientas en 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 adecuada con los parámetros correctos para satisfacer la intención del usuario.
• Confirma que el modelo está actuando en función de la información que recibió, por ejemplo, para usar información y llamar a otra herramienta.
• Verifica que los recorridos del usuario sean exitosos. Dado el propósito del usuario, ¿puede un agente completar con éxito el recorrido del usuario en mi sitio web con las herramientas proporcionadas?

Debes seguir escribiendo pruebas determinísticas 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 ocurran. Para ello, debes comprender cuándo puede fallar el sistema, tanto por sí solo como en su interacción con factores externos. En el caso de WebMCP, es posible que la herramienta en sí falle y que los agentes no puedan usar las herramientas según lo previsto.

Las herramientas de WebMCP pueden fallar, y el agente también puede fallar con ellas. 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 se expone correctamente al LLM en el estado o contexto actual? ¿El esquema de esta herramienta es potencialmente demasiado similar al de 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 y confunden 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 según lo previsto? ¿El caso de uso de extremo a extremo sigue siendo correcto si se llama a ciertas herramientas en un orden diferente? ¿Probaste la cadena de llamadas a herramientas específica de forma aislada forzando las llamadas anteriores 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 de enum y un buen 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 qué hay en su carrito?

Con errores	Ejemplo	Solucionar problemas
La respuesta de la herramienta es incorrecta o le falta algo.	El usuario pide 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 (verificar con pruebas determinísticas)? ¿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 está formateado de forma clara para la incorporación del LLM? ¿El resultado es demasiado detallado? ¿Contiene solo la información esencial mínima que el LLM necesita para la próxima acción?

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

• ¿El código de la herramienta controla correctamente todos los posibles errores y excepciones del entorno de ejecución?
• ¿El error se informa al agente y al modelo de forma ordenada?
• ¿Las APIs o los servicios externos de los que depende la herramienta están en buen estado?
• ¿La estructura del error 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 posibilidad 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.

Cómo medir la precisión de las llamadas

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

La función expectedCall define la función y el argumento esperados. Este enfoque confirma que el agente elegirá la herramienta correcta para respaldar 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 realizar pruebas cuando el estado de tu aplicación coincida 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 está navegando junto 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" }
   }
 ]
...

Cuando se abre, 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 determinísticas y pruebas probabilísticas.

Ejecuta pruebas determinísticas

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

• Verifica la lógica de la herramienta.
• Confirma que las dependencias se llamaron correctamente.
• Confirma que la interfaz de usuario se actualizó según lo esperado, junto con cualquier otro efecto secundario intencional.
• Verifica que la información devuelta coincida con el valor esperado.
• Valida los parámetros de prueba.

Por ejemplo, si tu herramienta usa una función SearchComponent, puedes pasar una simulación de SearchComponent para realizar la prueba. 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 la aplicación.

Ejecuta pruebas probabilísticas

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

Los usuarios pueden hacerle consultas directas al modelo en las que pregunten específicamente qué hace la herramienta, o bien consultas ambiguas que impliquen que se debe usar una herramienta. Por ejemplo, "Agrega pepperoni a mi pizza" es una búsqueda 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áles de los ingredientes se podrían definir como carne.

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

Si tienes una cafetería, podrías ayudar 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 devuelva un ID de producto de café.

En este ejemplo, evaluarás si el modelo comprende la intención de la búsqueda, elige la herramienta adecuada 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 tener la certeza de que los usuarios y sus agentes pueden 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 exitoso del agente podría verse de la siguiente manera:

1. Navega a la categoría de ropa.
2. Encuentra una de las prendas solicitadas (el orden no es importante).
3. Encuentra un elemento específico (search_clothes).
4. Obtén los detalles del producto que contienen la lista de materiales (get_product_details).
5. Repite los pasos del 2 al 4 para cada elemento solicitado.

Cuando el agente llega al paso 2, podría buscar la primera camisa negra o los jeans. El orden no es importante. Sin embargo, el resto de los pasos se deben seguir 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 a mitad de la cadena

Puede haber ocasiones en las 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:

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

Es posible que el agente falle en add_discount_coupon y proceda a pagar 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 este caso. Lleva tu aplicación al estado en el que prevés que la herramienta fallará. En este caso, es después de la herramienta start_checkout. Luego, puedes evaluar el add_discount_coupon de forma aislada.

Experimenta con WebMCP

Comienza a experimentar con las evaluaciones de 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.