WebMCP: lo standard che vuole portare gli AI agent dentro il browser. Funzionerà davvero?

Nei titoli del weekend ho letto almeno cinque volte la formula "nuovo standard W3C per gli agenti nel browser". È una formula sbagliata, in modo abbastanza preciso da meritare una correzione. WebMCP, di cui sto per parlare, non è uno standard W3C. È un Draft Community Group Report, pubblicato sotto il Web Machine Learning Community Group. La distinzione non è formale: è la differenza tra una proposta in incubazione e qualcosa che il W3C ha effettivamente raccomandato. La prima cosa, la seconda no.

Detto questo, WebMCP è una proposta tecnicamente seria, firmata da Google e Microsoft, già shippata in Chrome 146 Early Preview. Quindi vale la pena leggerla. Solo che vale la pena leggerla per quello che è: una scommessa di due hyperscaler contro un mercato dove lo screen-based browsing degli agenti funziona già, MCP server-side ha già vinto, e Anthropic — il foundation lab che più di chiunque ha definito il pattern agenti-tool — non ha endorsato la proposta. Provo a leggerla onestamente.

Cosa è WebMCP, in pratica

WebMCP è un'API JavaScript che permette a un sito web di esporre "tool" direttamente agli agenti AI che girano nel browser. Un tool è una funzione con uno schema di input e output, esattamente come in MCP server-side. La differenza è che gira dentro la pagina, riusa la sessione autenticata dell'utente, e sostituisce screenshot + click con chiamate strutturate.

Tecnicamente la spec definisce due API. Una declarative, con attributi HTML machine-readable sui form. Una imperative, in JavaScript:

navigator.modelContext.registerTool({
  name: 'searchProducts',
  description: 'Cerca prodotti nel catalogo',
  inputSchema: {
    type: 'object',
    properties: {
      query: { type: 'string' },
      maxResults: { type: 'number' }
    }
  },
  handler: async ({ query, maxResults }) => {
    // logica della tua app
    return await fetchProducts(query, maxResults)
  }
})

L'idea è elegante. Invece di mostrare uno screenshot del tuo sito a un modello visivo che poi clicca a tentoni, l'agente chiama searchProducts({query: "scarpe", maxResults: 5}) e riceve dati strutturati. Meno token, meno errori, più velocità.

Sullo status W3C: gli editor della spec sono Brandon Walderman (Microsoft) e Khushal Sagar + Dominic Farolino (Google). Ultima pubblicazione del draft: 23 aprile 2026. È sotto il Web Machine Learning Community Group, che è un container per incubazione di idee. Non è sul Recommendation Track. Una Community Group Report non è uno standard W3C, è esplicitamente etichettata come "not endorsed by W3C or its members". Lo scrive il W3C stesso a fondo pagina di ogni report.

Lo dico una volta sola, poi lo do per assodato: chi titola "nuovo standard W3C" sta facendo marketing, non cronaca tecnica.

La timeline, perché aiuta

Tre date utili per capire dove siamo.

• Gennaio 2025: nasce MCP-B, esperimento privato di portare MCP nel browser come extension.
• Agosto 2025: Google e Microsoft pubblicano una proposta unificata che chiamano WebMCP.
• Settembre 2025: il W3C Web ML Community Group accetta formalmente la proposta come incubazione.
• 10 febbraio 2026: Chrome 146 ship la Early Preview. Blog firmato da André Cipriani Bandarra su Chrome for Developers.
• 23 aprile 2026: aggiornamento del Draft CG Report.

A giugno 2026 — oggi — WebMCP è entrato in un origin trial pubblico con Chrome 149: gli sviluppatori possono registrare il proprio sito, ricevere un token e testare l'API in produzione su utenti reali. Non è più solo Canary dietro flag. Al lancio del trial Google ha annunciato nove brand sperimentatori di prima fascia — Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, Target — e che Gemini in Chrome supporterà le API WebMCP direttamente. Edge ha annunciato supporto in roadmap; per Firefox e Safari le posizioni pubbliche al momento di questa scrittura non sono confermate da fonte primaria diretta, quindi non le tratto come committed. Secondo le note di preview di Chrome 150 in circolazione, navigator.modelContext verrebbe deprecato a favore di document.modelContext: lo segnalo come traccia da verificare sul Chrome Platform Status quando la build esce, non come fatto consolidato.

