WebMCP spiegato: cos'è, come funziona e perché cambia il web

Il 10 febbraio 2026 André Cipriani Bandarra di Google ha pubblicato un breve post su Chrome for Developers che presentava un'anteprima di WebMCP, il Web Model Context Protocol. La premessa era ingannevolmente semplice: e se i siti web potessero dire agli agenti AI esattamente cosa sono in grado di fare, invece di costringerli a indovinare?

Quell'unica idea (sostituire i tentativi alla cieca con un contratto strutturato tra siti web e AI) è ora sulla strada per diventare uno standard web formale. Ha il sostegno sia di Google sia di Microsoft, è in fase di incubazione presso il W3C e la sua prima implementazione in un browser è già disponibile in Chrome Canary.

Per capire perché è importante, pensa a cosa succede oggi quando chiedi a un assistente AI di prenotarti un volo. L'agente fa uno screenshot del sito della compagnia aerea, lo passa a un modello di visione, cerca di capire quale elemento sullo schermo sia il campo della partenza, ci scrive dentro, fa un altro screenshot, cerca il pulsante di ricerca, ci clicca, fa un altro screenshot e così via: decine di costose chiamate di inferenza solo per compilare un modulo. Se la settimana dopo la compagnia ridisegna la pagina, l'intero processo si rompe.

WebMCP sostituisce tutto questo ciclo con una sola chiamata di funzione: searchFlights("AMS", "JFK", "2026-06-15"). Il sito pubblica la funzione. L'agente la chiama. Fatto.

La community SEO ha reagito subito. L'esperto di SEO tecnica Dan Petrovic l'ha definito il più grande cambiamento nella SEO tecnica dai tempi dei dati strutturati, e WordLift ha colto bene l'analogia: se Schema.org ha fornito i sostantivi standardizzati del web, WebMCP ne fornisce i verbi standardizzati.

Cos'è WebMCP?

WebMCP sta per Web Model Context Protocol. È una proposta di standard web che permette ai siti di esporre le proprie funzionalità come "strumenti" (tool) strutturati e richiamabili, che gli agenti AI possono invocare direttamente tramite il browser.

La specifica è stata scritta congiuntamente da ingegneri di Google e Microsoft: Brandon Walderman, Leo Lee e Andrew Nolan per Microsoft, David Bokan, Khushal Sagar e Hannah Van Opstal per Google. Viene sviluppata all'interno del W3C Web Machine Learning Community Group, lo stesso gruppo del W3C in cui vengono incubati altri standard di machine learning a livello di browser, con l'obiettivo di diventare uno standard web ampiamente adottato.

A febbraio 2026 WebMCP è disponibile dietro un flag sperimentale in Chrome 146 Canary. Gli sviluppatori possono accedere a documentazione e demo iscrivendosi all'Early Preview Program di Google. Visto il ruolo attivo di Microsoft come co-autrice della specifica, è opinione diffusa che arriverà anche il supporto in Edge.

La specifica stessa descrive WebMCP come "un'interfaccia JavaScript che permette agli sviluppatori web di esporre le funzionalità della propria applicazione web come 'strumenti': funzioni JavaScript con descrizioni in linguaggio naturale e schemi strutturati, che possono essere invocate da agenti AI, assistenti del browser e tecnologie assistive."

Quell'ultima espressione, tecnologie assistive, è facile da trascurare ma è importante. Molto di ciò che rende il web difficile per gli agenti AI lo rende difficile anche per gli screen reader e gli altri strumenti di accessibilità. L'approccio a strumenti strutturati di WebMCP potrebbe migliorare in modo significativo entrambe le cose.

Il problema che WebMCP risolve

Oggi gli agenti AI interagiscono con i siti web in due modi principali, ed entrambi hanno limiti strutturali.

Gli agenti visivi fanno screenshot delle pagine web, li passano a modelli di visione e cercano di individuare pulsanti e campi dei moduli analizzando i pixel. Ogni interazione richiede un nuovo screenshot e una nuova chiamata di inferenza. Una semplice ricerca di prodotti può richiedere una dozzina di passaggi avanti e indietro. Se il layout del sito cambia anche di poco (un restyling, un test A/B, una dimensione dello schermo diversa) l'agente può fallire.

