Chrome DevTools MCP con Kitesurf WebMCP: guida pratica

In breve

Per usare Kitesurf WebMCP, occorre collegare un agente compatibile con MCP a Cloudflare Browser Run tramite Chrome DevTools MCP, impostare l'endpoint WebSocket su browser=kitesurf e abilitare la categoria sperimentale dei tool WebMCP. L'agente ottiene così due comandi fondamentali: list_webmcp_tools, per scoprire le azioni offerte dalla pagina, ed execute_webmcp_tool, per eseguirne una.

È meglio iniziare con un'azione di sola lettura o reversibile. Cloudflare Radar è un buon ambiente documentato perché espone azioni come navigate-to e set-location. Prima si esamina lo schema restituito da Kitesurf, poi si forniscono soltanto gli argomenti ammessi dallo schema e infine si confronta il risultato strutturato con lo stato visibile della pagina. Una chiamata al tool supera il test solo se i due risultati coincidono.

Questa guida propone un piano di test basato sulla documentazione, non sostiene di aver eseguito una prova dal vivo. Per questa attività non erano disponibili né un account Cloudflare di test né un token Browser Run; di conseguenza, qui sotto non viene presentato alcun risultato di successo inventato.

Cosa cambia davvero con Kitesurf WebMCP

MCP e WebMCP svolgono funzioni diverse. MCP collega l'agente al browser remoto; WebMCP permette al sito di pubblicare nel browser le proprie azioni con un nome preciso. MCP è la linea telefonica, WebMCP il menu dall'altra parte: la linea stabilisce il collegamento, mentre il menu indica esattamente che cosa si può richiedere e quali informazioni servono.

Senza quel menu, un agente di solito legge la pagina, individua un controllo, lo seleziona, attende e legge di nuovo. Con WebMCP, invece, una pagina può esporre una funzione come set-location con input tipizzati. L'agente deve comunque scegliere l'azione corretta e convalidarne l'output, ma non è più costretto a dedurre ogni interazione dai pixel o dalla struttura della pagina.

La documentazione WebMCP di Cloudflare specifica che Kitesurf dispone di una propria implementazione, quindi non richiede una sessione Chrome Lab. Le pagine possono registrare tool programmatici tramite document.modelContext; Kitesurf riconosce anche i tool dichiarativi dei moduli contrassegnati dagli attributi toolname e tooldescription.

Collegare Chrome DevTools MCP a Kitesurf

Servono Node.js 20.19 o una versione successiva, un client compatibile con MCP, un ID account Cloudflare e un token API con autorizzazione Browser Rendering - Edit. La procedura Cloudflare per configurare un client MCP copre Claude Desktop, Claude Code, Cursor e OpenCode. Per chi configura la prima connessione MCP, la selezione dei migliori server MCP aiuta a capire il ruolo svolto dal server locale.

Nel lancio di Kitesurf, Cloudflare propone questa configurazione per il client locale:

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

La struttura della configurazione va adattata al client in uso, mantenendo però invariati gli argomenti del comando. L'ID account e il token reali dovrebbero risiedere in segreti forniti tramite l'ambiente, non in un file di impostazioni incluso nel repository. Non bisogna copiare in questo URL i parametri di Chrome Lab: Kitesurf usa browser=kitesurf, non richiede lab=true e non accetta keep_alive.

L'ultimo flag è indispensabile. È --category-experimental-webmcp ad aggiungere list_webmcp_tools ed execute_webmcp_tool a Chrome DevTools MCP. Senza questo flag, la connessione può funzionare perfettamente anche se i due comandi WebMCP non compaiono.

Eseguire un'attività verificata su Cloudflare Radar

Il test minimo davvero utile deve dimostrare quattro aspetti: la scoperta dei tool funziona, lo schema è leggibile, l'esecuzione restituisce dati e la pagina riflette il risultato.

