Valutazioni per WebMCP

Kasper Kulikowski

Pubblicato: 19 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.

Prima di rilasciare gli strumenti in produzione, devi assicurarti che gli agenti sappiano 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 descrizione e allo schema.
• Verifica che il modello scelga lo strumento giusto con i parametri corretti per supportare l'intent dell'utente.
• Verifica che il modello agisca in base alle informazioni ricevute, ad esempio per utilizzare le informazioni per chiamare un altro strumento.
• Verifica i percorsi utente riusciti. Data l'intenzione dell'utente, un agente può completare correttamente il percorso dell'utente sul mio sito web con gli strumenti forniti?

Devi continuare a scrivere test deterministici classici per qualsiasi interazione di sistema che non comunica 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 in interazione con fattori esterni. Per WebMCP, lo strumento stesso potrebbe non funzionare e gli agenti potrebbero non riuscire a utilizzarlo come previsto.

Gli strumenti WebMCP potrebbero non funzionare e l'agente potrebbe non funzionare con gli strumenti WebMCP. Ad esempio, supponiamo che l'utente voglia aggiungere una maglietta al carrello.

Operazione non riuscita	Esempio	Risoluzione dei problemi
L'agente non seleziona lo strumento corretto o chiama direttamente quello sbagliato.	L'agente salta addToCart e va direttamente a checkout.	La description dello strumento è chiara, completa e riflette con precisione le funzionalità dello strumento? Il functionName è intuitivo e descrittivo? Lo strumento è esposto correttamente al modello LLM nello stato/contesto attuale? Lo schema di questo strumento è potenzialmente troppo simile a un altro strumento, il che porta ad ambiguità nella 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 allo strumento successivo? Lo stato è aggiornato correttamente e i nuovi strumenti sono esposti all'LLM come previsto? Lo scenario d'uso end-to-end è ancora corretto se determinati strumenti vengono chiamati in un ordine diverso? Hai testato la catena di chiamate di strumenti specifica in isolamento forzando le chiamate precedenti per confermare che l'LLM sceglie il passaggio successivo corretto?
L'agente chiama lo strumento con argomenti non corretti	L'agente chiama addToCart, ma aggiunge delle scarpe anziché una t-shirt.	Il inputSchema è definito chiaramente, inclusi i valori enum e un buon description per ogni proprietà? Tutti i parametri obbligatori sono contrassegnati e selezionati in modo esplicito? La descrizione dell'argomento guida esplicitamente 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 della UI è stato aggiornato correttamente e l'agente ha ricevuto le informazioni corrette sull'effetto collaterale? Se l'output viene utilizzato dall'LLM per chiamate successive, è formattato in modo chiaro per l'inserimento nell'LLM? L'output è eccessivamente prolisso? Contiene solo le informazioni essenziali minime necessarie al LLM per l'azione successiva?

Infine, uno strumento potrebbe 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 e le eccezioni di runtime?
• L'errore viene segnalato all'agente e al modello in modo controllato?
• Le API o i servizi esterni su cui si basa lo strumento sono integri?
• La struttura dell'errore è abbastanza chiara da consentire al modello di distinguere tra un problema temporaneo (riprova) e un errore critico?

Testare gli strumenti in modo isolato

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 dell'utente complesso.

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

SUGGERIMENTO: puoi attivare una chiamata allo strumento WebMCP using navigator.modelContext.executeTool(...).

Misurare l'accuratezza delle chiamate

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

La funzione expectedCall definisce la funzione e l'argomento previsti. Questo approccio conferma che l'agente sceglierà lo strumento corretto per supportare l'intent 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 eseguire il test quando lo stato dell'applicazione corrisponde a quello previsto da WebMCP. Per gestire questo aspetto, fornisci un elenco completo degli 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 necessità, puoi verificare se la chiamata allo strumento ha i parametri corretti e se il risultato è quello previsto. Esistono due passaggi: test deterministici e test probabilistici.

Esegui test deterministici

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

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

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

Esegui test probabilistici

Se hai bisogno di un output del modello per chiamare correttamente gli strumenti successivi, devi scrivere evals.

È possibile che gli utenti inviino query dirette al modello che chiedono specificamente cosa fa lo strumento o una query ambigua che implica l'utilizzo di uno strumento. Ad esempio, "Aggiungi il salame piccante alla mia pizza" è una query diretta. "Voglio tutta la carne sulla mia pizza" è più ambigua e richiede al modello di capire che ha bisogno dello strumento add_topping e quali condimenti potrebbero essere definiti carne.

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

Se gestisci una caffetteria, potresti supportare gli utenti che chiedono al loro agente di riordinare lo stesso caffè 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 ordini, puoi inviare una simulazione che restituisce un ID prodotto di caffè.

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

Test end-to-end

Scrivi test end-to-end per avere la certezza che gli utenti e i loro agenti possano completare i loro percorsi senza problemi. Oltre a testare i singoli strumenti, verifichi anche 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: "Vorrei comprare una giacca nera e un paio di jeans. Potresti fornire un elenco dettagliato dei materiali utilizzati?

Un percorso di acquisto con l'agente potrebbe essere simile al seguente:

1. Vai alla categoria Abbigliamento.
2. Trova uno dei capi di abbigliamento richiesti (l'ordine non è importante).
3. Trova un elemento specifico (search_clothes).
4. Recupera i dettagli del prodotto che contengono l'elenco dei materiali (get_product_details).
5. Ripeti i passaggi 2-4 per ogni elemento richiesto.

Quando l'agente raggiunge il passaggio 2, può cercare prima la camicia nera o i jeans, l'ordine non è importante. Tuttavia, i passaggi rimanenti devono essere seguiti 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" }
            }
          ]
        }
      ]
    }
  ]
}

Valuta gli errori a metà catena

Potrebbero esserci momenti in cui un agente deve chiamare più strumenti in sequenza. Cosa succede se uno strumento non funziona a metà di questo processo? Ad esempio, un utente vuole ordinare una pizza con il suo codice coupon:

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

È possibile che l'agente non riesca a completare l'operazione al add_discount_coupon e proceda al pagamento di una pizza a prezzo pieno. Per testare lo strumento add_discount_coupon, puoi eseguire manualmente questa sequenza di chiamate allo strumento, 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. A questo punto, puoi valutare add_discount_coupon in isolamento.

Sperimenta 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 sperimentale su GitHub.
• Consulta il nostro corso Crea valutazioni dell'AI.