Il primo problema: l'89% di token efficiency è marketing

Il numero che gira ovunque è "89% di token in meno rispetto allo screen-based". Lo trovi sui blog di Google Chrome, lo trovi nei pezzi su Search Engine Land, lo trovi nei thread su LinkedIn. È un best case.

Il numero onesto viene da un paper su arXiv (2508.09171) che ha misurato 1.890 chiamate API live su task realistici. Risultato: riduzione media del 65% dei token (range 53,5%-78,6%), con qualità di risposta sostanzialmente invariata (97,9% contro 98,8% del baseline visivo). La riduzione di costo API misurata è del 34-63%, non l'89% marketing.

65% medio è comunque un grosso miglioramento. Va detto. Solo che 65% e 89% non sono lo stesso numero, e chi prende decisioni di product budget sulla base del numero sbagliato si ritrova un ROI dimezzato. La differenza nasce dal fatto che l'89% è la singola task ottimale (un form di checkout, parametri puliti, output strutturato), il 65% è la media su task miste che includono fallback al visivo e qualche overhead di registrazione tool.

Il secondo problema: Anthropic non c'è

WebMCP è co-firmato Google + Microsoft. Anthropic, che ha inventato MCP a novembre 2024 e lo ha portato a essere de facto lo standard server-side dell'industria, non ha rilasciato endorsement pubblico sulla proposta WebMCP. Non c'è un blog post, non c'è un commit nello spec repository, non c'è un nome di engineer Anthropic tra gli editor.

Questo non vuol dire che Anthropic abbia detto "no". Vuol dire che ha detto silenzio, mentre la sua roadmap MCP per il 2026 — pubblicata sul blog di engineering — si concentra su altre cose: OAuth e SSO server-side, streaming, code execution server-side. Computer use, dal canto suo, ha appena raggiunto il 72,5% su OSWorld-Verified con Claude Sonnet 4.6 (Opus 4.6 al 72,7%), che è livello umano medio sui task tipici. Tradotto: Anthropic ha già due stack agentici in produzione che coprono i casi d'uso di WebMCP, e nessuno dei due è WebMCP.

Sul peso dei due ecosistemi a giugno 2026, i numeri verificabili:

Il 12% di "adozione enterprise" che gira in alcuni report di settore è un dato di sondaggio sull'intenzione di fare POC. Non è una misura di traffico reale. Distinguere i due numeri è il minimo sindacale del giornalismo tecnico onesto.

Con l'origin trial di Chrome 149, Google ha aggiunto un dato narrativo importante: nove brand sperimentatori di prima fascia — Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, Target. Sono nomi che pesano: viaggi, prenotazioni, e-commerce, fisco, real estate, food delivery, retail. Non spostano l'1% di adozione reale, ma cambiano la conversazione sul tipo di siti che Google riesce a portare al tavolo. Resta da capire se sperimentano davvero in produzione su utenti reali o se è un'adesione di principio a un origin trial. La distinzione, ancora una volta, è il minimo sindacale.

Anthropic non ha incentivo a sostenere uno standard browser-side che non controlla e che, se vince, sposta parte del valore nei browser di Google e Microsoft. È una posizione razionale, è anche un problema politico serio per WebMCP: senza il foundation lab di riferimento per gli agenti, qualunque "standard" agentico ha un buco strutturale al centro.

Il terzo problema: lo screen-based è già qui e funziona

C'è una premessa implicita in WebMCP: "lo screen-based browsing degli agenti è troppo lento, troppo costoso, troppo fragile". Era vero nel 2024. Nel 2026 è meno vero.

• Claude computer use: in beta da ottobre 2024, GA con Sonnet 4.5/4.6.
• OpenAI Operator: lanciato gennaio 2025.
• Gemini visual reasoning: integrato in Gemini in Chrome.
• Browser-use e l'ecosistema open source dei wrapper per computer use.

