WebMCP: lo standard che permette agli agenti AI di usare i siti web nel browser

Differenze tra standard WebMCP e il protocollo MCP

La distinzione tra WebMCP e  MCP riguarda il punto in cui gli strumenti vivono e operano. Il Model Context Protocol, introdotto da Anthropic nel novembre 2024, è uno standard aperto che collega un modello linguistico a dati, applicazioni e servizi esterni attraverso un server dedicato. In questo schema il dialogo avviene tra la piattaforma di intelligenza artificiale e il backend del servizio: l’assistente comunica con un server remoto, che traduce le richieste in azioni e ne restituisce i risultati. Il trasporto dei messaggi segue il formato JSON-RPC 2.0, con due canali principali, l’input/output standard per le risorse locali e gli eventi inviati dal server per quelle remote. Questo modello eccelle nelle azioni lato server, dove la logica risiede su sistemi che il browser non raggiunge da solo.

Lo standard browser-native ribalta tale impostazione. Anziché esporre funzioni su un server separato, WebMCP permette al sito di dichiarare i propri strumenti direttamente nello script della pagina, dove vengono eseguiti nella stessa scheda che la persona sta usando. L’agente e il documento condividono il medesimo contesto, la sessione autenticata e lo stato dell’interfaccia, senza che lo sviluppatore debba replicare nulla altrove. Mentre il protocollo di Anthropic richiede la costruzione di un servizio dedicato, la specifica lato client riutilizza il codice già scritto per l’esperienza visiva. Da qui deriva la differenza pratica più evidente: il primo opera dietro le quinte, su infrastrutture remote; il secondo agisce sulla pagina, sotto gli occhi di chi la consulta.

Le due tecnologie non si pongono in concorrenza, ma si completano a vicenda. WebMCP nasce ispirandosi al Model Context Protocol e ne eredita il vocabolario, fatto di strumenti, schemi e parametri, adattandolo però ai concetti nativi del web come l’origine, i permessi e il ciclo di vita delle schede. Il protocollo backend resta la scelta adatta quando un’azione vive su un server, ad esempio l’interrogazione di un database aziendale o l’integrazione con un software gestionale. La controparte lato client interviene invece quando la funzionalità è già presente nel front-end e richiederebbe altrimenti una costosa duplicazione sul server. Un sistema automatizzato ricorre all’uno o all’altro a seconda del compito, e quando una pagina non offre gli strumenti necessari può sempre tornare all’automazione tradizionale dell’interfaccia. La convivenza dei due standard copre così l’intero spettro delle azioni di un agente, dai servizi remoti fino all’interazione diretta con il documento.

Funzionamento di WebMCP per gli agenti AI

La logica operativa di questo standard consiste nel dichiarare in anticipo lo scopo di ogni elemento interattivo, anziché lasciare che il programma lo deduca osservando pulsanti, campi e collegamenti. Un sito che adotta il protocollo comunica direttamente la funzione di una ricerca o di un acquisto definendo un componente chiamato strumento. Tale componente viene eseguito in modo visibile sulla pagina, così che la persona possa verificare il corretto svolgimento dell’operazione e mantenere il controllo sul risultato finale.

Per comprendere il valore di questo modello occorre distinguere due modalità di interazione. La prima, definita attivazione, descrive l’azione con cui un sistema automatizzato simula i clic del mouse e l’inserimento di testo, replicando il comportamento di una persona davanti allo schermo. Questa via comprende spesso molti passaggi e lascia ciascuno di essi aperto all’interpretazione, con un margine di errore non trascurabile. La seconda modalità, introdotta da WebMCP, sostituisce l’imitazione del gesto umano con una chiamata diretta a una funzione descritta in modo formale, più affidabile e meno ambigua.

Il sistema poggia su tre capacità che le pagine mettono a disposizione di un assistente:

Rilevamento

Modalità standard con cui le pagine registrano le proprie funzioni presso un sistema automatizzato, come una procedura di pagamento o un filtro dei risultati.

Schemi JSON

Definizioni esplicite degli ingressi e delle uscite attese, utili a ridurre fraintendimenti e risposte non corrette generate dal modello.

Stato

Comprensione condivisa del contesto corrente della pagina, così che l’assistente conosca in tempo reale le risorse disponibili su cui agire.

