Da un paio d’anni gli agenti AI usano i siti web nel modo più goffo possibile: guardandoli. Leggono il DOM, cercano di capire che cosa fa quel pulsante blu in alto a destra, simulano un clic, aspettano, rileggono la pagina, riprovano. In inglese la chiamano actuation, e funziona più o meno come funzionerebbe un collega che usa il tuo gestionale per la prima volta guardandolo da sopra la tua spalla, senza che nessuno gli spieghi niente.
Funziona, a volte. Ma ogni passaggio è aperto all’interpretazione, e ogni restyling del sito rompe tutto quello che l’agente aveva imparato.
WebMCP prova a ribaltare il rapporto. Invece di lasciare che l’agente deduca, è il sito a dichiarare: questi sono gli strumenti che ho, questi sono i parametri che accettano, questo è quello che restituiscono. Come una API, ma che vive dentro la pagina e gira nel browser dell’utente.
A che punto è WebMCP, al 1 settembre 2026 #
Prima di entrare nel codice, i fatti, perché su una tecnologia così nuova la differenza tra "esiste" e "esiste sul serio" è quasi tutto.
WebMCP è una proposta di standard, non uno standard. La documentazione
Chrome è stata pubblicata il 18 maggio 2026 e aggiornata il 1 settembre. Da
Chrome 149 è disponibile un origin trial, e a febbraio è stato annunciato un
programma di anteprima. In locale si attiva da chrome://flags/#enable-webmcp-testing.
Detto altrimenti: è un cantiere aperto, in un browser solo. Se leggi questo articolo tra sei mesi, verifica prima di fidarti.
Le due API #
Chrome propone due modi di dichiarare uno strumento. Sono pensati per due situazioni diverse, non uno come versione semplificata dell’altro.
Imperativa: JavaScript #
La prima registra strumenti a mano, con un nome, una descrizione, uno schema JSON degli input e una funzione che li esegue.
await document.modelContext.registerTool({
name: 'get_order_status',
description: 'Search orders in a given timeframe. Returns order number, shipping status and location',
inputSchema: {
type: 'object',
properties: {
timeframe: {
type: 'string',
enum: ['today', 'yesterday', 'last_7_days', 'last_30_days'],
description: 'Timeframe for the order lookup.',
},
},
required: ['timeframe'],
},
execute: async ({ timeframe }) => {
// Qui la tua logica: API, database, quello che serve.
},
});
Chi ha già scritto un tool per un modello riconosce la forma: è la stessa di MCP, di function calling, di tutto quello che negli ultimi due anni ha preso il posto dei prompt fatti di istruzioni.
La parte interessante non è questa. Sono le annotazioni, che sono tre e descrivono il carattere dello strumento, non quello che fa.
annotations: {
readOnlyHint: false, // non modifica niente?
consequentialHint: true, // fa qualcosa di irreversibile?
untrustedContentHint: false // restituisce roba scritta da estranei?
}
consequentialHint è quello che conta. Marcato a true, dice al browser e
all’agente che quello strumento prenota un volo, muove dei soldi o cancella dei
dati, e che prima serve una conferma esplicita dell’utente. È il punto in cui
questa proposta smette di essere una comodità per sviluppatori e diventa una
questione di sicurezza.
untrustedContentHint è il gemello meno ovvio: dice che il valore di ritorno
contiene testo scritto da qualcun altro, recensioni, commenti, contenuti di
terzi. Serve a segnalare che quel testo va trattato come dato e non come
istruzione, che è esattamente il buco da cui passa la prompt injection
indiretta. La documentazione Chrome sulla sicurezza dei tool è netta su questo
punto: i modelli sono probabilistici, è impossibile garantire che non cadano,
e gli attacchi documentati contro sistemi agentici funzionano anche sui modelli
più recenti.
Poi viene il contorno, che distingue una proposta pensata da un
annuncio: getTools() per elencare gli strumenti disponibili, executeTool()
per eseguirli a mano, un evento toolchange quando la lista cambia, e
AbortSignal sia per togliere la registrazione di uno strumento sia per
annullare un’esecuzione in corso.
await document.modelContext.registerTool(myTool, { signal: controller.signal });
controller.abort(); // lo strumento sparisce
Da Chrome 153 è possibile togliere la registrazione senza interrompere le esecuzioni già partite. È il genere di dettaglio che compare solo dopo che qualcuno ha provato a usarla dentro React e ha riscontrato problemi.
Dichiarativa: attributi HTML #
La seconda API non richiede JavaScript. Si annota un <form> che già esiste, e
il browser lo traduce in uno strumento.
<form toolname="supportRequestTool"
tooldescription="Submit a request for support."
action="/submit">
<label for="firstName">Nome</label>
<input type="text" name="firstName">
<select name="team" required
toolparamdescription="Determines what team this request is routed to.">
<option value="Customer happiness team">Voglio restituire un acquisto.</option>
<option value="Distribution team">Dov'è il mio pacco.</option>
</select>
<button type="submit">Invia</button>
</form>
Due attributi, e il browser genera da solo lo schema JSON: i name dei campi
diventano proprietà, le <option> diventano un anyOf con i titoli leggibili,
le <label> diventano le descrizioni. Togli toolname e lo strumento sparisce.
È anche il motivo per cui questa API mi convince più dell’altra: premia chi ha già scritto HTML fatto bene. Se i tuoi
campi hanno name sensati e ogni input ha la sua <label>, hai già quasi
finito. Se il tuo form è fatto di <div> con dei listener sopra, non hai
niente. È la stessa proprietà dell’accessibilità: non è una funzionalità da
aggiungere, è una conseguenza di come hai scritto la pagina.
Il resto della API dichiarativa è pensato per non perdere il controllo. Con
toolautosubmit il form si invia da solo, ma la tua validazione resta al suo
posto:
form.addEventListener('submit', (e) => {
e.preventDefault();
if (!myFormIsValid()) {
if (e.agentInvoked) { e.respondWith(myFormValidationErrorPromise); }
return;
}
if (e.agentInvoked) { e.respondWith(Promise.resolve('Search is done!')); }
});
e.agentInvoked dice se a premere sia stato un agente o una persona, e
respondWith() restituisce all’agente un risultato leggibile invece di
lasciarlo a indovinare guardando la pagina dopo. La specifica prevede anche due eventi,
toolactivated e toolcancel, e persino due pseudo-classi CSS,
:tool-form-active e :tool-submit-active, con cui Chrome disegna un contorno
tratteggiato sul form mentre l’agente ci lavora.
Quel contorno tratteggiato è la scelta di design più importante di tutta la proposta, e passa quasi inosservata: l’agente lavora sulla tua pagina, davanti all’utente, non da qualche parte in un server. L’utente vede il campo che si riempie. È il contrario di un agente che va a fare la spesa per conto tuo in una finestra che non esiste.
WebMCP non è MCP nel browser #
La confusione è frequente, e conviene chiarirla subito.
MCP è un protocollo per collegare un agente a sistemi esterni: database, API, servizi. Vive sul backend, parla spesso JSON-RPC, si implementa con un SDK. Funziona sempre, da qualsiasi piattaforma, che il tuo sito sia aperto o no.
WebMCP vive nel frontend e funziona solo mentre qualcuno è sulla tua pagina. La documentazione Chrome usa un paragone che rende bene: MCP è il call center, disponibile ovunque e a qualsiasi ora; WebMCP è il commesso esperto dentro il negozio, che però esiste solo se nel negozio ci sei entrato.
Non sono alternative, e nessuno dei due sostituisce l’altro. Il modo giusto di leggerli è: MCP espone i tuoi dati, WebMCP spiega la tua interfaccia. Un confronto con esempi aiuta a decidere quale dei due serva a un progetto.
I limiti, che sono tre e sono seri #
La documentazione Chrome li elenca senza girarci attorno, e sono la parte più utile di tutta la pagina.
Serve una scheda aperta. Le chiamate girano in JavaScript nel documento, quindi serve un contesto di navigazione visibile. Niente headless, niente agente che lavora di notte mentre dormi.
Le interfacce complesse costano. Se il tuo sito è una applicazione vera, non ti basta annotare due form: devi rifattorizzare, gestire lo stato, decidere quali strumenti registrare in quale schermata.
La scopribilità non è risolta. E questo è il vero problema. Un client o un browser scopre che hai degli strumenti solo visitando la tua pagina. Non esiste un registro né un file da mettere nella cartella principale: nulla segnala al mondo che "questo sito ha dei tool". Il che significa che WebMCP non ti porta agenti: serve solo a servire meglio quelli che sono già arrivati.
E allora conviene? #
Dipende da una domanda sola: sul tuo sito c’è qualcosa da fare, o solo qualcosa da leggere?
Se gestisci un e-commerce, un flusso di prenotazione, un’area assistenza, un configuratore di prodotto, allora sì. Hai una superficie transazionale vera, e la differenza tra un agente che ci azzecca e uno che si perde in mezzo ai tuoi filtri si misura in ordini. I compiti concreti, caso per caso, sono in cosa può già fare un agente AI sul tuo sito web.
Se hai un sito vetrina, un portfolio, un blog, allora no, e non per timidezza. Il motivo è che non esiste nulla da esporre. Il massimo che puoi dichiarare è "contattami" e "elenca le competenze", e per quelle un agente se la cava benissimo leggendo la pagina, cioè ciò che i modelli sanno fare meglio. Aggiungere WebMCP a un sito del genere significa scrivere codice per un problema che non hai.
Su questo sito, per essere concreti, la superficie utile è esattamente una: il form di contatto. Uno strumento solo. Quando lo avrò scritto lo annoterò, e mi interessa più come esperimento verificabile che come funzionalità utile: voglio vedere se un agente lo trova, se compila i campi giusti, e cosa succede quando sbaglia. Sarà il prossimo articolo, e conterrà risultati veri o non esisterà.
Nel frattempo, se vuoi provarci senza scrivere niente: l’estensione Model Context Tool Inspector mostra gli strumenti registrati su una pagina, li chiama a mano e verifica che lo schema JSON sia scritto bene. Le demo ufficiali sono tre, e coprono entrambe le API.
WebMCP e l’accessibilità: lo stesso lavoro #
Al di là di quanto durerà questa specifica, e delle probabilità che
document.modelContext si chiami così anche fra un anno, resta un’idea che vale
più della API.
Per trent’anni abbiamo scritto pagine per gli occhi, e poi abbiamo aggiunto un
secondo strato per chi non vede: alt, ruoli ARIA, ordine di tabulazione, HTML
semantico. Ogni volta con la stessa fatica, e ogni volta scoprendo che il secondo
strato migliorava anche il primo.
WebMCP è lo stesso lavoro, per un lettore nuovo. E la parte che mi convince è che
il conto lo paga soprattutto chi ha scritto male: se i tuoi form sono form, se i
campi hanno un nome, se ogni controllo ha la sua etichetta, sei già quasi a posto.
Se invece sono <div> con dei listener sopra, dovrai rifare tutto.
Non è un caso. È la terza volta che il web ci presenta lo stesso conto.
Domande frequenti su WebMCP #
Che cos’è WebMCP in parole semplici? #
È una proposta di standard web che permette a una pagina di dichiarare agli agenti AI quali azioni sa compiere, con un nome, una descrizione e uno schema JSON dei parametri. Invece di far dedurre all’agente a cosa serve un pulsante, il sito glielo dice. Chrome ne ha pubblicato la documentazione il 18 maggio 2026.
WebMCP sostituisce MCP? #
No, e non è nemmeno una sua estensione. MCP collega un agente a sistemi esterni e funziona sempre, da qualsiasi piattaforma, anche a sito chiuso. WebMCP vive nel frontend e funziona solo mentre qualcuno è sulla tua pagina. MCP espone i tuoi dati, WebMCP spiega la tua interfaccia. Si usano insieme.
Che differenza c’è tra API imperativa e dichiarativa? #
L’imperativa registra strumenti da JavaScript con
document.modelContext.registerTool(), e serve per azioni complesse o legate allo
stato dell’applicazione. La dichiarativa trasforma un <form> che già esiste in
uno strumento aggiungendo gli attributi toolname e tooldescription, e il
browser ne deduce da solo lo schema. Per un form la seconda basta quasi sempre.
Serve WebMCP su un sito vetrina? #
Quasi mai. Serve dove c’è qualcosa da fare, non qualcosa da leggere: un carrello, una prenotazione, un flusso di assistenza, un configuratore. Su un portfolio o un blog l’unica superficie plausibile è il form di contatto, e per il resto un agente se la cava leggendo la pagina, che è ciò che i modelli sanno fare meglio.
Quali browser lo supportano oggi? #
Solo Chrome, in origin trial da Chrome 149, più un flag per lo sviluppo locale in
chrome://flags/#enable-webmcp-testing. È una proposta in discussione attiva, non
uno standard stabile: la forma delle API può cambiare.
WebMCP è un rischio per la sicurezza? #
Sposta un rischio che esiste già. Gli agenti sono vulnerabili alla prompt
injection indiretta, cioè a istruzioni malevole nascoste dentro testo che il
modello legge come se fossero comandi. WebMCP non risolve il problema, ma dà due
strumenti per gestirlo: untrustedContentHint, che marca come non affidabile
l’output di uno strumento che restituisce contenuti di terzi, e
consequentialHint, che obbliga a una conferma dell’utente prima di un’azione
irreversibile. La documentazione Chrome è esplicita: dentro un modello linguistico
non è possibile garantire nulla.
Come faccio a provare i miei tool senza scrivere un agente? #
Con l’estensione Model Context Tool Inspector, che elenca gli strumenti registrati su una pagina, li chiama a mano e verifica che lo schema JSON sia interpretabile. Utile soprattutto per accorgersi che una descrizione ambigua manda l’agente sullo strumento sbagliato.
Fonti #
Documentazione WebMCP su developer.chrome.com, e le pagine su API imperativa, API dichiarativa, sicurezza dei tool, buone pratiche e confronto con MCP, più l’annuncio del programma di anteprima del 10 febbraio 2026.
Documentazione aggiornata al 1 settembre 2026, che e' la data dichiarata dalle pagine Chrome. Essendo una proposta in evoluzione, verifica prima di fidarti.