Su OSWorld-Verified, il benchmark di riferimento per agenti che usano il computer, Claude Sonnet 4.6 sta al 72,5%. Il baseline umano oscilla tra 72% e 84% a seconda della categoria di task. Tradotto in italiano: gli agenti visivi sono già al livello di un utente medio sui task standard. Non perfetti, ma in produzione, su volumi reali, con SLA accettabili per molti casi d'uso.

Questo non rende WebMCP inutile. Lo rende un'ottimizzazione, non una rivoluzione. L'ottimizzazione è preziosa per il volume (e-commerce, search, checkout: i casi dove i 65% di token in meno si traducono in soldi veri). È irrilevante per la copertura ("agisci su un sito che non ha mai sentito parlare di te"), che resta dominio dello screen-based.

WebMCP arriva in un mercato in cui il problema che vuole risolvere è già parzialmente risolto da altri stack. Non è una cosa da poco.

Il parallelo storico: AMP, Open Graph, microformats

A questo punto la domanda interessante non è "WebMCP è una buona spec?". Sì, lo è. La domanda è "WebMCP verrà adottata?". E qui i precedenti storici sono più informativi del paper su arXiv.

AMP (Google, 2015). Tecnicamente solida, spinta con un incentivo SEO molto duro: badge fulmine nei risultati, posizione privilegiata in Top Stories. Adoption forzata, sviluppatori in rivolta. Maggio 2021: Google rimuove AMP come requisito per Top Stories con il Page Experience update. L'adozione crolla nei dodici mesi successivi. Oggi AMP è di fatto abbandonato.

Open Graph (Facebook, aprile 2010). Tecnicamente più semplice di AMP. Adottata massivamente, sopravvive ancora oggi. Perché? Perché Facebook (poi Twitter, LinkedIn, WhatsApp) dava un feedback visivo immediato: implementi og:title + og:image + og:description, e in cinque minuti vedi il tuo link condividere con anteprima graziosa al posto di un URL nudo. L'incentivo era nel volto del dev che vede il preview, non in un badge SEO promesso da Google.

microformats e RDFa (W3C, primi anni 2000). Tecnicamente elegantissimi. Adoption lentissima per anni. Mancava l'incentivo immediato per chi implementava.

La lezione, distillata: uno standard tecnicamente valido non è uno standard adottato. Serve un incentivo immediato e visibile per chi deve fare il lavoro di implementare. AMP ce l'aveva (SEO duro), Open Graph ce l'aveva (preview belli), microformats no.

Per WebMCP, l'incentivo immediato oggi non c'è. Il dev di un sito italiano che implementa WebMCP oggi vede zero traffico, perché gli agenti che parlano WebMCP sono Gemini in Chrome con flag attivo. Il dev vede invece il costo: due-quattro ore di lavoro per registrare tre-cinque tool su Next.js o React (i tutorial più seri sono allineati su questo ordine di grandezza), più la manutenzione, più la compliance EU. ROI: negativo nel breve.

L'incentivo potrebbe arrivare quando Google decide che Gemini in Chrome privilegia siti WebMCP-enabled in qualche modo SEO-rilevante. È esattamente il pattern AMP. È un pattern che ha funzionato per cinque anni e poi è collassato sotto il peso della rivolta dei dev. La domanda 2027 è se Google sceglie quella strada o no.

L'adozione bidirezionale, classico chicken-and-egg

Il problema di fondo: i siti implementano WebMCP solo se gli agenti lo richiedono in massa. Gli agenti supportano WebMCP solo se i siti lo espongono in massa. Tre vie storiche per rompere lo stallo, in ordine di efficacia:

1. Il browser pre-include il client agente (Chrome → Gemini in Chrome). È quello che Google sta tentando.
2. L'hyperscaler crea un incentivo coercitivo per i siti (AMP → SEO). Plausibile ma esplosivo politicamente.
3. Una killer app crea domanda da sola (iPhone → web mobile). Improbabile a breve.