Gli agenti basati sul DOM analizzano l'HTML grezzo della pagina e l'albero di accessibilità per estrarre dati e attivare eventi. È più affidabile dell'analisi dei pixel, ma costringe comunque l'agente a consumare una grossa fetta della finestra di contesto per leggere la struttura della pagina, e lo obbliga a ricostruire a ritroso cosa fa davvero ogni elemento. Un <button> con l'etichetta "Vai" potrebbe significare cerca, invia, naviga o elimina: l'agente deve dedurlo dal contesto.

Entrambi gli approcci condividono lo stesso difetto di fondo: l'AI cerca di usare un'interfaccia pensata per gli esseri umani, mai progettata per le macchine. Come dice la specifica di WebMCP, "anche quando gli agenti ci riescono, operazioni semplici richiedono spesso più passaggi e possono essere lente o inaffidabili."

WebMCP offre una terza strada. Invece di lasciare che sia l'agente a capire cosa può fare un sito, è il sito a dichiarare esplicitamente le proprie capacità, e l'agente le richiama direttamente.

Come funziona WebMCP

WebMCP introduce una nuova API del browser: navigator.modelContext. Attraverso questa API un sito registra degli "strumenti": funzioni JavaScript con descrizioni in linguaggio naturale e schemi di parametri tipizzati. Nel loro insieme, queste definizioni formano quello che è stato chiamato il Tool Contract del sito: un menu leggibile dalle macchine di tutte le azioni che un agente AI può compiere su quella pagina.

La specifica offre due modi complementari per definire questi strumenti.

L'API dichiarativa (basata su HTML)

È la strada più semplice. Gli sviluppatori aggiungono nuovi attributi ai moduli HTML esistenti e il browser li converte automaticamente in strumenti richiamabili dagli agenti. Senza bisogno di JavaScript.

<form toolname="searchFlights"
      tooldescription="Search for available flights between airports">
  <input name="origin" type="text" required pattern="[A-Z]{3}">
  <input name="destination" type="text" required pattern="[A-Z]{3}">
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

Gli attributi toolname e tooldescription sono le uniche aggiunte. Il browser legge la struttura già presente nel modulo (nomi dei campi, tipi, pattern di validazione, campi obbligatori) e genera uno schema che un agente AI può capire e invocare. Per i siti che hanno già moduli ben strutturati, è sorprendentemente vicino a un aggiornamento plug-and-play.

Quando un agente invoca uno strumento dichiarativo, il browser genera un SubmitEvent con la proprietà agentInvoked impostata a true. Questo permette al backend di distinguere gli invii fatti da persone da quelli fatti da agenti: utile per le analytics, per il rate limiting o per restituire dati in un formato ottimizzato per le macchine invece che in HTML renderizzato.

L'API imperativa (basata su JavaScript)

Per le interazioni che vanno oltre l'invio di un modulo (flussi dinamici in più passaggi, elaborazione di dati in tempo reale, logica condizionale) gli sviluppatori registrano gli strumenti via codice:

navigator.modelContext.registerTool({
  name: "getFlightStatus",
  description: "Check real-time status of a specific flight",
  schema: {
    type: "object",
    properties: {
      flightNumber: { type: "string", description: "IATA flight number" },
      date: { type: "string", format: "date" }
    },
    required: ["flightNumber"]
  },
  handler: async ({ flightNumber, date }) => {
    const status = await flightAPI.getStatus(flightNumber, date);
    return { status: status.state, gate: status.gate, delay: status.delay };
  }
});

Così si ha il pieno controllo dal codice. Gli sviluppatori possono aggiungere e rimuovere strumenti dinamicamente in base allo stato dell'applicazione, mostrando capacità diverse a seconda che l'utente abbia effettuato l'accesso, della pagina in cui si trova o del punto raggiunto in un flusso. Soprattutto, le funzioni handler possono riutilizzare la stessa logica frontend che già alimenta l'interfaccia del sito. Non stai costruendo un livello di integrazione separato: stai esponendo ciò che hai già costruito.

Il browser come intermediario