1. Chiedere all'agente connesso di aprire https://radar.cloudflare.com/. L'attività deve restare confinata a un account di test, evitando azioni con conseguenze finanziarie, distruttive o estese all'intero account.
2. Chiamare list_webmcp_tools e salvare nome, descrizione e schema di input di ogni tool restituito. Poiché l'insieme disponibile può cambiare dopo una navigazione o un'altra azione, l'inventario vale per lo stato corrente della pagina.
3. Se è disponibile un'azione innocua come set-location, selezionarla e leggere lo schema restituito. I nomi degli argomenti non vanno dedotti da questo articolo: il contratto è lo schema live.
4. Chiamare execute_webmcp_tool con un valore di posizione valido rispetto allo schema. Registrare il nome esatto del tool, gli argomenti, il risultato strutturato, il tempo trascorso e lo stato visibile della pagina.
5. Confrontare la risposta con ciò che mostra Radar. Dopo il cambio di stato, eseguire nuovamente list_webmcp_tools e annotare le eventuali azioni aggiunte o rimosse.

Un prompt efficace per l'agente può essere molto diretto:

Le prove vanno trattate come un piccolo verbale di test, non come una trascrizione della chat. Come minimo, è opportuno conservare questi campi:

In questo modo una demo diventa un test ripetibile da un team di sviluppo. Inoltre, è possibile distinguere un problema di WebMCP da un errore di ragionamento dell'agente. Se il tool indicato per nome manca, l'interfaccia ha fallito prima dell'esecuzione. Se la chiamata riesce ma la pagina mostra altro, il problema si trova nell'implementazione o nella verifica successiva.

Quando Kitesurf richiede un fallback

Kitesurf WebMCP non è un livello universale per controllare il browser. I suoi limiti attuali determinano quali attività di produzione possano essere instradate in sicurezza attraverso questa tecnologia.

• I tool registrati dentro un iframe o un popup non vengono esposti tramite CDP. L'agente deve considerarli non disponibili e ricorrere a un percorso browser tradizionale, a un intervento umano oppure, se il sito è di proprietà del team, a un tool di primo livello.
• Le sessioni Kitesurf non appaiono in wrangler browser list e non dispongono di una vista live. Un agente non può portare a termine un tool che si interrompe per chiedere la conferma di una persona.
• Per un'azione soggetta a conferma, il percorso manuale documentato da Cloudflare passa dal pannello WebMCP nella sezione Application del playground di Kitesurf. È un passaggio di consegne, non un'automazione non presidiata.
• Kitesurf non implementa la policy di autorizzazione tools di WebMCP né il filtro dei tool basato sull'origine. Scoprire un tool non significa essere autorizzati a usarlo: serve un'allowlist separata per domini, azioni e identità di test.
• L'elenco dei tool dipende dallo stato. Dopo una navigazione o qualsiasi azione che modifichi la pagina, va richiesto di nuovo prima di dare per scontato che il tool successivo esista ancora.

Lo schema di produzione più realistico è un router: prima WebMCP, se esiste un'azione adatta identificata per nome; poi la normale browser automation, se non esiste; infine il passaggio a una persona, quando serve il consenso. Queste diramazioni non vanno nascoste dietro un unico prompt ottimistico.

Il conto economico dipende dalla manutenzione, non solo dal prezzo del browser

Kitesurf è gratuito durante la beta, nei limiti previsti per l'account, ma Cloudflare non ha stabilito che le normali tariffe a consumo di Browser Run si applichino anche alla beta gratuita. Il quadro attuale di prezzi e disponibilità di Kitesurf è trattato separatamente, insieme ai motivi per cui non conviene fondare un modello di costo permanente su un'offerta beta.

In questo mercato esiste già un budget concreto per l'infrastruttura browser. Browserbase propone piani a $20 e $99 al mese. Browserless offre piani da $25 e $140 al mese con fatturazione annuale. Questi prodotti coprono esigenze infrastrutturali più ampie, quindi non si tratta di sostenere una sostituzione alla pari. Dimostrano però che i team pagano già per gestire agenti che operano nel browser.

WebMCP incide su una voce diversa del budget: manutenzione dei selettori, nuovi tentativi e revisione da parte degli operatori. Non elimina il browser, il modello, i controlli di sicurezza, la convalida dei risultati o il percorso di fallback. La stessa attività va misurata in entrambi i modi, confrontando tempo trascorso, tentativi falliti, interventi umani e correzioni tecniche. Kitesurf va mantenuto soltanto dove la riduzione misurata della manutenzione supera il lavoro d'integrazione.

Sette casi d'uso, in ordine di beneficio