WebMCP sta giocando esplicitamente la prima: Google ha confermato che Gemini in Chrome supporterà le API WebMCP, l'origin trial è già partito con nove sperimentatori grossi, l'asset agentic è già piazzato dentro il browser. È molto più della "preparazione" che ho descritto in una versione precedente di questo pezzo — è una mossa attiva. La seconda (incentivo SEO o equivalente) resta sullo sfondo come carta da giocare se la prima non basta. Però la prima da sola — Gemini in Chrome che usa WebMCP — non sposta i siti grandi finché non c'è massa di utenti che lo usano. Gli utenti non lo usano finché i siti che amano non lo supportano. L'origin trial con nove brand di prima fascia è un primo tentativo di rompere lo stallo con il prestigio: se Booking e Shopify dicono "ci siamo", molti altri si muovono per non restare fuori. La storia di AMP dice che funziona finché qualcuno paga il costo, e qualcuno paga il costo finché qualcuno gli paga il privilegio.

Ho già fatto questo ragionamento in un articolo recente sulla battaglia di Anthropic sugli SDK con Stainless: l'ecosistema vince quando l'incentivo è immediato per chi implementa. Quando l'incentivo è promesso ma differito, si formano isole. Quando l'incentivo è coercitivo, si forma rancore.

Cosa cambia per il dev italiano

Se sviluppi siti pubblici. Implementare WebMCP oggi è lavoro a fondo perduto: nessun traffico misurabile, nessuna spinta SEO, nessuna metrica conversione. Da rimandare al Q1 2027 salvo casi specifici: search box ad alta intensità, checkout di e-commerce, form di prenotazione (banca, hotel, ristoranti). In questi tre casi, l'agente di un utente potrebbe arrivare prima del resto del mercato, e la spec è abbastanza giovane da poter essere implementata "esplorativamente" senza commitment. Il costo è 2-4 ore per i primi tre-cinque tool, secondo i tutorial più seri su Next.js / React / SvelteKit.

Se sviluppi agenti. Continui a basarti su computer use + MCP server-side, perché coprono il 100% dei siti, non solo quelli WebMCP-enabled. WebMCP è un'ottimizzazione opportunistica da consumare quando presente, con graceful fallback a screen-based quando assente. Architettura realistica giugno 2026: agente che combina MCP server-side per i sistemi tuoi + computer use per i siti terzi + WebMCP quando disponibile. Sui pattern per agenti complessi ne ho parlato in subagents: quando dividere e quando no e in memoria degli agenti, stato dell'arte 2026, dove la lezione è la stessa: vincono i pattern che si compongono male con quelli esistenti.

Sulla compliance. Il Garante italiano ha pubblicato linee guida su web scraping AI a maggio 2024, aggiornate nel 2025, con focus su aree riservate, clausole nei ToS e interventi su robots.txt. Non risulta a oggi un provvedimento Garante specifico su WebMCP — la spec è troppo recente. Il caso nuovo da segnalare: se l'agente di un utente chiama un tool sul tuo sito usando la sessione autenticata dell'utente stesso, sei nel territorio dell'"automated processing on behalf of the data subject" sotto GDPR, e sotto AI Act potrebbero esserci implicazioni se il tool partecipa a una decisione automatizzata senza supervisione umana. I ToS vanno aggiornati prima di implementare, non dopo.

Chi vince, chi perde, in tre scenari

Se WebMCP esplode. Vincono Google + Microsoft (controllo dello standard, Gemini in Chrome + Copilot in Edge come agent layer di default, 70%+ del mercato browser combinato). Vincono i siti ad alto valore transazionale che adottano presto (Shopify, Booking, banche): meno frizione agente, conversioni in più. Vincono gli utenti: latenza minore, affidabilità maggiore. Perde Anthropic, che deve scegliere se aderire perdendo controllo di parte dello stack o ignorare perdendo presenza nei browser di Google e Microsoft (dilemma simile a quello che Apple e Microsoft hanno affrontato in modo opposto sui modelli di frontiera). Perdono Apple e Mozilla: rincorrono. Perdono i siti che non implementano: degradano lato AI search.