Una delle scelte progettuali più importanti di WebMCP è che il browser fa da intermediario in tutta la comunicazione tra il sito e l'agente. Il sito registra gli strumenti tramite navigator.modelContext. Il browser li presenta all'agente nel formato di cui l'agente ha bisogno. Sito e agente non parlano mai direttamente.

Come ha spiegato Patrick Brosset del team di Microsoft Edge: "È il browser che parla con l'agente. La specifica usa il termine 'Model context provider'. Tramite navigator.modelContext la tua pagina fornisce il contesto, cioè gli strumenti che un agente AI poi usa, ma è il browser che si occupa del protocollo al posto tuo."

Questa architettura risolve tre problemi in un colpo solo.

L'autenticazione viene ereditata. Gli strumenti vengono eseguiti all'interno della scheda del browser, nel contesto della sessione già attiva dell'utente. Se hai effettuato l'accesso a un sito di e-commerce, l'agente ha accesso alla stessa sessione: niente flussi OAuth separati, niente chiavi API, niente gestione dei token.

L'utente mantiene il controllo. Tutto avviene all'interno della scheda visibile del browser, quindi l'utente può vedere cosa sta facendo l'agente. Per le azioni sensibili (acquisti, invio di dati personali, eliminazioni) la specifica include agent.requestUserInteraction(), che mette in pausa l'esecuzione e chiede al browser di ottenere una conferma esplicita dell'utente prima di procedere.

Indipendenza dalla piattaforma. Che l'agente in visita giri su ChatGPT, Claude, Gemini o su un modello aziendale personalizzato, il Tool Contract del sito rimane lo stesso. È il browser a normalizzare l'interazione.

Da dove viene WebMCP

WebMCP non è nato in Google né in Microsoft. È nato dalla frustrazione di un ingegnere di Amazon.

All'inizio del 2025 Alex Nahas stava costruendo agenti AI interni ad Amazon usando il Model Context Protocol (MCP) di Anthropic. Amazon aveva messo in piedi quello che in pratica era un unico, enorme server MCP che esponeva migliaia di strumenti sui suoi servizi interni. "Dovevi disattivarli con comandi di processo nella stringa di connessione", ha raccontato Nahas ad Arcade.dev. Era scomodo, ma il vero ostacolo era l'autenticazione. La specifica di MCP aveva adottato OAuth 2.1, che praticamente nessun servizio interno di Amazon aveva implementato. Ogni servizio aveva il proprio sistema di autenticazione, e nessuno parlava OAuth.

Poi Nahas ha avuto un'intuizione: il browser aveva già risolto questo problema. I dipendenti di Amazon avevano accesso a tutti i servizi interni tramite un'autenticazione federata basata sul browser. Se si potevano eseguire strumenti in stile MCP dentro la scheda del browser, si ereditava tutta quell'autenticazione gratis.

Ha costruito MCP-B (Model Context Protocol for Browser) come proof of concept. Funzionava. L'ha reso open source.

Nel frattempo, ingegneri di Google e Microsoft lavoravano in modo indipendente su problemi simili. I team sono entrati in contatto tramite il W3C, sono arrivati a una specifica unificata entro agosto 2025 e l'hanno pubblicata su GitHub. A settembre 2025 il W3C Web Machine Learning Community Group l'ha accettata come deliverable formale. A febbraio 2026 Google ha rilasciato la prima implementazione in un browser.

Una sfumatura importante: nonostante il nome, WebMCP non è tecnicamente MCP. Come ha spiegato Nahas, inizialmente aveva spinto per portare nel browser l'intero protocollo MCP (JSON-RPC compreso), ma il gruppo di lavoro ha scelto di non legarsi troppo strettamente alla specifica di Anthropic. WebMCP condivide il modello concettuale di MCP (strumenti con schemi che gli agenti richiamano), ma è uno standard distinto e nativo del browser.

WebMCP vs MCP vs NLWeb

I nomi creano confusione, quindi vale la pena chiarire come si colloca WebMCP rispetto agli altri protocolli dell'ecosistema degli agenti AI.

