Valutazioni per WebMCP

Kasper Kulikowski

Pubblicato il 19 maggio 2026, ultimo aggiornamento il 28 maggio 2026

WebMCP supporta gli agenti che utilizzano modelli di AI generativa. Per testare qualsiasi sistema che utilizza l'AI generativa, i test devono supportare risultati probabilistici: un input potrebbe portare a migliaia di risposte con diversi gradi di accuratezza. Questa tecnica di test è chiamata valutazioni o evals.

Prima di rilasciare gli strumenti in produzione, devi verificare che gli agenti capiscano quando chiamare lo strumento, come eseguirlo e quali risposte sono accettabili. Affronta le opportunità di errore prima che si verifichino.

Scrivi valutazioni per testare i punti di contatto del tuo sistema con un modello linguistico di grandi dimensioni (LLM):

• Verifica che il modello comprenda lo scopo dello strumento in base alla sua descrizione e allo schema.
• Verifica che il modello scelga lo strumento giusto con i parametri corretti per supportare l'intento dell'utente.
• Verifica che il modello agisca in base alle informazioni ricevute, ad esempio per utilizzare le informazioni per chiamare un altro strumento.
• Verifica che i percorsi utente siano completati correttamente. Dato l'intento dell'utente, un agente può completare correttamente il percorso utente sul mio sito web con gli strumenti forniti?

Dovresti continuare a scrivere test deterministici classici per qualsiasi interazione di sistema che non comunichi con il modello.

Modalità di errore

Gli sviluppatori devono testare i propri sistemi per evitare errori prima che si verifichino. Per farlo, devi capire quando il sistema potrebbe non funzionare, sia da solo sia interagendo con fattori esterni. Per WebMCP, lo strumento stesso potrebbe non funzionare e gli agenti potrebbero non utilizzare gli strumenti come previsto.

Gli strumenti WebMCP potrebbero non funzionare e l'agente potrebbe non funzionare con gli strumenti WebMCP. Supponiamo, ad esempio, che l'utente voglia aggiungere una t-shirt al carrello.

Operazione non riuscita	Esempio	Risoluzione dei problemi
L'agente non riesce a selezionare lo strumento corretto o chiama direttamente lo strumento sbagliato.	L'agente salta addToCart e va direttamente a checkout.	La description dello strumento è chiara, completa e riflette accuratamente ciò che fa lo strumento? Il functionName è intuitivo e descrittivo? Lo strumento è esposto correttamente all'LLM nello stato/contesto attuale? Lo schema di questo strumento è potenzialmente troppo simile a un altro strumento, il che porta all'ambiguità della chiamata?
L'agente chiama gli strumenti nell'ordine sbagliato	L'agente chiama checkout e poi addToCart.	Le descrizioni degli strumenti si sovrappongono, confondendo l'LLM sulla sequenza richiesta? L'output di uno strumento precedente fornisce il contesto necessario per la chiamata dello strumento successivo? Lo stato viene aggiornato correttamente e tutti i nuovi strumenti vengono esposti all'LLM come previsto? Il caso d'uso end-to-end è ancora corretto se alcuni strumenti vengono chiamati in un ordine diverso? Hai testato la catena di chiamate di strumenti specifica in isolamento forzando le chiamate precedenti per verificare che l'LLM scelga il passaggio successivo corretto?
L'agente chiama lo strumento con argomenti errati	L'agente chiama addToCart, ma aggiunge scarpe anziché una t-shirt.	L'inputSchema è definito chiaramente, inclusi i valori enum e una buona description per ogni proprietà? Tutti i parametri obbligatori sono contrassegnati e controllati in modo esplicito? La descrizione dell'argomento guida in modo esplicito l'LLM su come mappare l'input dell'utente ai dati strutturati previsti (ad esempio un ID o un formato specifico)?

Cosa succede se l'utente vuole controllare cosa c'è nel carrello?