Se WebMCP fallisce. Vince Anthropic: MCP server-side + computer use restano lo stack dominante per il futuro prevedibile. Vincono i provider di "computer use as a service". Vince lo status quo dei dev: nessun lavoro extra da fare.

Scenario base più probabile a giugno 2026. WebMCP non vince in 12 mesi, non fallisce, resta nicchia per casi d'uso ad alto valore mentre screen-based + MCP server-side restano il default. Decisione critica nel 2027: Google attiva WebMCP-on-by-default in Chrome stable e privilegia siti WebMCP-enabled in Gemini Search? Se sì, abbiamo un AMP redux con tutti i pro e i contro del caso. Se no, abbiamo un microformats redux, e WebMCP diventa una nota a piè di pagina nella storia degli standard W3C-in-incubazione.

Quindi: vale la pena?

Per il dev italiano: tenerlo d'occhio, sì. Implementarlo oggi su un sito di produzione, no — salvo nei tre casi specifici sopra. Per chi sviluppa agenti: leggerlo, capirlo, prepararsi a supportarlo opportunisticamente, ma costruire la pipeline su computer use + MCP server-side che sono già qui e già funzionano. L'errore strategico più probabile è scambiare un Community Group Report in incubazione per un vincolo dell'ecosistema da onorare subito.

WebMCP è tecnicamente promettente. È strutturalmente in ritardo. Le due cose non si annullano: convivono. Mi aspetto che nei prossimi 12 mesi la copertura mainstream oscilli tra "rivoluzione" e "morto al nascere", e che la verità — come quasi sempre con gli standard web — sia un terzo posto noioso: parzialmente adottato, in convivenza con altri stack, utile dove serve, ignorato dove non porta valore immediato. Sui pattern che hanno seguito traiettorie simili, Agent SDK e l'ecosistema MCP che Anthropic sta costruendo sono il termine di paragone più utile.

Una cosa è certa: la frase "nuovo standard W3C per gli agenti" che leggerete ancora questa settimana è imprecisa. WebMCP è una proposta seria, di due hyperscaler seri, in stato di incubazione. Trattarla per quello che è, niente di più e niente di meno, è il favore migliore che possiamo fare a chi ci deve costruire sopra del software.

Fonti

Primarie

1. W3C WebMCP spec — Web Machine Learning CG
2. Chrome for Developers — WebMCP available for early preview — André Cipriani Bandarra, 10 febbraio 2026 2b. Chrome at I/O 2026 — Powering the agentic web — 19 maggio 2026 (origin trial Chrome 149, partner sperimentatori, Gemini in Chrome + WebMCP)
3. Chrome Developers — Imperative API
4. Chrome Developers — When to use WebMCP and MCP
5. Anthropic — Introducing the Model Context Protocol
6. Anthropic — Code execution with MCP
7. Anthropic — Introducing Claude Sonnet 4.6 (OSWorld 72,5%)
8. Garante Privacy — Web scraping IA generativa

Analisi e coverage 9. SearchEngineLand — WebMCP explained: Inside Chrome 146 10. WinBuzzer — Google Chrome Ships WebMCP 11. Studio Meyer — WebMCP Reality Check May 2026 12. Lawrence Hitches — MCP vs WebMCP Disambiguation 13. Zuplo — What is WebMCP 14. Webfuse — WebMCP Cheat Sheet 2026 15. freeCodeCamp — A Developer's Guide to WebMCP 16. Effloow — MCP Ecosystem 97M Installs 17. Digital Applied — MCP Adoption Statistics 2026 18. WorkOS — Everything your team needs to know about MCP in 2026

Parallelo storico 19. Plausible — Google AMP is dead 20. SearchEngineJournal — Google Retires AMP Icon 21. Wikipedia — Open Graph protocol 22. Wikipedia — Model Context Protocol

Paper 23. arXiv 2508.09171 — WebMCP: Efficient AI-Native Client-Side Interaction (benchmark 1.890 chiamate, riduzione media 65% token)