MCP di Anthropic (Model Context Protocol) è un protocollo di backend. Collega le piattaforme AI a servizi esterni tramite integrazioni lato server basate su JSON-RPC. Se vuoi che Claude o ChatGPT interroghino il database della tua azienda, è con MCP che costruisci quel collegamento. Richiede un'infrastruttura server dedicata.

NLWeb di Microsoft, annunciato a maggio 2025, offre ai siti un'interfaccia di interrogazione in linguaggio naturale e fa sì che ogni sito funzioni come server MCP per gli agenti dell'ecosistema più ampio. Opera a livello di API: gli agenti parlano direttamente con il backend del sito.

WebMCP gira interamente lato client, nel browser. Il sito registra gli strumenti al caricamento della pagina. Il browser li espone agli agenti in visita. Nessuna infrastruttura backend necessaria. L'autenticazione è ereditata dalla sessione dell'utente.

I tre sono complementari, non concorrenti. Un'azienda potrebbe usare MCP per integrazioni profonde di backend, NLWeb per l'accesso in linguaggio naturale a livello di API e WebMCP per le interazioni a livello di browser in cui l'utente è presente. La differenza chiave: WebMCP è l'unico che permette agli sviluppatori di riutilizzare il codice frontend esistente e non richiede alcuna nuova infrastruttura lato server.

Perché è importante

Ciò che rende significativo WebMCP non è tanto una singola funzionalità quanto la combinazione di diverse caratteristiche.

Costo per interazione drasticamente più basso. Una sola chiamata strutturata sostituisce ciò che prima richiedeva decine di scambi tra screenshot, inferenza dei modelli di visione e parsing del DOM. I primi resoconti indicano una riduzione di circa il 67% del carico computazionale rispetto agli approcci con agenti visivi. Per i siti ad alto traffico che gestiscono migliaia di interazioni con agenti al giorno, il risparmio è considerevole.

Affidabilità slegata dal design. Le chiamate di funzione strutturate non si rompono quando un designer sposta un pulsante, rinomina una classe CSS o lancia un test A/B. Il Tool Contract offre un'interfaccia stabile, indipendente dal layout visivo: agenti e web designer possono quindi evolvere ciascuno per conto proprio.

Impegno minimo per gli sviluppatori. L'API dichiarativa richiede di aggiungere due attributi HTML ai moduli esistenti. Niente JavaScript, niente nuovi endpoint, nessuna documentazione API da mantenere. Per la maggior parte dei siti, la strada per diventare "pronti per gli agenti" è più breve della maggior parte delle ottimizzazioni SEO.

Accessibilità come effetto collaterale. Le stesse definizioni strutturate che aiutano gli agenti AI aiutano anche le tecnologie assistive. Screen reader e altri strumenti di accessibilità affrontano molte delle stesse difficoltà degli agenti AI quando cercano di capire cosa fa una pagina web, non solo cosa dice. WebMCP potrebbe migliorare in modo concreto entrambe le cose.

Settori e casi d'uso

La documentazione dell'anteprima di Google mette in evidenza diversi casi d'uso principali, tutti legati a flussi utente strutturati e in più passaggi.

L'e-commerce è il beneficiario più ovvio. Invece di un agente AI che arranca tra filtri di prodotto, selettori di taglia e flussi di checkout, un negozio espone strumenti come searchProducts(query, priceRange, category), addToCart(productId, quantity, size) e checkout(paymentMethod). L'intero percorso dalla scoperta all'acquisto diventa una serie di chiamate di funzione pulite. Per le aziende questo potrebbe tradursi in tassi di conversione da agenti decisamente più alti.

Viaggi e ospitalità sono un'applicazione naturale. Ricerca voli, prenotazione hotel e noleggio auto sono transazioni strutturate con molti parametri, che si traducono direttamente in definizioni di strumenti. Google ha citato espressamente la prenotazione di viaggi tra i principali casi d'uso già verificati.

I prodotti SaaS possono esporre agli agenti i propri flussi di lavoro principali. Immagina di dire a un assistente AI "crea una nuova bacheca di progetto con tre colonne e invita il mio team" e di vederlo eseguire tutto tramite chiamate strutturate invece che con clic e battiture simulate.