Operazione non riuscita	Esempio	Risoluzione dei problemi
L'output dello strumento non è corretto o lo strumento non rileva qualcosa.	L'utente chiede di viewCart, ma l'agente restituisce il costo totale del carrello anziché i nomi dei prodotti e i prezzi individuali.	La logica dello strumento sottostante presenta bug (verifica con test deterministici)? Lo stato dell'interfaccia utente è stato aggiornato correttamente e l'agente ha ricevuto le informazioni corrette sull'effetto collaterale? Se l'output viene utilizzato dall'LLM per le chiamate successive, l'output è formattato in modo chiaro per l'inserimento dell'LLM? L'output è eccessivamente dettagliato? Contiene solo le informazioni essenziali minime di cui l'LLM ha bisogno per l'azione successiva?

Infine, uno strumento potrebbe non funzionare in qualsiasi modo in cui JavaScript non funziona. Per risolvere il problema, esamina quanto segue:

• Il codice dello strumento gestisce correttamente tutti i potenziali errori di runtime ed eccezioni?
• L'errore viene segnalato all'agente e al modello in modo corretto?
• Le API o i servizi esterni su cui si basa lo strumento sono integri?
• La struttura degli errori è sufficientemente chiara da consentire al modello di distinguere tra un problema temporaneo (riprova) e un errore critico?

Testare gli strumenti in isolamento

Se un agente non riesce a capire quale strumento chiamare per una richiesta come "Vorrei una pizza piccola", non avrà alcuna possibilità in un percorso utente complesso.

Testando gli strumenti in isolamento, puoi ottimizzare gli schemi e le descrizioni prima di eseguire una simulazione del browser.

Misurare l'accuratezza delle chiamate

Dai un'occhiata alla nostra demo, the WebMCP zaMaker. Quando l'utente chiede "Vorrei una pizza piccola", puoi aspettarti una risposta del modello che indichi l'intenzione di eseguire una chiamata set_pizza_size con l' "size":"Small" argomento.

La funzione expectedCall definisce la funzione e l'argomento previsti. Questo approccio conferma che l'agente sceglierà lo strumento corretto per supportare l'intento dell'utente, in base allo schema fornito.

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

expectedCall viene utilizzato per eseguire un test deterministico basato su regole:

È possibile collegare gli strumenti WebMCP al ciclo di vita di un componente, il che significa che devi testare quando lo stato dell'applicazione corrisponde a quello previsto da WebMCP. Per gestire questa operazione, fornisci un elenco completo di strumenti pertinenti allo stato che vuoi valutare. Ad esempio, un utente sta navigando insieme al suo agente e apre 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" }
   }
 ]
...

All'apertura, WebMCP espone gli strumenti add_topping, set_pizza_size e set_pizza_style. Per testare con precisione uno di questi singoli strumenti, devi includerli tutti per creare uno stato simulato e completo.

NOTA: un agente potrebbe avere accesso a strumenti aggiuntivi, ma la cosa migliore che puoi fare è valutare gli strumenti che fornisci.

Ora che sai che l'agente chiama lo strumento giusto in base alle esigenze, puoi verificare se la chiamata dello strumento ha i parametri corretti e se il risultato è quello previsto. Esistono due passaggi: test deterministici e test probabilistici.

Eseguire test deterministici

Poiché gli strumenti WebMCP sono creati con JavaScript o come annotazioni HTML, puoi scrivere test deterministici per eseguire le seguenti attività:

• Verificare la logica dello strumento.
• Verificare che le dipendenze siano state chiamate correttamente.
• Verificare che l'interfaccia utente sia stata aggiornata come previsto, insieme a eventuali altri effetti collaterali intenzionali.
• Verificare che le informazioni restituite corrispondano al valore previsto.
• Convalidare i parametri di test.

Ad esempio, se lo strumento utilizza una funzione SearchComponent, puoi eseguire il test passando un mock di SearchComponent. Ricorda di simulare l'ambiente in cui opera lo strumento per ottenere i migliori risultati possibili. Questa è la stessa tecnica che useresti per scrivere un altro test di integrazione dell'applicazione.

