WebMCP è un'API del browser proposta che scopre, descrive ed esegue strumenti strutturati per un agente IA per conto di una persona. Il sito dichiara cosa fa un'azione e quali input accetta; l'agente chiama quello strumento invece di indovinare su quale pulsante o campo fare clic. Questo può rendere più rapidi e affidabili un modulo, un flusso di prenotazione o un'attività di diagnostica, ma non è un sostituto universale dell'automazione browser. la documentazione WebMCP di Chrome
La scelta pratica è architetturale. WebMCP è cooperazione lato server: chi possiede il sito pubblica un contratto rivolto agli agenti. L'automazione browser è osservazione lato client: un agente opera l'interfaccia che già esiste, compresa una sessione autenticata. Usa la prima quando controlli il sito e puoi definire strumenti sicuri; usa la seconda quando devi lavorare con il web di oggi. le linee guida sugli strumenti sicuri
Cos'è WebMCP
WebMCP (Web Model Context Protocol) è una proposta di API lato browser del team Chrome e della comunità WebMCP. La documentazione di Chrome lo descrive come un modo per costruire ed esporre strumenti strutturati agli agenti, preservando l'applicazione web visibile e il controllo della persona. Un sito può pubblicare uno strumento di ricerca, di pagamento, di selezione date, di assistenza o di diagnostica come miglioramento progressivo; una persona può continuare a usare la stessa pagina quando non c'è nessun agente. l'annuncio della prova dell'origine di Chrome
Come funziona WebMCP
Una pagina WebMCP registra gli strumenti presso il browser. Ogni strumento ha un nome, una descrizione, uno schema di input e un'implementazione che gira nella pagina. L'API imperativa usa JavaScript per azioni personalizzate; l'API dichiarativa annota normali moduli HTML. La documentazione di Chrome indica tre elementi che contano per un agente: la scoperta, gli schemi JSON di input e output, e lo stato che descrive cosa può fare la pagina corrente.
Il risultato può essere un percorso d'azione più breve. Invece di leggere un DOM enorme, dedurre che un pulsante significa submit_application e sperare che un selettore sopravviva a un restyling, un agente può chiamare lo strumento con nome passando campi descritti dallo schema. L'azione viene comunque eseguita in modo visibile nel sito, così la pagina può mostrare l'avanzamento e chiedere conferma prima di un acquisto o di un'altra operazione che cambia lo stato.
Il nostro test pratico di WebMCP, passo per passo
L'11 settembre 2026 abbiamo eseguito un test guidato sulla demo ufficiale Hotel Chain di Chrome Labs, con Google Chrome 152.0.7977.76 su macOS e WebMCP Model Context Tool Inspector 1.9.15. Chi ha operato ha usato dati sintetici degli ospiti, nessuna chiave API di Gemini e nessuna credenziale reale di hotel, pagamento o account. È stata una passeggiata sul comportamento, non un benchmark di velocità o affidabilità.
- L'Inspector ha scoperto gli strumenti e gli schemi della pagina. Abbiamo chiamato search_location per Parigi, 18 settembre, tre notti e un adulto; la pagina ha mostrato due strutture.
- Abbiamo chiamato filter_search_results con breakfast. Il numero visibile di risultati è passato da due a uno, lasciando solo Montmartre Suites.
- Abbiamo aperto quell'hotel, avviato il flusso di prenotazione e inserito l'identità sintetica Alex Chen. Lo strumento ha preparato il modulo ma non ha finalizzato la prenotazione.
- La pagina si è fermata su Confirm Reservation. Solo dopo il clic della persona che operava, la demo ha mostrato Reservation Confirmed.
Ha contato anche un limite dello strumento: dopo il nostro flusso manuale Execute Tool, l'azione Copy trace dell'Inspector ha restituito un array JSON vuoto. Per questo usiamo screenshot e un registro strutturato dei passaggi come prove di questa esecuzione, e non generalizziamo quel risultato del trace ad altre modalità dell'Inspector.
Che rapporto c'è tra WebMCP e l'automazione browser
WebMCP e l'automazione browser risolvono modi di fallire diversi. WebMCP elimina l'ambiguità quando il sito pubblica un buon contratto. L'automazione tradizionale, che sia Playwright, Selenium, browser-use o un agente che guida un browser reale, gestisce i siti che non pubblicano alcun contratto leggendo la pagina renderizzata e interagendo con essa. WebMCP quindi completa l'automazione: un client può chiamare uno strumento di pagina quando è disponibile e tornare alla navigazione normale quando non lo è.
La distinzione si verifica più facilmente come confine di capacità. Leggi sia la colonna positiva sia quella negativa prima di scegliere una strada.
| Approccio | Cosa può fare | Cosa non può fare |
|---|---|---|
| WebMCP | Chiamare strumenti con nome e descritti da uno schema, esposti da una pagina | Raggiungere pagine che non registrano strumenti o importare un accesso separato del browser |
| Automazione basata sul DOM | Operare quasi qualsiasi pagina renderizzata con selettori, screenshot o stato di accessibilità | Conoscere l'azione prevista dal sito senza interpretare l'interfaccia |
| Riutilizzo di una sessione di browser reale | Usare uno stato del browser autenticato, autorizzato e predisposto in modo esplicito | Garantire l'accesso, aggirare un CAPTCHA o imporsi sulle regole del sito |
Un rilascio concreto parte da un solo strumento in sola lettura, un browser supportato e un passaggio di conferma visibile. Amplia solo quando la strada di riserva funziona.
Il confine della sessione è altrettanto importante. WebMCP viene eseguito nella pagina visitata dal client; non trasferisce i cookie di Chrome di un utente in una nuova sessione cloud. Su un sito privo di WebMCP, ego (lite) è il browser Chromium locale per agenti AI: sei tu a fornire esplicitamente lo stato del browser e un agente compatibile usa il sito tramite ego-browser in uno Space dedicato e visibile. Lo Space tiene separati le schede e il controllo dell'attività dal lavoro che stai svolgendo, ma non è una VM remota né un confine di isolamento multi-tenant. Questo percorso cambia il modello di esecuzione del browser, non il contratto dell'interfaccia del sito. le note di rilascio di OpenClaw 2.0
Usa questa tabella di valutazione per rendere esplicita la decisione invece di trattare WebMCP come un aggiornamento universale.
| Domanda di valutazione | Scegli WebMCP quando... | Scegli l'automazione browser quando... |
|---|---|---|
| Controlli il sito? | Sì; puoi pubblicare e proteggere strumenti di pagina | No; devi lavorare con un sito di terze parti |
| L'attività richiede un accesso già esistente? | Basta la sessione autenticata della pagina stessa | L'agente deve riutilizzare una sessione locale predisposta a parte |
| Qual è l'obiettivo del rilascio? | Un contratto stabile e tipizzato per i client supportati | Un flusso immediato tra più pagine, senza lavoro di adozione |
Quando conviene usare WebMCP
Scegli WebMCP quando l'applicazione è tua, puoi definire confini di attività stabili e vuoi che gli agenti completino lavoro strutturato come moduli di assistenza, ricerca di viaggi, pagamenti o diagnostica interna. È particolarmente utile per interfacce complesse in cui una persona conosce l'azione prevista ma un agente avrebbe altrimenti bisogno di molti clic interpretati. Mantieni lo strumento piccolo, tipizzato e osservabile.
Scegli l'automazione con browser reale quando non controlli il sito, ti serve un accesso già autorizzato, devi lavorare su molti siti tra loro non correlati o ti serve un flusso oggi e non dopo l'adozione del sito. Per gli script CI consolidati l'automazione deterministica resta appropriata; per il lavoro interattivo autenticato, un browser locale visibile dà all'agente lo stesso account e lo stesso stato di pagina che una persona può rivedere.
I limiti di sicurezza di WebMCP
WebMCP non concede autorità da solo. Chrome protegge le API con l'isolamento dell'origine e la policy di autorizzazione tools; gli iframe cross-origin sono disattivati per impostazione predefinita. Un sito può esporre strumenti solo alle origini di cui si fida, e le linee guida di sicurezza di Chrome consigliano readOnlyHint per gli strumenti che non modificano lo stato e untrustedContentHint quando l'output contiene testo esterno o generato dagli utenti.
L'iniezione di prompt resta possibile perché un agente elabora insieme istruzioni e contenuti web. Mantieni descrizioni e output concisi, convalida gli input sul server, richiedi la conferma della persona per le azioni con conseguenze ed esponi il minor insieme possibile di origini e strumenti. WebMCP è un'interfaccia più chiara, non un motivo per saltare autenticazione, autorizzazione, log di audit o revisione umana.
Sfide e limiti di WebMCP
Il limite principale di WebMCP è l'adozione: un client deve visitare una pagina compatibile e il browser deve implementare l'API sperimentale. Chrome osserva inoltre che gli scenari headless non sono l'obiettivo principale del progetto, che le applicazioni complesse possono richiedere una ristrutturazione dello stato e che la proposta è ancora in evoluzione.
Ne deriva uno stack misto per il futuro prevedibile. Un sito può esporre un ottimo strumento di checkout e lasciare le impostazioni dell'account come normali controlli DOM; un browser può supportare WebMCP in prova ma non nel tuo parco di produzione. Mantieni una strada di riserva di automazione normale e misura errori degli strumenti, tassi di conferma e passaggi a una persona su esecuzioni ripetute.
Come provare WebMCP oggi
Per gli esperimenti locali, attiva chrome://flags/#enable-webmcp-testing in Chrome e riavvia. Per i test dal vivo, la documentazione di Chrome indirizza gli sviluppatori alla prova dell'origine di Chrome 149. Usa le demo ufficiali e l'estensione Model Context Tool Inspector per vedere gli strumenti registrati, chiamarli manualmente e provare input sia validi sia invalidi. Poiché la proposta è in discussione attiva, fissa la versione del browser e aspettati cambiamenti all'API. il WebMCP Challenge di OpenAI
Se usi agenti e non possiedi il sito, non devi aspettare che WebMCP venga adottato. Esegui /ego-browser nel tuo agente di programmazione supportato, descrivi l'attività delimitata e mantieni espliciti la sessione del browser e i permessi. I due approcci convivranno: WebMCP rende più facili da operare i siti che collaborano; l'automazione con browser reale raggiunge tutto il resto.
Domande frequenti
WebMCP è la stessa cosa di un server MCP?
No. Un server MCP tradizionale è un processo o un servizio esterno che espone strumenti a un client. WebMCP espone strumenti dalla pagina web stessa a un agente nel browser, con i confini dell'origine del browser e della policy di autorizzazione.
WebMCP può automatizzare un sito che non supporta WebMCP?
No. Il client deve visitare una pagina che registra strumenti. Usa l'automazione browser normale per un sito che non ha adottato WebMCP e fermati per chiedere l'intervento umano quando l'autenticazione o una verifica lo richiedono.
Chi deve implementare WebMCP?
Chi possiede il sito web implementa gli strumenti WebMCP; un client agente e un browser devono poterli usare. Chi visita il sito non può aggiungere strumenti a un sito altrui.
Quali sono i principali vantaggi di WebMCP?
WebMCP dà agli agenti azioni con nome, input descritti da uno schema e stato della pagina, riducendo la necessità di indovinare i selettori e i clic interpretati sui siti che collaborano. L'applicazione deve comunque convalidare ogni payload.
Quali sono i principali limiti di WebMCP?
WebMCP richiede l'adozione da parte delle pagine e il supporto dei browser, resta sperimentale in Chrome e non risolve la parità headless, le politiche di autenticazione o l'iniezione di prompt.
Gli strumenti WebMCP possono funzionare senza una persona?
Alcuni strumenti a basso rischio possono girare automaticamente, ma le azioni sensibili dovrebbero richiedere l'interazione e la conferma della persona. Il progetto di Chrome punta a flussi locali nel browser con una persona nel ciclo.
WebMCP espone strumenti a ogni iframe?
No. L'isolamento dell'origine e la policy di autorizzazione tools controllano la registrazione; gli iframe cross-origin richiedono un permesso esplicito e un'esposizione fidata.
Per quanto tempo l'API WebMCP resterà stabile?
Non esiste ancora alcuna garanzia di stabilità. Chrome etichetta WebMCP come standard proposto in discussione attiva, quindi fissa le versioni e monitora l'explainer e le note della prova dell'origine.
Posso usare WebMCP con un account già autenticato?
Una pagina può esporre strumenti all'interno della propria sessione autenticata, ma WebMCP non trasferisce i cookie a un altro browser. Mantieni autorizzazione e conferma nel modello di sicurezza del sito.
Cosa devo usare mentre un sito non ha WebMCP?
Usa l'automazione browser normale. Per una sessione locale autorizzata, ego (lite) permette a un agente supportato di operare un browser reale predisposto a parte tramite /ego-browser.
Dove posso leggere le linee guida di implementazione?
Parti dalla documentazione WebMCP di Chrome, dalle linee guida sugli strumenti sicuri, dalla pagina della prova dell'origine e dall'explainer WebMCP su GitHub; i link sono elencati nelle note sulle fonti qui sotto.