I portali di assistenza clienti possono definire strumenti per aprire ticket, verificarne lo stato e classificare i problemi. Un agente che può chiamare direttamente createTicket(category, urgency, description) è molto più affidabile di uno che deve attraversare visivamente un modulo di assistenza in più passaggi.

Le implicazioni per la SEO

La forte reazione della community SEO a WebMCP non è hype: riflette un cambiamento strutturale nel modo in cui i siti vengono scoperti e utilizzati.

L'analogia con Schema.org è utile. Quando sono arrivati i dati strutturati, hanno dato ai motori di ricerca un modo standardizzato per capire cosa significa un contenuto. I siti che li hanno adottati per primi hanno ottenuto rich snippet, posizionamenti nei knowledge panel e una migliore visibilità nella ricerca. Chi non l'ha fatto ha accumulato uno svantaggio che ha richiesto anni per essere colmato.

WebMCP fa qualcosa di parallelo, ma per un'epoca diversa. Dà agli agenti AI un modo standardizzato per capire quali azioni supporta un sito. Man mano che gli agenti diventano un canale primario attraverso cui le persone interagiscono con il web (prenotare viaggi, fare acquisti, gestire servizi), i siti con Tool Contract chiari e affidabili saranno quelli con cui gli agenti potranno lavorare con sicurezza.

Questo crea un nuovo tipo di dinamica competitiva. Se un agente AI può chiamare direttamente bookFlight() su un sito di viaggi ma deve farsi strada a forza di pixel-scraping su un altro, l'opzione strutturata sarà più veloce, più economica e meno soggetta a errori. Col tempo quel vantaggio di affidabilità si accumula: gli agenti (e le piattaforme che li ospitano) indirizzeranno naturalmente gli utenti verso i siti con cui è più facile ed economico interagire.

Per le aziende, essere pronti per WebMCP potrebbe diventare importante quanto lo è stato il design responsive per il mobile dieci anni fa. Non da un giorno all'altro, ma in modo costante, man mano che il supporto dei browser si allarga e le interazioni mediate dagli agenti crescono.

Come iniziare

WebMCP è in anteprima, il che significa che la finestra per chi vuole adottarlo per primo è aperta adesso.

