Teste o WebMCP com avaliações

Kasper Kulikowski

Publicado em 19 de maio de 2026, atualizado em 28 de maio de 2026

Vídeo explicativo	Web	Extensões	Status do Chrome	Intenção
GitHub	Teste de origem		Ver	Intenção de experimentar

O WebMCP oferece suporte a agentes que usam modelos de IA generativa. Para testar qualquer sistema usando IA generativa, seus testes precisam oferecer suporte a resultados probabilísticos: uma entrada pode levar a milhares de respostas com graus variados de precisão. Essa técnica de teste é chamada de avaliações ou evals.

Antes de lançar ferramentas na produção, confirme se os agentes entendem quando chamar a ferramenta, como executá-la e quais respostas são aceitáveis. Aborde as oportunidades de falha antes que elas aconteçam.

Escreva avaliações para testar os pontos de contato do sistema com um modelo de linguagem grande (LLM):

• Verifique se o modelo entende a finalidade da ferramenta com base na descrição e no esquema.
• Verifique se o modelo escolhe a ferramenta certa com os parâmetros corretos para oferecer suporte à intenção do usuário.
• Confirme se o modelo está agindo com base nas informações recebidas, por exemplo, para usar informações para chamar outra ferramenta.
• Verifique as jornadas do usuário bem-sucedidas. Considerando a intenção do usuário, um agente pode concluir a jornada do usuário no meu site com as ferramentas fornecidas?

Continue escrevendo testes determinísticos clássicos para qualquer interação do sistema que não se comunique com o modelo.

Modos de falha

Os desenvolvedores precisam testar os sistemas para evitar falhas antes que elas aconteçam. Para isso, é necessário entender quando o sistema pode falhar, tanto por conta própria quanto ao interagir com fatores externos. Para o WebMCP, a ferramenta em si pode falhar, e os agentes podem não usar as ferramentas conforme o esperado.

As ferramentas do WebMCP podem falhar e quando o agente pode falhar com as ferramentas do WebMCP. Por exemplo, digamos que o usuário queira adicionar uma camiseta ao carrinho.

Falha	Exemplo	Resolver problemas
O agente não consegue selecionar a ferramenta correta ou chama diretamente a ferramenta errada.	O agente pula addToCart e vai direto para checkout.	A description da ferramenta é clara, completa e reflete com precisão o que a ferramenta faz? O functionName é intuitivo e descritivo? A ferramenta está exposta corretamente ao LLM no estado/contexto atual? O esquema dessa ferramenta é potencialmente muito semelhante a outra ferramenta, levando à ambiguidade de chamada?
O agente chama ferramentas na ordem errada	O agente chama checkout e depois addToCart.	As descrições das ferramentas se sobrepõem, confundindo o LLM sobre a sequência necessária? A saída de uma ferramenta anterior fornece o contexto necessário para a próxima chamada de ferramenta? O estado é atualizado corretamente e todas as novas ferramentas são expostas ao LLM conforme o esperado? O caso de uso de ponta a ponta ainda está correto se determinadas ferramentas forem chamadas em uma ordem diferente? Você testou a cadeia de chamadas de ferramentas específicas de forma isolada, forçando as chamadas anteriores a confirmar se o LLM escolhe a próxima etapa correta?
O agente chama a ferramenta com argumentos incorretos	O agente chama addToCart, mas adiciona sapatos em vez de uma camiseta.	O inputSchema está claramente definido, incluindo valores enum e uma boa description para cada propriedade? Todos os parâmetros obrigatórios estão marcados e verificados explicitamente? A descrição do argumento orienta explicitamente o LLM sobre como mapear a entrada do usuário para os dados estruturados esperados (como um ID ou formato específico)?

E se o usuário quiser verificar o que está no carrinho?

Falha	Exemplo	Resolver problemas
A saída da ferramenta está incorreta ou a ferramenta perde algo.	O usuário pede para viewCart, mas o agente gera o custo total do carrinho, em vez dos nomes dos produtos e dos preços individuais.	A lógica da ferramenta subjacente tem bugs (verifique com testes determinísticos)? O estado da interface foi atualizado corretamente e o agente recebeu as informações certas sobre o efeito colateral? Se a saída for usada pelo LLM para chamadas subsequentes, ela será formatada claramente para ingestão do LLM? A saída é muito detalhada? Ela contém apenas as informações essenciais mínimas de que o LLM precisa para a próxima ação?

Por fim, uma ferramenta pode falhar de qualquer maneira que o JavaScript falhe. Para resolver problemas, investigue o seguinte:

• O código da ferramenta processa corretamente todos os possíveis erros e exceções de tempo de execução?
• O erro é informado ao agente e ao modelo de maneira adequada?
• As APIs ou serviços externos em que a ferramenta se baseia são íntegros?
• A estrutura de erros é clara o suficiente para que o modelo possa diferenciar entre um problema temporário (repetir) e uma falha crítica?

Ferramentas de teste isoladas

Se um agente não conseguir descobrir qual ferramenta chamar para uma solicitação como "Eu gostaria de uma pizza pequena", ele não terá chance em uma jornada complexa do usuário.

Ao testar ferramentas isoladamente, é possível otimizar seus esquemas e descrições antes de executar uma simulação de navegador.

Medir a precisão da chamada

Confira nossa demonstração, o WebMCP zaMaker. Quando o usuário solicita "Eu gostaria de uma pizza pequena", você pode esperar uma resposta do modelo indicando a intenção de fazer uma chamada set_pizza_size com o "size":"Small" argumento.

A função expectedCall define a função e o argumento esperados. Essa abordagem confirma que o agente vai escolher a ferramenta correta para oferecer suporte à intenção do usuário, com base no esquema fornecido.

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

