WebMCP a ottobre 2026: rendere un sito utilizzabile dagli agenti IA e cosa significa davvero l'origin trial

WebMCP permette a una pagina web di consegnare a un agente IA un breve elenco di cose che può fare, ciascuna con un nome, una descrizione e uno schema di input, invece di lasciare che l'agente ricostruisca la pagina da screenshot e DOM. Un agente che trova uno strumento check_order_status può chiamarlo con un numero d'ordine. Senza, deve individuare il campo giusto e cliccare il pulsante giusto.

Questa è la promessa. Il quadro al 22 ottobre 2026 è più ristretto di quanto suggeriscano gran parte degli articoli in circolazione. WebMCP è una proposta di un W3C Community Group, non uno standard. Chrome lo gestisce come origin trial, senza che sia stata presa alcuna decisione di rilasciarlo. Un solo agente rivolto ai consumatori chiama gli strumenti (il browser integrato nell'app desktop di ChatGPT), e quell'agente ignora la versione dichiarativa basata sui moduli, che l'8 ottobre è stata tolta dalla specifica. Il team del motore di Safari si oppone alla proposta; Mozilla è neutrale.

Questo articolo è per sviluppatori e product owner che devono decidere se aggiungere WebMCP adesso. Spiega cos'è l'API, chi la chiama, come attivarla per i visitatori reali, come scrivere strumenti che non mettano un'arma carica in mano a un agente e cosa sistemare per primo se volete che gli agenti usino il vostro sito.

Cos'è WebMCP

La specifica definisce un'API JavaScript su document.modelContext con cui una pagina registra strumenti: «L'API WebMCP consente alle applicazioni web di fornire agli agenti IA strumenti basati su JavaScript». Uno strumento ha un name, una description e una callback execute, e facoltativamente un title, un inputSchema (JSON Schema) e delle annotations. Quando l'agente chiama lo strumento, viene eseguito il codice della pagina, con la sessione dell'utente.

Su tre punti è facile sbagliarsi:

• Non è uno standard. Il documento è una Draft Community Group Report del Web Machine Learning Community Group, e lo dice: «Non è uno standard W3C né si trova sul percorso degli standard W3C». La documentazione di Chrome lo definisce «uno standard web proposto». La data del rapporto cambia ogni pochi giorni, a ottobre; i suoi editor lavorano per Microsoft e Google.
• Non c'è MCP al suo interno. La specifica dice che le pagine che lo usano «possono essere considerate server Model Context Protocol che implementano strumenti in script lato client», e poi che «non prescrive il formato in cui gli strumenti vengono esposti all'agente del browser». La valutazione di Mozilla è stata diretta: «Il nome è fuorviante ... Qui non c'è MCP». Uno strumento WebMCP non si collega al vostro server MCP di backend e non lo sostituisce.
• Non vi rende reperibili. La documentazione di Chrome elenca da sola questo limite: «I client e i browser devono visitare un sito direttamente per sapere se ha strumenti richiamabili». WebMCP aiuta un agente che è già sulla vostra pagina. Per farsi trovare non fa nulla.

L'API è limitata ai contesti sicuri ed è controllata da una Permissions Policy tools la cui allowlist predefinita è 'self', quindi un iframe cross-origin non può registrare strumenti a meno che la pagina che lo incorpora non lo consenta.

A che punto è, al 22 ottobre 2026

Chrome 156, l'ultima versione della finestra originale del trial, è arrivata sul canale stabile il 20 ottobre 2026. Chrome 162, la fine della proroga richiesta, è prevista sul canale stabile il 2 febbraio 2027. Dalla console del trial non è stato possibile confermare se la proroga sia già attiva, quindi regolatevi come se fosse probabile ma non certa.

La richiesta di proroga spiega perché Chrome vuole più tempo: «Il feedback dell'OT ha suggerito miglioramenti all'API, che stiamo implementando». Nello stesso thread Dominic Farolino di Google ha scritto che il team spera «di passare a I2S entro la finestra della proroga», cioè di chiedere il rilascio, e che «l'API imperativa è molto più popolare di quella dichiarativa, quindi stiamo investendo di più su di essa in risposta alle esigenze degli utenti». Ha citato anche un'API di continuazione, un'API di stabilità degli strumenti e dei limiti alla dimensione degli strumenti, in fase di prototipo. L'API con cui scrivete oggi cambierà.

Chi chiama davvero gli strumenti

Registrare strumenti non richiede nulla. Usarli richiede un agente, e l'elenco degli agenti è breve.

Le estensioni di prova di Chrome. La documentazione di Chrome propone due estensioni, tra cui il Model Context Tool Inspector, per provare gli strumenti nelle demo e sulle vostre pagine. Richiedono la vostra chiave API di un modello, e Chrome precisa: «Queste estensioni sono separate da Gemini in Chrome». Sono strumenti per sviluppatori, non clienti.

Il browser integrato di ChatGPT. Un messaggio di un dipendente di OpenAI sul suo forum per sviluppatori ha detto il 25 agosto 2026 che «i site tools sono l'implementazione di ChatGPT dello standard WebMCP proposto». La sua documentazione pone delle condizioni: modelli specifici, l'ultima app desktop, un amministratore che lo consenta negli spazi di lavoro Enterprise, nessuno spazio di lavoro Edu, e «la disponibilità dipende anche dal rilascio graduale». Elenca anche ciò che non supporta: «API dichiarativa: gli strumenti definiti tramite attributi di moduli HTML non sono disponibili come site tools», e gli strumenti registrati dentro gli iframe, anche same-origin. L'indicazione di OpenAI è chiara: «Usate JavaScript per registrare gli strumenti nella pagina di primo livello». La documentazione non dice se una pagina abbia bisogno di un token dell'origin trial di Chrome perché ChatGPT veda i suoi strumenti.

Gemini in Chrome. A maggio Google ha detto che «supporterà presto le API WebMCP». Da allora non abbiamo trovato alcuna fonte primaria che dica che lo faccia. Per ora non basateci un piano.

Tutti gli altri ripiegano sul metodo di prima. Ogni agente, in ogni browser, continua a leggere le pagine alla vecchia maniera. Lo dice Chrome nella sua stessa valutazione dei rischi: «Gli agenti del browser in Chrome possono continuare a operare sui siti come prima, simulando i comportamenti dell'utente». OpenAI: «Se non è disponibile uno strumento adatto, l'agente può comunque usare le normali funzioni del suo browser». Un sito senza WebMCP non è invisibile agli agenti. Un sito con pulsanti rotti e campi senza etichetta è difficile per tutti.

L'API imperativa

È la versione definita dalla specifica, quella supportata da ChatGPT e quella che, secondo Chrome, gli sviluppatori preferiscono. Uno strumento racchiude una logica che la pagina ha già. Ecco una ricerca in sola lettura per un cliente autenticato, sul modello della documentazione di Chrome e del rilevamento delle funzionalità (feature detection) di OpenAI:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

Cosa conta, qui dentro:

• Nome, descrizione e schema sono ciò che legge il modello. Chrome raccomanda al massimo 500 caratteri per la descrizione di uno strumento, 150 per quella di un parametro, 30 per il nome di uno strumento o di un parametro e 1,5K caratteri per l'output di uno strumento, e precisa che «queste raccomandazioni sono soggette a modifiche». L'explainer della specifica avverte che «esporre troppi strumenti (ad esempio decine o centinaia) può degradare gravemente le prestazioni dell'agente»: registrate ciò di cui ha bisogno lo stato attuale della pagina e rimuovete il resto con il segnale dell'AbortController.
• Il secondo argomento di execute porta un AbortSignal, così una chiamata annullata può interrompere una richiesta in corso.
• Le annotazioni sono suggerimenti. readOnlyHint indica una ricerca. consequentialHint indica tutto ciò che prenota, acquista, invia, cancella o trasferisce, e la documentazione di Chrome dice che «consente ad agenti e browser di imporre richieste di conferma obbligatoria da parte dell'utente». untrustedContentHint indica un output che contiene recensioni, contenuti degli utenti o dati di terze parti. Da Chrome 156 esiste un'annotazione debugging.
• Anche il codice della pagina può elencare ed eseguire gli strumenti, con document.modelContext.getTools() e executeTool(), e quando l'elenco cambia viene emesso un evento toolchange. Gli argomenti convertiti in stringa JSON passati a executeTool() sono deprecati da Chrome 155.

React, Angular e Vue hanno ciascuno degli helper sperimentali, e il pacchetto npm webmcp-types fornisce le tipizzazioni TypeScript. I vecchi tutorial che chiamano navigator.modelContext sono superati: il 27 maggio 2026 la specifica ha spostato l'API su document.

L'API dichiarativa: nel trial di Chrome, fuori dalla specifica

La versione dichiarativa trasforma un modulo HTML esistente in uno strumento con due attributi. È allettante per i siti vecchi e ricchi di moduli, perché nient'altro deve cambiare:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

Nel trial di Chrome, «quando un agente chiama toolname, il browser porta in primo piano il modulo e ne compila i campi. Il modulo resta visibile all'utente». Il browser costruisce i parametri a partire dai controlli: i loro nomi, i loro <label>, required e le opzioni di un <select>. A meno che il modulo non abbia toolautosubmit, «l'utente deve fare clic manualmente su Invia per completare l'attività», che è ciò che serve per tutto quanto effettua un ordine o invia un lead. SubmitEvent.agentInvoked dice al vostro gestore che a compilare il modulo è stato un agente, e respondWith(), dopo preventDefault(), restituisce all'agente l'esito. Ascoltate gli eventi toolactivated e toolcancel su document.modelContext con addEventListener: window.ontoolactivated e window.ontoolcancel non sono supportati da Chrome 156.

Il problema è il suo stato. L'ultima modifica dell'explainer, l'8 ottobre 2026, si intitola «Remove declarative API from the spec for now» (togliere per ora l'API dichiarativa dalla specifica), e ora dice che una controparte dichiarativa «è in esame separatamente ... ma al momento non fa parte della specifica». ChatGPT non la supporta. Chrome la documenta ancora nel trial, e nel thread di Mozilla Farolino di Google ha sostenuto che «vediamo valore nella proposta dichiarativa semplicemente per i siti legacy, soprattutto quelli basati su moduli». Consideratela un esperimento di Chrome dentro un esperimento: va bene provarla, ma non è saggio farne l'unica strada.