Analizza i flussi chiave del tuo sito. Individua le azioni principali degli utenti (ricerca, prenotazione, checkout, invio di moduli, gestione dell'account) che trarrebbero vantaggio dall'essere esposte come strumenti. Parti dalle transazioni di maggior valore.

Comincia con l'API dichiarativa. Se hai moduli HTML puliti e ben strutturati, aggiungere gli attributi toolname e tooldescription è la strada più rapida. Non serve JavaScript e le modifiche al codice sono minime.

Iscriviti all'Early Preview Program. L'EPP di Google dà accesso a documentazione completa, demo e strumenti di test. Puoi iscriverti tramite il sito Chrome for Developers.

Testa in Chrome Canary. Attiva il flag "WebMCP for testing" in Chrome 146 Canary. Il Model Context Tool Inspector di Google offre strumenti di debug per validare le definizioni dei tuoi strumenti.

Esplora l'API imperativa per i flussi complessi che richiedono la registrazione dinamica degli strumenti o una logica in più passaggi.

Se vuoi iniziare a sviluppare prima che il supporto nativo dei browser sia ampiamente disponibile, il polyfill MCP-B di Alex Nahas (@mcp-b/global) ti permette di registrare strumenti con navigator.modelContext.registerTool() già oggi. Funziona con i framework frontend di tool calling esistenti come CopilotKit, AGUI e SystintUI. La documentazione completa è su docs.mcp-b.ai.

La specifica del W3C è disponibile su GitHub.

Cosa succederà ora

La specifica è ancora una bozza, ma la direzione è chiara.

Il rilascio ufficiale nei browser è previsto tra la metà e la fine del 2026. Google I/O e Google Cloud Next sono le occasioni più probabili per annunci di più ampio respiro. Dato che Microsoft è co-autrice della specifica, il supporto in Edge dovrebbe seguire i tempi di Chrome. Patrick Brosset del team di Edge ha segnalato esplicitamente un impegno continuativo: "Nel team di Edge ci teniamo a coinvolgere non solo le persone, ma anche gli sviluppatori. Ecco perché WebMCP ci sta a cuore."

L'API continua a evolversi. L'interfaccia è già passata dal precedente window.agent a window.navigator.modelContext, e funzionalità come agent.requestUserInteraction() sono state aggiunte dopo la proposta iniziale di agosto 2025. La community del W3C sta perfezionando attivamente la specifica sulla base dei test nel mondo reale.

Il supporto multimodale è nella roadmap dell'ecosistema MCP più ampio. Le versioni future del protocollo dovrebbero gestire immagini, video e audio: gli agenti non si limiteranno a leggere e scrivere, ma interpreteranno contenuti visivi e audio all'interno dello stesso framework.

La comunicazione tra agenti è la prossima frontiera. La specifica attuale si concentra sull'interazione tra utente e agente tramite il browser, ma la roadmap include scenari in cui gli agenti delegano compiti ad altri agenti attraverso più servizi e pagine.

Domande frequenti

WebMCP è la stessa cosa dell'MCP di Anthropic? No. Condividono un modello concettuale (strumenti con schemi che gli agenti possono richiamare), ma WebMCP è uno standard distinto. Non usa JSON-RPC, gira interamente nel browser (non su server di backend) ed è stato progettato specificamente per la piattaforma web. I due sono complementari: un'azienda potrebbe adottarli entrambi per casi d'uso diversi.

Quali browser supportano WebMCP? A febbraio 2026 WebMCP è disponibile in Chrome 146 Canary dietro il flag "WebMCP for testing". Il supporto in Edge è ampiamente atteso, visto il ruolo di Microsoft come co-autrice della specifica. Il rilascio ufficiale è previsto tra la metà e la fine del 2026.

Devo riscrivere il mio sito? No. L'API dichiarativa ti permette di aggiungere il supporto a WebMCP inserendo due attributi HTML nei moduli esistenti. Per i siti con HTML pulito e ben strutturato, le modifiche sono minime. L'API imperativa richiede JavaScript, ma può riutilizzare la logica frontend esistente.

Gli agenti AI possono compiere azioni senza il permesso dell'utente? Non per come è progettato. WebMCP include agent.requestUserInteraction(), che mette in pausa l'esecuzione per chiedere la conferma dell'utente sulle azioni sensibili. La specifica si basa sul principio che nessuna azione con conseguenze debba avvenire senza che l'utente ne sia consapevole e abbia dato il suo consenso.

WebMCP migliora l'accessibilità? Potenzialmente sì. Le definizioni strutturate che aiutano gli agenti AI a capire cosa fa una pagina possono aiutare anche gli screen reader e le altre tecnologie assistive. La specifica del W3C elenca esplicitamente le tecnologie assistive come caso d'uso di riferimento, accanto agli agenti AI.

Che effetto ha WebMCP sulla SEO? Il quadro completo si sta ancora delineando, ma i parallelismi strutturali con Schema.org sono evidenti. Man mano che gli agenti AI diventano un canale di transazione e di scoperta, i siti con Tool Contract ben definiti saranno più facili ed economici da usare per gli agenti, creando un vantaggio naturale simile a quello di cui hanno goduto nella ricerca i primi ad adottare i dati strutturati.

In conclusione

Per trent'anni il web è stato un luogo pensato per occhi e mani umane. Ogni pagina, ogni pulsante, ogni modulo presuppone che dall'altra parte ci sia una persona. WebMCP è il primo tentativo serio, sostenuto da uno standard, di rendere il web comprensibile e utilizzabile in modo nativo dagli agenti AI, senza togliere alle persone il controllo.

Siamo ancora agli inizi. La specifica è una bozza. Il supporto dei browser è sperimentale. Ma le fondamenta sono solide: due dei più grandi produttori di browser al mondo che collaborano tramite il W3C, un'implementazione funzionante già disponibile per i test e un'esperienza per gli sviluppatori abbastanza semplice da permettere alla maggior parte dei siti di partire con due attributi HTML.

Le aziende che hanno capito presto l'importanza dei dati strutturati hanno guadagnato anni di vantaggio competitivo nella ricerca. La stessa finestra si sta aprendo ora con WebMCP, e non resterà aperta per sempre.