expectedCall é usado para realizar um teste determinístico baseado em regras:

É possível vincular as ferramentas do WebMCP ao ciclo de vida de um componente, o que significa que você precisa testar quando o estado do aplicativo corresponde ao que o WebMCP espera. Para gerenciar isso, forneça uma lista completa de ferramentas relevantes para o estado que você quer avaliar. Por exemplo, um usuário está navegando em conjunto com o agente e abre o zaMaker do WebMCP.

[
...
  {
    "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" }
   }
 ]
...

Ao abrir, o WebMCP expõe as ferramentas add_topping, set_pizza_size e set_pizza_style. Para testar com precisão qualquer uma dessas ferramentas individuais, inclua todas as ferramentas para criar um estado simulado e completo.

OBSERVAÇÃO: um agente pode ter acesso a outras ferramentas, mas o melhor que você pode fazer é avaliar as ferramentas fornecidas.

Agora que você sabe que o agente chama a ferramenta certa conforme necessário, é possível testar se a chamada de ferramenta tem os parâmetros corretos e se o resultado é o esperado. Há duas etapas: testes determinísticos e testes probabilísticos.

Executar testes determinísticos

Como as ferramentas do WebMCP são criadas com JavaScript ou como anotações HTML, é possível escrever testes determinísticos para realizar as seguintes tarefas:

• Verificar a lógica da ferramenta.
• Confirmar se as dependências foram chamadas corretamente.
• Confirmar se a interface do usuário foi atualizada conforme o esperado, juntamente com outros efeitos colaterais intencionais.
• Verificar se as informações retornadas correspondem ao valor esperado.
• Validar parâmetros de teste.

Por exemplo, se a ferramenta usar uma função SearchComponent, você poderá testar transmitindo uma simulação de SearchComponent. Lembre-se de simular o ambiente em que a ferramenta está operando para receber os melhores resultados possíveis. Essa é a mesma técnica que você usaria para escrever outro teste de integração de aplicativos.

Executar testes probabilísticos

Se você precisar de uma saída de modelo para chamar corretamente as próximas ferramentas, será necessário escrever evals.

É possível que os usuários façam consultas diretas ao modelo que pedem especificamente o que a ferramenta faz ou uma consulta ambígua que implica que uma ferramenta precisa ser usada. Por exemplo, "Adicionar pepperoni à minha pizza" é uma consulta direta. "Quero toda a carne na minha pizza" é mais ambígua e exige que o modelo entenda que ele precisa da ferramenta add_topping e quais coberturas podem ser definidas como carne.

Ao criar conjuntos de dados para suas evals, inclua consultas diretas que testam a execução da ferramenta de linha de base e consultas abertas que testam o raciocínio do modelo e a lógica de seleção de ferramentas.

Se você tiver uma cafeteria, poderá oferecer suporte a usuários que pedem ao agente para refazer o mesmo café que pediram no mês passado. Escreva uma ferramenta para pesquisar pedidos anteriores, OrderHistoryService, e outra para pedir o café. Para testar o serviço de histórico de pedidos, você pode enviar uma simulação que retorna um ID de produto de café.

Neste exemplo, você avalia se o modelo entende a intenção da consulta, escolhe a ferramenta certa e se essa ferramenta fornece as informações corretas para agir. Se o modelo não chamar get_order_history, ele não saberá qual item_id usar para order_product.

Testes de ponta a ponta

Escreva testes de ponta a ponta para garantir que os usuários e os agentes possam concluir as jornadas com sucesso. Além de testar as ferramentas individuais, você também está testando se as ações de várias etapas são realizadas na ordem correta.

Por exemplo, você tem uma loja de roupas on-line. Um usuário pergunta ao agente: "Quero comprar uma jaqueta preta e uma calça jeans. Você pode fornecer um detalhamento dos materiais usados?

Uma jornada de agente bem-sucedida pode ser assim:

1. Navegue até a categoria de roupas.
2. Encontre um dos itens de vestuário solicitados (a ordem não é importante).
3. Encontre o item específico (search_clothes).
4. Receba os detalhes do produto que contêm a lista de materiais (get_product_details).
5. Repita as etapas 2 a 4 para cada item solicitado.

Quando o agente chegar à etapa 2, ele poderá pesquisar primeiro a jaqueta preta ou o jeans. A ordem não é importante. No entanto, as demais etapas precisam ser seguidas sequencialmente.

Escreva uma eval de ponta a ponta para verificar se o agente chama ferramentas na ordem esperada:

{
  "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" }
            }
          ]
        }
      ]
    }
  ]
}

Avaliar falhas no meio da cadeia

Pode haver momentos em que um agente precisa chamar várias ferramentas sequencialmente. O que acontece se uma ferramenta falhar no meio desse processo? Por exemplo, um usuário quer pedir uma pizza com o código do cupom:

"Eu gostaria de uma pizza pequena de pesto. Use meu código promocional, FreePizza."

É possível que o agente falhe no add_discount_coupon e prossiga para o checkout de uma pizza com preço total. Para testar a ferramenta add_discount_coupon, você pode executar manualmente essa sequência de chamadas de ferramentas, sem interagir com um modelo, para simular esse cenário. Coloque o aplicativo no estado em que você prevê que a ferramenta falhe. Nesse caso, é depois da ferramenta start_checkout. Em seguida, você pode avaliar o add_discount_coupon isoladamente.

Experimentar com o WebMCP

Comece a experimentar com evals para ferramentas isoladamente e avalie seus próprios sites ativados para WebMCP com qualquer agente compatível com WebMCP:

• Faça o download das nossas ferramentas de avaliação experimental no GitHub.
• Confira nosso curso Criar avaliações de IA.