Gli agenti basati sull’intelligenza artificiale costituiscono una tecnologia recente, in grado di assistere le persone nel portare a termine compiti tecnici e articolati. L’arricchimento progressivo offerto dalla specifica si affianca alle pagine esistenti senza alterarne l’aspetto né le scelte di progettazione legate al marchio. Quando un’operazione risulta sensibile, come la conferma di un pagamento, il modello prevede la possibilità di richiedere un’interazione esplicita attraverso una finestra di conferma, preservando la supervisione della persona su ogni fase critica del processo.

Integrazioni backend e strumenti lato client a confronto

La differenza sostanziale tra le integrazioni tradizionali e l’approccio proposto da WebMCP riguarda il luogo in cui avviene il dialogo con il sistema automatizzato. Le piattaforme come gli assistenti conversazionali interagiscono già con servizi esterni per controllare il meteo, individuare voli e alberghi o fornire indicazioni stradali. Questa capacità si appoggia a integrazioni di backend, nelle quali un servizio registra le proprie funzioni presso la piattaforma e comunica con essa tramite un’interfaccia server, agendo per conto della persona che dialoga con l’assistente.

Tale schema funziona bene per le azioni che si svolgono lato server, ma presenta criticità evidenti per le applicazioni web interattive. Il dialogo diretto tra agente e servizio scavalca l’interfaccia del sito, con una perdita di contesto e una disintermediazione dell’esperienza visiva. Lo sviluppatore si trova inoltre costretto a duplicare su un server separato lo stato dell’utente, il contesto attivo e le credenziali di autenticazione. A ciò si aggiunge l’onere di scrivere un server dedicato, anziché riutilizzare il codice JavaScript già presente nel browser.

L’alternativa lato client risolve queste difficoltà permettendo di definire gli strumenti direttamente nello script della pagina. In questo modo l’agente e la persona collaborano all’interno della stessa interfaccia, condividendo il medesimo contesto e mantenendo il controllo sull’operazione. Una pagina che adotta tale modello può essere considerata un server di contesto interno al browser, capace di esporre la logica lato client e l’interazione con il documento invece di funzioni remote.

Registrazione degli strumenti con l’API imperativa

La via imperativa di WebMCP si fonda su un’interfaccia esposta nel documento attraverso l’oggetto document.modelContext. Un fornitore di contesto registra una funzione richiamando il metodo registerTool, al quale fornisce un nome, una descrizione in linguaggio naturale e uno schema degli ingressi. Lo schema, espresso in formato JSON, definisce con precisione i parametri attesi e riduce il rischio di interpretazioni errate o di risposte inventate dal modello. La descrizione testuale, scritta in modo chiaro, consente al sistema automatizzato di capire quando e perché impiegare quella specifica funzione.

Il ciclo di vita di una chiamata segue una sequenza ordinata e prevedibile:

1. Registrazione: la pagina dichiara una o più funzioni tramite il metodo dedicato, specificandone nome, descrizione e parametri.
2. Rilevamento: l’agente interroga il browser per scoprire l’elenco attivo degli strumenti e dei relativi schemi.
3. Invocazione: l’agente richiede una chiamata, inviando argomenti strutturati conformi allo schema degli ingressi.
4. Esecuzione: il browser media la richiesta e avvia la funzione di esecuzione con gli argomenti ricevuti, eseguendo la logica lato client.
5. Risposta: la funzione restituisce un risultato strutturato, che il sistema elabora per proseguire la collaborazione con la persona.

Questa organizzazione consente di mantenere allineate la definizione dello strumento e la sua implementazione, poiché entrambe risiedono nello stesso punto del codice. La funzione di esecuzione riutilizza la logica già scritta per l’interfaccia visiva, aggiornando lo stato e il contenuto della pagina come avverrebbe con un’azione manuale. Al termine restituisce un risultato che l’assistente interpreta per continuare il dialogo. Per revocare una funzione registrata, lo sviluppatore può interrompere il segnale associato tramite un controllo dedicato, rimuovendola quando non risulta più pertinente allo stato corrente del documento.

Annotazione dei moduli HTML con l’API dichiarativa

Accanto alla via programmatica, WebMCP offre una controparte dichiarativa pensata per i moduli e i campi di inserimento standard. Questa modalità consente al browser di sintetizzare automaticamente la definizione di uno strumento a partire dagli elementi form presenti nella pagina, senza richiedere la scrittura di codice aggiuntivo. L’annotazione di un modulo trasforma quindi una struttura già esistente in una funzione comprensibile per un sistema automatizzato, rendendo immediatamente utilizzabili componenti diffusi come la registrazione di un utente, la ricerca di un prodotto o l’invio di una richiesta.