Tutti i casi d'uso seguenti presuppongono che la pagina di destinazione esponga davvero un tool WebMCP adeguato. Kitesurf non può creare un'azione che il sito non mette a disposizione.

Il primo caso d'uso offre il valore più ampio, perché per anni la maggior parte dei team dovrà lavorare con un web ibrido. Un router capace di capire quando non usare WebMCP è più utile di una demo riuscita su una singola pagina preparata.

Tre prodotti che vale la pena costruire

1. Un router WebMCP-first con fallback

Si può creare un livello di policy per i team che sviluppano agenti: elenca i tool di una pagina, abbina l'azione richiesta dall'utente a uno schema consentito e instrada l'attività verso execute_webmcp_tool, la browser automation tradizionale oppure una coda gestita da persone. È l'opportunità più solida perché colma il divario che frena l'adozione, senza aspettare che ogni sito implementi WebMCP.

La domanda per questo tipo di lavoro è già visibile: browser automation registra circa 720 ricerche mensili, mentre la query commerciale browser automation tools ne conta circa 260, con un CPC di $34.28 nei dati sulle keyword raccolti per questa analisi. La versione minima vendibile richiede un connettore per client MCP, un'allowlist di domini e azioni, un sistema di abbinamento degli schemi, un registro di esecuzione e un adattatore di fallback.

Il limite è la copertura. WebMCP è ancora poco diffuso, l'insieme dei tool può cambiare con lo stato della pagina e Kitesurf non può esporre tramite CDP i tool presenti in iframe o popup. Il motore di fallback è parte integrante del prodotto, non una funzione facoltativa da aggiungere in seguito.

2. Un monitor di regressione WebMCP

Ai proprietari dei siti si può offrire un controllo pianificato che registra nomi e schemi dei tool esposti, esegue una fixture reversibile, confronta il risultato con la pagina visibile e invia un avviso in caso di differenze. Circa 590 ricerche mensili riguardano website automation, con un CPC di $33.88. Nei dati dei suggerimenti, la query correlata al singolare browser automation tool è cresciuta del 24% su base annua.

Un MVP può monitorare un elenco ristretto di route di proprietà con credenziali di test, archiviare gli inventari dei tool prima e dopo l'azione e produrre un resoconto sintetico dell'errore con argomenti, risultato, durata e stato della pagina. Il problema è lo stato: un tool assente può dipendere dalla route o dalla sessione sbagliata, non da una release difettosa. Servono quindi una navigazione riproducibile e fixture progettate con attenzione.

3. Un audit di preparazione a WebMCP

Un servizio di preflight per team web può mappare quali customer journey espongono tool di primo livello, quali azioni si trovano dietro iframe o popup e quali richiedono l'approvazione di una persona. L'indicatore della domanda è concreto: playwright browser automation registra circa 320 ricerche mensili ed è cresciuta del 129% su base annua, mentre website automation ne registra circa 590.

La versione minima accetta route e identità di test di un sito di proprietà, elenca e classifica i tool disponibili e produce un report d'implementazione ordinato per priorità. Il suo limite reale è l'osservabilità. Poiché Kitesurf non può esporre tramite CDP i tool annidati in iframe o popup, un auditor non può dedurne da Kitesurf soltanto i contratti previsti. Per distinguere ciò che è nascosto da ciò che è assente, servono informazioni fornite dal proprietario del sito o un secondo metodo di ispezione.

Limiti e valutazione realistica

Kitesurf WebMCP è già adatto ad attività circoscritte e reversibili, quando un'azione strutturata è chiaramente preferibile a una sequenza di clic. Non dovrebbe invece essere l'unico percorso per un workflow critico, un pagamento annidato o un'attività che deve attendere l'approvazione in tempo reale di una persona.

La funzione ha valore, ma il lancio precede la maturità dell'ecosistema. Il modello basato su azioni con un nome può ridurre l'ambiguità e facilitare la diagnosi degli errori. Non rende ogni sito automaticamente compatibile con gli agenti e non trasforma un payload restituito nella prova che la pagina abbia eseguito l'operazione corretta. Il confine decisivo del prodotto resta la verifica.

Per realizzare in produzione questa connessione, il sistema di test e verifica e la policy di fallback, posso aiutarti a costruire il sistema.