Attivarlo per i visitatori reali

Un flag (chrome://flags/#enable-webmcp-testing) attiva WebMCP nel vostro browser per i test. Per i visitatori non fa nulla. Per loro la pagina ha bisogno di un token dell'origin trial.

1. Registrate l'origine sulla pagina del trial WebMCP di Chrome. Gli origin trial «sono pubblici e aperti a tutti gli sviluppatori», e un token «abilita una funzionalità per tutti gli utenti della vostra origine».
2. Servite il token su ogni pagina che deve esporre strumenti, come <meta http-equiv="origin-trial" content="..."> nell'<head> o come header di risposta Origin-Trial:. Un token può anche essere iniettato da script. Un token copre un'origine; una pagina può portarne diversi.
3. Rinnovatelo. Quando un trial viene prorogato, Chrome chiede a chi si è registrato di «fornire un nuovo token per ogni origine iscritta al trial», e «Chrome ignora i token non validi o scaduti». Un token scaduto fallisce in silenzio: gli strumenti semplicemente smettono di comparire.
4. Per Edge, registratevi separatamente sulla pagina del trial di Edge. I suoi termini chiedono che «dove possibile, accettiate di applicare il rilevamento delle funzionalità / il degrado graduale».

Anche gli audit WebMCP di Lighthouse richiedono la registrazione al trial, quindi un sito che li prova senza token li vedrà fallire.

Scrivere strumenti sicuri da chiamare

La sezione della specifica sulla sicurezza non è normativa ed è franca su dove ricada l'onere: impedire che un agente venga manipolato è «principalmente responsabilità del modello di sicurezza dell'agente stesso, più che qualcosa che questa specifica possa imporre in modo normativo». Sono comunque i vostri strumenti a decidere quanto danno possa fare un agente manipolato.

• I suggerimenti possono mentire, quindi gli agenti non si fidano. La specifica: «un sito malevolo può omettere o travisare quei suggerimenti». OpenAI: «Il nome di uno strumento, o la sua dichiarazione di leggere soltanto dati, non è la prova di ciò che fa», e ogni chiamata nel suo browser viene sottoposta a una verifica di sicurezza, con la conferma ancora richiesta per acquisti e azioni simili. Annotate comunque con onestà. È ciò che un agente prudente usa per decidere quando chiedere all'utente.
• Descrivete gli effetti con esattezza. Il cattivo esempio della stessa specifica è uno strumento descritto come «Finalizza il carrello attuale» che «in realtà avvia un acquisto. L'utente non intendeva acquistare nulla». Se uno strumento addebita una carta, la descrizione lo dice e consequentialHint vale true.
• Autorizzate sul server, ogni volta. Lo strumento viene eseguito con la sessione dell'utente: la specifica osserva che «gli agenti possono ereditare l'identità dell'utente e il contesto di autenticazione dal browser». Una chiamata a uno strumento è una richiesta di quell'utente e subisce gli stessi controlli. Il consiglio dell'explainer vale: «Validare in modo rigoroso nel codice, in modo permissivo nello schema», perché i fallimenti rigorosi dello schema possono bloccare gli agenti.
• Mettete in conto la prompt injection. La specifica la elenca per prima, in tre forme: istruzioni nascoste nei metadati dello strumento, nell'output dello strumento e attacchi che usano gli strumenti come bersaglio. L'output che contiene testi scritti da altri (recensioni, messaggi, domande sui prodotti) va sotto untrustedContentHint e va restituito come dato, non come prosa che un agente potrebbe scambiare per istruzioni.
• Escludete le pagine in modo deliberato. Un header Permissions-Policy: tools=() rende l'API non disponibile per un documento e per tutto ciò che incorpora. Le impostazioni dell'account, le pagine di pagamento e le schermate di amministrazione sono candidate.

Un'avvertenza sulla documentazione di Chrome: la sua pagina sulla sicurezza dice che la bozza include un metodo requestUserInteraction() per chiedere all'utente un intervento a metà di uno strumento. La bozza della specifica del 20 ottobre 2026 non ha un metodo simile, e l'explainer elenca ancora la conferma dell'utente tra le questioni aperte. Non progettate in base a esso.

A cosa si oppongono gli ingegneri di Safari e di Firefox

Le obiezioni vale la pena leggerle anche se sviluppate solo per Chrome, perché descrivono come WebMCP possa andare storto nella pratica.

La posizione di WebKit, pubblicata il 3 giugno 2026, sostiene che le pagine difficili da usare vadano sistemate in HTML e ARIA, «dove l'utente, la tecnologia assistiva e gli agenti ne traggono tutti beneficio», e che con gli strumenti «la fragilità si sposta soltanto dal DOM alle descrizioni degli strumenti». Tratta un agente come una tecnologia assistiva che non dovrebbe essere messa in evidenza: «WebMCP fa l'opposto, rendendo “sta guidando un agente” un fatto osservabile». E osserva che la proposta «non ha alcun modello di consenso o di reversibilità per le azioni con conseguenze».

Mozilla si è assestata sulla posizione neutrale ad agosto: WebMCP «introduce un'astrazione potenzialmente preziosa», ma «apre una superficie le cui dinamiche nel mondo reale lasciano troppe questioni aperte per sostenerla senza riserve». Avverte che i siti potrebbero «fornire strumenti che non corrispondono all'esperienza di un utente sulla pagina», per esempio per «introdurre una prompt injection invisibile agli utenti tipici». Singoli ingegneri di Mozilla hanno mostrato interesse per una primitiva imperativa di chiamata di funzioni; non è un'approvazione di Mozilla.

Chrome stesso valuta bassa, per gli utenti, la probabilità che gli altri motori non adottino WebMCP. Il rovescio della medaglia è che oggi un sito non ottiene nulla, in Safari o Firefox, dall'aggiunta di strumenti.

Cosa funziona oggi per ogni agente

Ogni agente di browser legge screenshot, HTML e albero di accessibilità. La guida di web.dev di Google sui siti adatti agli agenti dice che gli agenti «usano il DOM e l'albero di accessibilità per ottenere un elenco pulito e strutturato degli elementi interattivi, e poi lo confrontano con un rendering visivo». Il suo elenco pratico è breve:

• Usate veri elementi <button> e <a>, non <div> e <span> cliccabili.
• Collegate ogni <label> al proprio input con for.
• Nessun overlay trasparente sopra gli elementi interattivi, e nulla di interattivo più piccolo di 8 pixel quadrati.
• Un layout stabile, che non si sposti mentre l'agente sta per cliccare.

La sua conclusione: «Tutto ciò che suggeriamo per rendere un sito “pronto per gli agenti” migliora il sito anche per le persone». È anche, quasi parola per parola, ciò che WebKit chiede al posto di WebMCP. Se il vostro checkout non supera un audit di accessibilità, sistemate quello prima di scrivere un solo strumento.

Lighthouse ha una categoria Agentic Browsing dalla versione 13.2.0 (1° maggio 2026), disponibile in Chrome dalla versione 150 e abilitata per la PageSpeed Insights API in Lighthouse 13.4.1 (20 luglio 2026). Controlla il sottoinsieme di audit di accessibilità che contano per le macchine, la stabilità del layout, gli strumenti WebMCP registrati e i moduli che ne sono privi, la validità dello schema e la presenza di un file llms.txt. Chrome la definisce «informativa e priva di benchmark»: non c'è un punteggio da 0 a 100. Quanto a llms.txt, la guida della Ricerca Google è che ignora questi file: aggiungerne uno «non danneggerà né aiuterà la visibilità o il posizionamento del vostro sito nella Ricerca Google». Il fatto che Lighthouse controlli il file non cambia le cose.

Conviene aggiungere WebMCP adesso?

Su Shopify con un tema Liquid: nessun lavoro. Gli strumenti di storefront, carrello e checkout di Shopify sono già attivi, «non c'è nulla da installare o configurare», con la precisazione di Shopify che «il supporto agli agenti è attualmente limitato ai browser basati su Chromium tramite un origin trial». Gli storefront headless sono coperti solo dalla developer preview di Hydrogen. Non abbiamo trovato altre piattaforme di commercio, prestatori di servizi di pagamento o CDN che attivino WebMCP per i propri clienti.

Su un sito personalizzato, headless o legacy: dipende da chi sono i vostri utenti.

• Se i vostri clienti o il vostro personale usano il browser dell'app desktop di ChatGPT, gli unici strumenti che li raggiungono sono quelli imperativi nella pagina di primo livello. Partite da due o tre strumenti di sola lettura attorno all'attività più comune (stato dell'ordine, disponibilità, un preventivo), dietro il rilevamento delle funzionalità, con un token dell'origin trial, e misurate se qualcuno li chiama.
• Se volete sperimentare a basso costo in Chrome, gli attributi dichiarativi sui moduli esistenti sono questione di poche ore di lavoro. Non fermatevi lì: ChatGPT non li vedrà, e la specifica non li contiene più.
• Se non avete alcuna prova che gli agenti vi visitino, sistemate prima semantica, etichette e layout. Quel lavoro aiuta ogni agente e ogni persona che usa una tecnologia assistiva, e nulla di esso andrà buttato quando l'API cambierà.

In ogni caso, mantenete completa l'interfaccia normale. Il consiglio di OpenAI: «Mantenete l'interfaccia normale per le persone e per i browser che non supportano WebMCP».

Cosa potrebbe cambiare

• Un Intent to Ship. Il team di Chrome spera di chiederlo entro la finestra della proroga, che termina con Chrome 162 (2 febbraio 2027) se la proroga verrà confermata. Il rilascio eliminerebbe la necessità dei token in Chrome.
• La forma dell'API. Sono in fase di prototipo un'API di continuazione (risultati che arrivano alla pagina successiva dopo una navigazione), un'API di stabilità degli strumenti e dei limiti di dimensione. Le versioni recenti hanno già rimosso window.ontoolactivated e gli argomenti convertiti in stringa.
• Il destino dell'API dichiarativa. Fuori dalla specifica «per ora», ancora nel trial di Chrome.
• Chi chiama gli strumenti. Il supporto di Gemini in Chrome è stato annunciato ma non rilasciato. La pagina sullo stato di implementazione della specifica elenca WebMCP per le web app sugli occhiali Ray-Ban Display di Meta come in arrivo, e un supporto sperimentale nell'assistente Leo di Brave.

Se aggiungete strumenti adesso, teneteli in un unico modulo, dietro il rilevamento delle funzionalità, così la prossima modifica sarà un solo intervento.

Dove trovare aiuto

Sviluppiamo le parti di un sito web e del suo backend che gli agenti toccano: strumenti che racchiudono la logica esistente di ordini, prenotazioni e account, un'autorizzazione che tratta la chiamata di un agente come qualsiasi altra richiesta di quell'utente, e le correzioni di semantica e accessibilità che rendono un sito utilizzabile prima ancora che esista uno strumento. Il nostro servizio di sviluppo di agenti IA e integrazione MCP comprende gli strumenti WebMCP e i server MCP di backend, che sono un'altra cosa nonostante il nome.

Se volete sapere cosa vede oggi un agente sul vostro sito, e se gli strumenti cambierebbero qualcosa per i vostri clienti, scrivete a office@c9group.dev.