Quando un agente AI visita un sito web, in realtà è un turista che non parla la lingua locale. Che sia costruito su LangChain, Claude Code o sul sempre più popolare framework OpenClaw, l’agente deve indovinare quali pulsanti premere: raschiare HTML grezzo, inviare screenshot a modelli multimodali e masterizzare migliaia di token solo per capire dove si trova una barra di ricerca.
Quell’era potrebbe volgere al termine. All’inizio di questa settimana, il team di Google Chrome WebMCP – Web Model Context Protocol: disponibile in anteprima in Chrome 146 Canary. WebMCP, sviluppato congiuntamente dagli ingegneri di Google e Microsoft e incubato tramite W3C Gruppo della comunità Web Machine Learningè uno standard web proposto che consente a qualsiasi sito web di presentare strumenti strutturati e richiamabili direttamente agli agenti AI tramite una nuova API del browser: navigator.modelContext.
Le implicazioni per l’IT aziendale sono significative. Invece di costruire e mantenere server MCP backend separati in Python o Node.js per connettere le applicazioni web alle piattaforme AI, i team di sviluppo possono ora racchiudere la logica JavaScript lato client esistente in strumenti leggibili dagli agenti senza dover riprogettare una singola pagina.
Gli agenti AI sono turisti costosi e fragili su Internet
I problemi di costo e affidabilità associati agli attuali approcci all’interazione dell’agente web (agente browser) sono ben compresi da chiunque li abbia implementati su larga scala. I due metodi dominanti (visual screen scraping e analisi DOM) soffrono entrambi di inefficienze fondamentali che influiscono direttamente sui budget aziendali.
Con approcci basati su screenshot, gli agenti inseriscono immagini in modelli multimodali (come Claude e Gemini) e sperano che il modello possa descrivere non solo cosa c’è sullo schermo, ma dove si trovano pulsanti, campi modulo ed elementi interattivi. Ogni immagine consuma migliaia di monete e può avere una lunga latenza. Con gli approcci basati su DOM, gli agenti ricevono HTML e JavaScript grezzi, una lingua straniera piena di vari tag, regole CSS e markup strutturato che non sono correlati all’attività in corso ma consumano comunque spazio nella finestra di contesto e costi di inferenza.
In entrambi i casi, l’agente passa da ciò per cui il sito web è stato progettato (l’occhio umano) a ciò di cui ha bisogno il modello (dati strutturati sulle azioni attuali). Una singola ricerca di prodotto che un essere umano completa in pochi secondi può richiedere dozzine di interazioni sequenziali con agenti (cliccando sui filtri, scorrendo le pagine, analizzando i risultati); ognuna di queste è una chiamata di inferenza che aggiunge ritardi e costi.
Come funziona WebMCP: due API, uno standard
WebMCP propone due API complementari che fungono da ponti tra siti Web e agenti AI.
API dichiarativa Gestisce azioni standard che possono essere definite direttamente nei moduli HTML esistenti. Per le organizzazioni con moduli consolidati già in produzione, questo percorso richiede un lavoro aggiuntivo minimo; Gli sviluppatori possono aggiungere nomi e descrizioni degli strumenti al markup del modulo esistente in modo che tali moduli possano essere richiamati dagli agenti. Se i tuoi moduli HTML sono già puliti e ben strutturati, probabilmente sei all’80% del percorso.
API obbligatoria Gestisce interazioni più complesse e dinamiche che richiedono l’esecuzione di JavaScript. È qui che gli sviluppatori definiscono schemi di veicoli più ricchi; È concettualmente simile alle definizioni degli strumenti inviate agli endpoint API OpenAI o Anthropic, ma viene eseguito interamente sul lato client nel browser. Attraverso RegisterTool(), un sito Web può esporre funzioni come searchProducts (query, filtri) o orderPrints (copie, page_size) con schemi di parametri completi e descrizioni in linguaggio naturale.
L’idea di base è che una singola chiamata allo strumento tramite WebMCP può sostituire dozzine di interazioni di utilizzo del browser. Un sito di e-commerce che registra uno strumento searchProducts consente all’agente di effettuare una singola chiamata di funzione strutturata e ricevere risultati JSON strutturati, invece di dover fare clic sull’agente sui menu a discesa dei filtri, scorrere i risultati impaginati e acquisire uno screenshot di ogni pagina.
Esempio aziendale: costi, affidabilità e fine della raschiatura fragile
Per i decisori IT che valutano le implementazioni dell’IA nelle agenzie, WebMCP affronta contemporaneamente tre punti critici persistenti.
riduzione dei costi È il vantaggio misurabile più rapido. Sostituendo le sequenze di acquisizione di screenshot, le chiamate di inferenza multimodale e l’analisi DOM iterativa con chiamate a strumenti strutturati singoli, le organizzazioni possono aspettarsi riduzioni significative nel consumo di token.
Affidabilità Migliora perché gli agenti non devono più indovinare la struttura della pagina. Quando un sito web pubblica chiaramente un contratto per un veicolo: "Ecco le funzioni che supporto, ecco i loro parametri, ecco cosa restituiscono" – L’agente agisce con certezza piuttosto che con inferenza. Le interazioni che falliscono a causa di modifiche all’interfaccia utente, caricamento dinamico di contenuti o definizione di elementi ambigui vengono in gran parte eliminate per qualsiasi interazione coperta da uno strumento registrato.
Velocità di sviluppo i team Web vengono accelerati perché possono sfruttare JavaScript front-end esistente invece di creare un’infrastruttura back-end separata. La specifica sottolinea che qualsiasi attività che un utente può eseguire tramite l’interfaccia utente di una pagina può essere trasformata in uno strumento riutilizzando gran parte del codice JavaScript esistente della pagina. Non è necessario che i team apprendano nuovi framework server o mantengano superfici API separate per i consumatori intermedi.
In base alla progettazione, l’essere umano nel ciclo non è un ripensamento
Una decisione architettonica critica distingue WebMCP dal paradigma dell’agente completamente autonomo che ha dominato i titoli dei giornali recenti. Lo standard è progettato attorno a flussi di lavoro esplicitamente collaborativi e human-in-the-loop piuttosto che a un’automazione non supervisionata.
Secondo Khushal Sagar, ingegnere software dello staff di Chrome, le specifiche WebMCP definiscono tre pilastri che supportano questa filosofia.
-
Contesto: tutti i data broker devono comprendere cosa sta facendo l’utente, compresi i contenuti che spesso non sono visibili sullo schermo.
-
Abilità: azioni che l’agente può eseguire per conto dell’utente, dalla risposta alle domande alla compilazione di moduli.
-
Coordinamento: Controllare il trasferimento tra l’utente e l’agente quando l’agente incontra situazioni che non può risolvere da solo.
Gli autori delle specifiche di Google e Microsoft lo spiegano con uno scenario di acquisto: un utente di nome Maya chiede al suo assistente AI di aiutarla a trovare un abito ecologico per un matrimonio. L’agente consiglia i venditori, apre un browser su un sito di abbigliamento e scopre che la pagina contiene strumenti WebMCP come getDresses() e showDresses(). Quando i criteri di Maya vanno oltre i filtri di base del sito, l’agente richiama questi strumenti per recuperare i dati del prodotto e utilizza la propria logica per filtrarli. "abito da cocktail adatto," e quindi chiama showDresses() per aggiornare la pagina solo con risultati rilevanti. È un ciclo fluido del gusto e dell’azione umana; Questo è esattamente il tipo di navigazione collaborativa per cui WebMCP è stato progettato.
Questo non è uno standard di scansione headless. La specifica lo dice chiaramente che gli scenari senza testa e completamente autonomi sono irrilevanti. Per questi casi d’uso, gli autori fanno riferimento ai protocolli esistenti come il protocollo Agent-to-Agent (A2A) di Google. WebMCP riguarda il browser in cui si trova l’utente, guarda e collabora.
Non sostituisce MCP, è complementare
WebMCP non sostituisce il Model Context Protocol di Anthropic, sebbene abbia origini concettuali e parte del suo nome. Non è conforme alla specifica JSON-RPC utilizzata da MCP per la comunicazione client-server. Mentre MCP funziona come un protocollo backend che collega le piattaforme AI ai fornitori di servizi tramite server ospitati, WebMCP viene eseguito interamente sul lato client all’interno del browser.
La relazione è complementare. Un’agenzia di viaggi può mantenere un server MCP backend per integrazioni API dirette con piattaforme AI come ChatGPT o Claude, implementando contemporaneamente strumenti WebMCP sul sito Web rivolto al consumatore in modo che gli agenti basati su browser possano interagire con il flusso di prenotazione nel contesto della sessione attiva dell’utente. I due standard servono diversi modelli di interazione senza conflitto.
Questa distinzione è importante per gli architetti aziendali. Le integrazioni MCP backend sono adatte per l’automazione da servizio a servizio in cui non è richiesta un’interfaccia utente del browser. WebMCP è appropriato dove è presente l’utente e l’interazione sfrutta il contesto visivo condiviso che definisce gran parte delle interazioni web rivolte al consumatore che interessano alle organizzazioni.
Cosa accadrà dopo: dalla bandiera allo standard
WebMCP è attualmente disponibile in Chrome 146 Canary. "WebMCP per i test" Segnala su chrome://flags. Gli sviluppatori possono partecipare Programma di anteprima anticipata di Chrome per accedere alla documentazione e alle demo. Altri browser devono ancora annunciare le tempistiche di implementazione, ma la co-paternità attiva di Microsoft delle specifiche suggerisce che è probabile il supporto di Edge.
Gli osservatori del settore si aspettano che gli annunci ufficiali dei browser vengano fatti tra la metà e la fine del 2026, con Google Cloud Next e Google I/O che probabilmente saranno luoghi per annunci di lancio più ampi. La specifica sta passando dall’incubazione comunitaria all’interno del W3C a una bozza formale; è un processo che storicamente ha richiesto mesi ma segnala un serio impegno istituzionale.
Il confronto che fa Sagar è istruttivo: WebMCP mira a essere l’USB-C delle interazioni degli agenti AI con il web. Un’unica interfaccia standardizzata a cui qualsiasi agente può connettersi, sostituendo le strategie di scraping personalizzate esistenti e i fragili script di automazione.
La realizzazione di questa visione dipende dalla sua adozione da parte sia dei fornitori di browser che degli sviluppatori web. Ma con Google e Microsoft che distribuiscono congiuntamente il codice, il W3C che fornisce l’impalcatura aziendale e Chrome 146 che già esegue l’implementazione dietro una bandiera, WebMCP ha superato l’ostacolo più difficile che qualsiasi standard web abbia mai affrontato: passare dalla proposta al software funzionante.