La coesistenza delle due interfacce risponde a una necessità precisa. Come i siti non possono essere costruiti esclusivamente con moduli dichiarativi, perché parte della funzionalità del web richiede JavaScript, anche la rappresentazione delle capacità di un’applicazione non può limitarsi alle sole strutture statiche. Per esporre l’intera gamma delle azioni possibili, lo standard deve poter descrivere anche la logica scritta in codice attraverso strumenti programmatici, non soltanto quelli derivati dai campi di un modulo. La parte dichiarativa copre i casi più comuni con il minimo sforzo, mentre la parte imperativa raggiunge le funzioni che nessuna marcatura statica potrebbe esprimere.

La scelta tra le due strade dipende dalla natura dell’operazione. Un modulo di contatto, una barra di ricerca o un filtro semplice si prestano alla sintesi automatica e non giustificano lo sviluppo di codice dedicato. Le funzioni che modificano dinamicamente l’interfaccia, che gestiscono uno stato complesso o che restituiscono dati elaborati richiedono invece la registrazione programmatica. La combinazione delle due modalità permette di adattare un’intera applicazione, dai componenti elementari fino alle interazioni più sofisticate, mantenendo un unico vocabolario comune per il sistema automatizzato che le interpreta.

Casi d’uso concreti per l’attivazione agentica

Le applicazioni di WebMCP coprono ambiti molto diversi, accomunati dalla collaborazione tra la persona e il sistema automatizzato all’interno della stessa interfaccia. Nell’assistenza ai clienti, un flusso di supporto articolato può guidare l’agente verso il modulo corretto e compilarne i campi con le informazioni raccolte durante la conversazione. Nel settore dei viaggi, l’organizzazione di itinerari complessi, con più città e più passeggeri, si riduce a un numero inferiore di passaggi, alleggerendo un compito che con la sola navigazione manuale risulterebbe lungo e soggetto a errori.

Alcune azioni risultano particolarmente delicate, come la finalizzazione di un acquisto. In questi casi la specifica prevede un comando che richiede la conferma esplicita della persona attraverso una finestra dedicata, così da preservare il controllo sulle operazioni irreversibili. Sul piano pratico, le funzioni esposte da una pagina possono svolgere attività distinte:

• Compilazione di moduli strutturati: una funzione dedicata mappa i dati raccolti dalla conversazione nei campi corretti, distinguendo ad esempio un nome completo da nome e cognome separati.
• Selezione di date e orari: un componente specifico gestisce scelte complesse in una prenotazione, dove i campi pensati per le persone risulterebbero poco chiari a un sistema automatizzato.
• Diagnostica rapida delle applicazioni: una funzione di controllo, collocata in una pagina per sviluppatori, avvia verifiche e correzioni altrimenti nascoste dietro menu profondi.

L’utilità del modello emerge anche in contesti tecnici avanzati. Nelle interfacce di revisione del codice, strumenti capaci di interrogare lo stato dei processi di compilazione e di recuperare i registri degli errori aiutano i sistemi automatizzati a operare su pannelli complessi, che diversamente verrebbero gestiti con difficoltà. Nella progettazione grafica, la cooperazione tra persona e agente consente di filtrare modelli, applicare modifiche visive in blocco e avviare un ordine di stampa, mantenendo ogni intervento verificabile prima della conferma definitiva. In tutti questi scenari resta centrale la possibilità di delegare porzioni di un compito senza rinunciare alla supervisione di chi lo controlla.

Sicurezza e isolamento dell’origine nel protocollo

La protezione delle interazioni occupa un ruolo centrale in WebMCP, poiché il dialogo con un sistema automatizzato attraversa i confini tradizionali della fiducia. Le interfacce sono disponibili soltanto nei documenti isolati per origine, una condizione che mantiene stabile l’origine del documento per tutta la durata di uno strumento. Quando un documento abilita la modifica del proprio dominio, ad esempio tramite un’apposita intestazione che disattiva il raggruppamento per origine, le funzioni dello standard risultano automaticamente disabilitate, a tutela della coerenza del contesto in cui operano gli assistenti.