Eseguire test probabilistici

Se è necessario che un output del modello chiami correttamente gli strumenti successivi, devi scrivere le valutazioni.

È possibile che gli utenti forniscano query dirette al modello che chiedono in modo specifico cosa fa lo strumento o una query ambigua che implica che deve essere utilizzato uno strumento. Ad esempio, "Aggiungi il salame piccante alla mia pizza" è una query diretta. "Voglio tutta la carne sulla mia pizza" è più ambiguo e richiede che il modello comprenda che ha bisogno dello strumento add_topping e quali dei condimenti potrebbero essere definiti carne.

Quando crei set di dati per le tue valutazioni, includi sia query dirette che testano l'esecuzione di base degli strumenti sia query aperte che testano la logica di ragionamento e selezione degli strumenti del modello.

Se gestisci una caffetteria, puoi supportare gli utenti che chiedono al loro agente di riordinare lo stesso caffè che hanno ordinato il mese scorso. Scrivi uno strumento per cercare gli ordini precedenti, OrderHistoryService, e un altro per ordinare il caffè. Per testare il servizio di cronologia degli ordini, puoi inviare un mock che restituisce un ID prodotto di caffè.

In questo esempio, valuti se il modello comprende l'intento della query, sceglie lo strumento giusto e se questo strumento fornisce le informazioni corrette per intraprendere un'azione. Se il modello non chiama get_order_history, non saprà quale item_id utilizzare per order_product.

Test end-to-end

Scrivi test end-to-end per assicurarti che gli utenti e i loro agenti possano completare correttamente i loro percorsi. Oltre a testare i singoli strumenti, stai anche testando che le azioni in più passaggi vengano eseguite nell'ordine corretto.

Ad esempio, gestisci un negozio di abbigliamento online. Un utente chiede al suo agente: "Sto cercando di acquistare una giacca nera e un paio di jeans. Potresti fornirmi un'analisi dei materiali utilizzati?"

Un percorso di agenti di successo potrebbe essere il seguente:

1. Vai alla categoria di abbigliamento.
2. Trova uno degli articoli di abbigliamento richiesti (l'ordine non è importante).
3. Trova l'articolo specifico (search_clothes).
4. Ottieni i dettagli del prodotto che contengono l'elenco dei materiali (get_product_details).
5. Ripeti i passaggi da 2 a 4 per ogni articolo richiesto.

Quando l'agente raggiunge il passaggio 2, potrebbe cercare prima la giacca nera o i jeans, l'ordine non è importante. Tuttavia, il resto dei passaggi deve essere seguito in sequenza.

Scrivi una valutazione end-to-end per verificare che l'agente chiami gli strumenti nell'ordine previsto:

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

Valutare gli errori a metà catena

A volte un agente deve chiamare più strumenti in sequenza. Cosa succede se uno strumento non funziona nel mezzo di questa procedura? Ad esempio, un utente vuole ordinare una pizza con il suo codice coupon:

"Vorrei una pizza piccola al pesto. Utilizza il mio codice promozionale, FreePizza."

È possibile che l'agente non riesca a eseguire add_discount_coupon e proceda al pagamento per una pizza a prezzo pieno. Per testare lo strumento add_discount_coupon, puoi eseguire manualmente questa sequenza di chiamate di strumenti, senza interagire con un modello, per simulare questo scenario. Porta l'applicazione allo stato in cui prevedi che lo strumento non funzioni. In questo caso, dopo lo strumento start_checkout. Poi, puoi valutare add_discount_coupon in isolamento.

Sperimentare con WebMCP

Inizia a sperimentare con le valutazioni per gli strumenti in isolamento e a valutare i tuoi siti abilitati a WebMCP con qualsiasi agente compatibile con WebMCP:

• Scarica i nostri strumenti di valutazione sperimentali su GitHub.
• Consulta il nostro corso Creare valutazioni AI.