Dal listing dei tool all’analisi della console, fino al debug via CLI: un approccio ripetibile per rendere affidabili i comandi MCP che pilotano il browser.
Quando inizi a usare tool WebMCP per pilotare un sito (o un’app) via agente, la domanda non è se avrai bisogno di debug, ma quanto presto. L’integrazione tra Chrome DevTools for Agents e un client MCP ti permette di fare una cosa molto concreta: collegarti a un browser reale, eseguire tool uno dopo l’altro e, quando qualcosa va storto, leggere l’errore dove serve davvero—nella console e nei segnali runtime del browser.
Di seguito un flusso pratico e ripetibile, basato su un esempio volutamente semplice (una “pizza builder UI”) ma applicabile a qualunque set di tool MCP che interagisce con la pagina.
1) Collegati al browser e verifica l’ambiente di esecuzione
Il primo passo è lavorare su un browser in esecuzione (spesso una build Canary o un profilo dedicato) così da poter:
- collegarti in modo deterministico alla sessione;
- ispezionare console, network e runtime;
- riprodurre bug senza “sporcare” l’ambiente principale.
In questa fase l’obiettivo non è ancora “fare cose”, ma assicurarti che la connessione al browser sia stabile e che il client MCP veda l’istanza corretta.
2) Elenca i tool WebMCP disponibili (sanity check)
Prima di invocare qualunque comando, è utile chiedere al sistema l’elenco dei tool esposti dal server WebMCP. In un esempio tipo potresti vedere tool come:
add_toppingremove_topping- altri comandi specifici della tua UI
Questo passaggio serve a:
- verificare che il server MCP sia quello atteso;
- controllare nomi, parametri e capacità effettive dei tool;
- ridurre errori banali (tool rinominati, signature cambiate, deploy incompleto).
3) Esegui una sequenza di tool e controlla lo stato risultante
A questo punto puoi testare il comportamento della pagina invocando una serie di tool in un ordine preciso, ad esempio:
- aggiungi 10 peperoni;
- aggiungi formaggio;
- aggiungi 10 funghi.
Qui la cosa importante non è la “pizza”, ma la proprietà che vuoi garantire in produzione:
- ripetibilità (stessi input → stesso risultato),
- osservabilità (se qualcosa fallisce, sai dove guardare),
- verificabilità (puoi controllare che la UI sia davvero nello stato atteso).
Se tutto fila liscio, ottieni un riscontro immediato nella UI e/o nello stato applicativo.
4) Introduci un bug intenzionale per validare il flusso di debug
Un modo efficace per validare davvero la tua pipeline è inserire un errore deliberato: per esempio, far sì che quando qualcuno richiede i funghi venga lanciata un’eccezione.
Riesegui la stessa sequenza di tool. Se l’integrazione è corretta, l’agente (e DevTools) dovrebbe:
- intercettare un errore;
- correlare il fallimento ai messaggi di console;
- rendere evidente quale step ha causato il problema.
In pratica, stai testando la tua capacità di:
- riprodurre,
- osservare,
- diagnosticare.
5) Usa la console come fonte di verità (e non solo come “log”)
Quando un tool WebMCP fallisce, l’errore utile spesso vive in uno di questi posti:
- console (exception, stacktrace, errori applicativi);
- runtime signals (promise rejection, assertion fallite);
- stato UI incoerente (azioni parziali, elementi non aggiornati).
Chrome DevTools for Agents rende questo passaggio più lineare perché il debugging non si riduce a “l’agente ha fallito”: puoi vedere cosa è fallito nel contesto del browser.
6) Correggi e ripeti: il ciclo “fix → re-run” deve essere veloce
Una volta individuato il problema, il valore sta nel rientrare rapidamente nel ciclo:
- applica una correzione;
- riesegui la stessa sequenza (stessi input, stesso ordine);
- verifica che:
- l’errore non ricompaia;
- la UI arrivi allo stato atteso;
- non ci siano regressioni (es. altri topping che ora falliscono).
Un buon flusso di debug è quello che ti permette di arrivare a una sintesi operativa tipo:
- “errore trovato in console”,
- “fix applicato”,
- “sequenza completata con successo”.
Non è solo soddisfazione: è controllo.
7) Debug anche via CLI: utile per automazioni e CI
Oltre all’uso interattivo, è spesso utile collegarsi al browser via CLI, soprattutto per:
- script ripetibili;
- smoke test;
- pipeline CI che devono validare tool MCP a ogni commit.
Il flusso tipico è:
- connetti la CLI al browser;
- elenca le pagine disponibili;
- seleziona la pagina target;
- invoca tool come “aggiungi funghi e ananas” e verifica l’esito.
Il vantaggio della CLI è la standardizzazione: lo stesso script può girare localmente e in CI, fornendo segnali immediati se un tool ha rotto qualcosa.
8) Configurazione e flag: trattali come parte del prodotto
Quando lavori con DevTools for Agents + MCP client, i dettagli contano:
- come avviene la connessione al browser;
- quali permessi/flag abiliti;
- come abiliti la modalità di test e debug;
- quali log raccogli (e dove finiscono).
La configurazione non è “collaterale”: è ciò che rende il debug affidabile e ripetibile nel tempo, anche quando il team cresce o la base di tool aumenta.
Sintesi operativa
Per rendere solidi i tuoi tool WebMCP, imposta un workflow in tre mosse:
- Connetti e osserva: lavora su un browser reale, con console e segnali runtime accessibili.
- Esegui sequenze deterministiche: elenca tool, riproduci scenari e valida lo stato finale.
- Chiudi il loop rapidamente: intercetta l’errore in console, correggi, riesegui la stessa sequenza; poi automatizza via CLI.
Quando il ciclo “tool → errore → console → fix → re-run” diventa fluido, i tool MCP smettono di essere una demo fragile e iniziano a comportarsi come una superficie di automazione affidabile, pronta per test seri e integrazione continua.
Articolo originale: https://frontendfacile.it/blog/debug-dei-tool-webmcp-con-chrome-devtools-for-agents-un-flusso-pratico-per-testa
Top comments (0)