Il controllo degli accessi si basa inoltre su una politica dei permessi dedicata. Il valore predefinito consente la registrazione delle funzioni nei contesti di primo livello e della stessa origine, mentre la disabilita per gli iframe di origine diversa. Per autorizzare l’uso all’interno di un iframe multiorigine, lo sviluppatore aggiunge un attributo specifico all’elemento, delegando in modo esplicito il permesso a una cornice altrimenti esclusa. Le chiamate effettuate senza l’autorizzazione necessaria vengono respinte con un errore dedicato, che segnala chiaramente l’assenza del permesso richiesto.

Per impostazione predefinita, le funzioni registrate da un documento restano esposte soltanto a sé stesso, ai documenti della stessa origine nello stesso albero e agli agenti integrati nel browser. Allo scopo di supportare assistenti forniti dall’autore della pagina, ed eseguiti all’interno di cornici, lo standard permette di condividere in modo selettivo le funzioni con origini sicure scelte dallo sviluppatore. Un documento che corrisponde a tali origini, e abilitato all’uso degli strumenti, riceve l’evento di aggiornamento quando una funzione viene registrata o rimossa, e può individuarla ed eseguirla. Questo equilibrio tra apertura e controllo consente di estendere le capacità agentiche solo verso le destinazioni che l’autore considera affidabili.

Limiti operativi degli strumenti in-browser

Pur semplificando i compiti complessi, WebMCP presenta alcuni vincoli che ne delimitano l’ambito di applicazione. La gestione delle chiamate avviene in JavaScript e richiede quindi un contesto di navigazione attivo: una scheda del browser o una vista web deve restare aperta per fornire l’interfaccia visibile e il contesto necessario. Di conseguenza, l’esecuzione di funzioni in modalità headless, priva di interfaccia, non rientra tra gli scenari supportati, così come restano esclusi gli agenti completamente autonomi privi di supervisione umana.

Un secondo limite riguarda le interfacce particolarmente articolate. Quando un sito raggiunge un elevato grado di complessità, l’adozione del modello può comportare un lavoro di ristrutturazione o l’aggiunta di codice per gestire lo stato dell’applicazione e della sua interfaccia. Questo sovraccarico rappresenta un costo da valutare in rapporto ai benefici attesi, soprattutto per piattaforme estese con numerose schermate interdipendenti. La convenienza dell’integrazione cresce quando le operazioni più frequenti possono essere esposte come strumenti chiari e riutilizzabili.

La rilevabilità delle funzioni costituisce un ulteriore aspetto da considerare. I client e i browser devono visitare direttamente un sito per sapere se dispone di strumenti richiamabili, poiché non esiste ancora un meccanismo di scoperta a distanza pienamente definito. Va inoltre ricordato che questa proposta nasce per i flussi locali con una persona coinvolta nel processo, e non per sostituire i protocolli orientati al backend, che continua piuttosto a complementare. Quando un compito non risulta realizzabile attraverso le funzioni fornite dalla pagina, un sistema automatizzato può comunque ricorrere all’automazione generica del browser, tornando alla simulazione dell’input. Questa convivenza evita conflitti con le tecniche di automazione già diffuse e garantisce una via di riserva sempre disponibile.

Stato di adozione e sperimentazione nei browser

L’introduzione di WebMCP nei browser procede attraverso una fase sperimentale aperta agli sviluppatori. La prova dell’origine è disponibile a partire dalla versione 149 di Chrome e consente di valutare la specifica in condizioni reali prima di una sua eventuale standardizzazione definitiva. Per lo sviluppo locale, il protocollo può essere attivato tramite un apposito flag nelle impostazioni sperimentali del browser, seguito dal riavvio dell’applicazione, in modo da sperimentare le funzioni senza partecipare formalmente alla prova pubblica.

La definizione dello standard avanza in modo aperto, con un processo documentato e accessibile a chiunque desideri seguirne l’evoluzione o contribuire con osservazioni. L’obiettivo dichiarato consiste nel costruire interfacce che qualsiasi browser dotato di capacità agentiche possa implementare, così da rendere più semplice il completamento dei compiti per le persone. Strumenti di ispezione dedicati permettono di simulare il dialogo con un agente, individuare le funzioni registrate su una pagina, richiamarle manualmente e verificare la correttezza degli schemi e dei dati restituiti, accelerando il lavoro di chi sviluppa.