WebMCP: il prossimo cliente del tuo sito potrebbe essere un agente AI

Per trent'anni abbiamo costruito siti per due interlocutori. Il primo era una persona, da convincere con un titolo, una fotografia, una sequenza di pagine e un pulsante. Il secondo era il motore di ricerca, al quale abbiamo imparato a offrire struttura, metadati e contenuti leggibili. Ora ne sta arrivando un terzo.

Non guarda una homepage come noi, non si lascia impressionare da un'animazione e non ha nessun desiderio di imparare dove abbiamo nascosto una funzione. È un agente AI che riceve un obiettivo, raccoglie informazioni, confronta alternative e prova a concludere un'attività per conto di qualcuno.

WebMCP nasce per questo visitatore. L'idea è semplice: invece di costringere l'agente a interpretare il sito osservando lo schermo, leggendo il DOM e simulando una lunga serie di clic, la pagina dichiara in modo esplicito ciò che sa fare. Cercare un prodotto, filtrare un catalogo, verificare una compatibilità, compilare una richiesta, recuperare lo stato di un ordine, preparare un preventivo, aggiungere un articolo al carrello. Ogni capacità viene descritta come uno strumento con un nome, uno schema di input e un risultato atteso. Il browser mette quindi in relazione tre soggetti che finora vivevano in ambienti separati: il sito, l'agente e la persona che osserva e decide.

È una prospettiva importante, ma è ancora presto per trasformarla in una certezza commerciale. Ad agosto 2026 WebMCP resta uno standard proposto, in fase di sperimentazione. Chrome lo ha inserito in un origin trial a partire dalla versione 149; il piano pubblicato indica una sperimentazione fino alla 156 e una possibile distribuzione dalla 157, ma si tratta di milestone stimate. Nello stesso documento non risultano ancora segnali formali da Gecko e WebKit. Non siamo davanti a una tecnologia universale già disponibile su ogni browser. Siamo davanti a un'indicazione abbastanza concreta della direzione che il web potrebbe prendere. Ed è proprio in questa distanza tra ciò che funziona oggi e ciò che potrebbe diventare normale domani che si trova la parte interessante. Chrome for Developers, Intent to Experiment

Prima di tutto: con lo stesso nome circolano due progetti diversi

Una parte della confusione online nasce dal fatto che il link webmcp.dev non documenta esattamente la stessa implementazione presentata oggi da Chrome. È un progetto open source precedente e indipendente, creato da Jason McGhee, che collega una pagina web a un client MCP attraverso un piccolo widget, un token monouso e un server WebSocket locale. È un esperimento ingegnoso: ha anticipato il problema, permette di registrare tool, prompt e risorse nella pagina e consente a client come Claude Desktop di utilizzarli. Richiede però una configurazione specifica sul computer dell'utente e un passaggio manuale di connessione. Il progetto browser-native ora in sperimentazione elimina quel rituale e porta il concetto dentro la piattaforma web, attraverso document.modelContext e le regole di sicurezza del browser. Repository di Jason McGhee

Le due strade condividono l'intuizione, non il livello di maturità né il meccanismo tecnico. Il primo WebMCP dimostra che una pagina può comportarsi come un server MCP locale; la proposta del Web Machine Learning Community Group prova a trasformare quella possibilità in una capacità nativa e interoperabile del browser. Quando si valuta un investimento è essenziale non sommare demo, librerie e standard come se fossero già un unico ecosistema. Il riferimento da seguire per la compatibilità futura è la specifica WebMCP e la sua implementazione nei browser. Il progetto su webmcp.dev rimane utile per sperimentare con i client MCP disponibili oggi.

Un sito che non deve più essere interpretato

Un agente browser tradizionale lavora spesso per approssimazioni successive. Osserva uno screenshot o una rappresentazione della pagina, individua un elemento che sembra pertinente, fa clic, attende il cambiamento, osserva di nuovo e ripete. Le implementazioni più evolute leggono anche il DOM e l'albero di accessibilità, ma il principio non cambia: devono dedurre l'intenzione del sito da un'interfaccia costruita per gli esseri umani. Se il design cambia, se due pulsanti hanno etichette ambigue o se un calendario usa un componente particolare, l'agente può rallentare, scegliere male o perdersi.

WebMCP sposta la responsabilità semantica dalla macchina al proprietario del sito. Non è più l'agente a dover indovinare che cosa faccia un controllo: è l'applicazione a dichiararlo. La proposta prevede una via dichiarativa, adatta ai normali form HTML, e una via imperativa per le funzioni JavaScript più complesse. In entrambi i casi l'agente riceve un catalogo circoscritto di azioni con parametri strutturati. Il sito continua a mostrare la sua interfaccia e ad applicare la propria logica; l'agente smette soltanto di attraversarla alla cieca. Secondo la documentazione di Chrome, questa impostazione migliora affidabilità ed efficienza, mantiene visibili gli effetti delle operazioni e può essere aggiunta come progressive enhancement senza togliere nulla agli utenti dei browser che non la supportano. Perché WebMCP

La differenza sembra tecnica, ma cambia il significato del frontend. Fino a oggi il frontend era la traduzione visiva delle capacità di un servizio. Con WebMCP può diventare anche il luogo in cui quelle capacità vengono dichiarate agli agenti. L'interfaccia non scompare: acquista un secondo linguaggio. Uno è fatto di gerarchie, testi, immagini e controlli per le persone; l'altro di nomi, descrizioni, schemi e conseguenze per le macchine.

WebMCP non sostituisce le API e non sostituisce MCP

Il dubbio più sensato emerso nelle discussioni su Reddit è diretto: se un'azienda possiede già buone API, perché dovrebbe far passare l'agente dal sito? La risposta è che risolvono problemi diversi. Un'API o un server MCP tradizionale permettono a un sistema esterno di parlare direttamente con il backend. Sono ideali per integrazioni server-to-server, automazioni headless e processi che devono funzionare senza una pagina aperta. WebMCP opera invece nella sessione del browser, riutilizza lo stato dell'interfaccia, le autorizzazioni dell'utente connesso e le funzioni client già presenti. Consente inoltre alla persona di vedere ciò che accade e di intervenire nel punto in cui una decisione diventa sensibile. Explainer WebMCP

Se un SaaS dispone di API complete, autenticazione ben risolta e nessun bisogno di mantenere sincronizzata l'interfaccia, aggiungere WebMCP può essere superfluo. Se invece gran parte del valore vive nello stato della pagina, in procedure a più passaggi, in componenti interattivi o in funzioni interne che non sono mai state esposte pubblicamente, il browser diventa un contesto prezioso. È anche il motivo per cui la sessione autenticata viene descritta da molti sviluppatori come il vantaggio più immediato: l'agente può usare soltanto gli strumenti disponibili per quell'utente e per quel preciso stato della pagina. La discussione su r/webdev arriva a una sintesi corretta: WebMCP non è per l'integrazione tra due backend, ma per un terzo tipo di client, l'agente che agisce per conto dell'utente nel browser in cui l'utente è già connesso.

Il futuro plausibile non è quindi una scelta tra sito, API e MCP. È una stessa logica di business esposta attraverso superfici diverse. Il backend rimane la fonte di verità; API e MCP servono l'automazione esterna; WebMCP porta una parte controllata di quelle capacità dentro la sessione visibile. Se per aggiungerlo bisogna duplicare regole, autorizzazioni e validazioni, l'architettura è già sbagliata. Gli strumenti dovrebbero essere involucri sottili attorno a funzioni applicative esistenti, non una seconda implementazione dei processi aziendali.

Il commercio agentico è una pila di livelli, non un solo protocollo

Nel commercio automatico bisogna distinguere almeno quattro momenti. L'agente deve scoprire che:

1. 01un'azienda esiste e capire che cosa vende
2. 02deve poter cercare, configurare e comporre l'offerta
3. 03deve costruire un checkout coerente con prezzi, disponibilità, tasse e consegna
4. 04infine deve dimostrare che la persona o l'organizzazione gli ha concesso il diritto di spendere e completare il pagamento.

WebMCP è particolarmente adatto al secondo momento dentro una pagina aperta e può accompagnare il terzo mantenendo l'esperienza visibile. Non risolve da solo gli altri.

Il Universal Commerce Protocol è stato progettato per dare a piattaforme, agenti, merchant e provider di pagamento un linguaggio comune dal catalogo al checkout. L'Agent Payments Protocol aggiunge mandati firmati e prove verificabili dell'intenzione, distinguendo i casi in cui la persona approva il carrello da quelli in cui delega all'agente una ricerca e una futura spesa entro determinate condizioni. Visa e Mastercard stanno costruendo infrastrutture proprie per riconoscere gli agenti, tokenizzare le credenziali, applicare limiti e portare la transazione sulle reti di pagamento. Nel 2026 Mastercard ha esteso questo lavoro alle transazioni machine-to-machine ad alta frequenza e di piccolo valore. Visa Intelligent Commerce, Mastercard Agent Pay for Machines

Il quadro è ancora in movimento, con standard concorrenti e sovrapposti, ma la direzione è leggibile. WebMCP dice all'agente che cosa può fare nella pagina. UCP descrive il viaggio commerciale. AP2 e i sistemi dei circuiti di pagamento cercano di provare identità, delega e limiti. Confondere questi livelli porta a costruire una demo che compra; separarli permette di progettare un sistema che può essere autorizzato, controllato e contestato.

Non è il nuovo SEO: è il possibile ultimo metro della conversione

Nel video viene proposta una progressione efficace: il SEO serve a essere trovati, l'AEO a essere citati, il web agentico a essere selezionati e utilizzati. Il concetto è valido, ma WebMCP non rende automaticamente un sito scopribile. Chrome dichiara esplicitamente che l'agente deve prima visitare una pagina per sapere quali strumenti offre. Non esiste, dentro WebMCP, un indice universale dei siti azionabili. Per un e-commerce la scoperta può passare da cataloghi, feed e profili UCP; per altri servizi continueranno a contare ricerca, contenuti, dati strutturati, API e distribuzione sulle piattaforme frequentate dagli agenti. Limiti di WebMCP

WebMCP è quindi più vicino al conversion rate optimization per agenti che al SEO per agenti. Interviene quando l'agente è già arrivato e deve concludere un compito senza rompersi contro un date picker, una tabella incomprensibile o una procedura divisa in sette schermate. Un sito può essere perfettamente indicizzato ma impossibile da azionare; può anche essere azionabile ma invisibile agli agenti. La strategia richiede entrambe le cose. Il possibile vantaggio non nasce dall'aggiungere tre attributi HTML e aspettare un'ondata di bot compratori. Nasce dal ridurre la distanza tra intenzione e risultato quando quel traffico inizierà ad avere un peso reale.

Avere un sito WebMCP oggi può davvero creare un vantaggio?

Sì, ma non per tutti e non nello stesso modo. Nelle community tecniche i casi reali sono ancora pochi. Uno sviluppatore racconta di aver collegato le funzioni già presenti sul proprio sito con circa quaranta righe di codice, ma definisce l'adozione quasi nulla e il lavoro soprattutto un modo per piantare una bandierina. Un altro mostra un gioco risolto in pochi secondi e descrive un forte risparmio di tempo e token. Nel mondo WordPress esistono già plugin che trasformano le Abilities API in tool WebMCP, con allowlist, nonce, HTTPS e rate limiting. Sono segnali di attività, non ancora prove di domanda su larga scala. Esperienza su r/AI_Agents, WebMCP e WordPress, test su r/mcp

Il ritorno più vicino non è necessariamente acquisire nuovi clienti agentici. È costringere l'azienda a descrivere bene le proprie capacità, separare la logica dall'interfaccia, rendere i processi verificabili e costruire valutazioni ripetibili. Questo lavoro migliora anche API, automazioni, accessibilità, testing e strumenti interni. Se il sito possiede già funzioni pulite, un primo esperimento può essere economico. Se dietro i pulsanti ci sono eccezioni manuali, stato incoerente e regole replicate, WebMCP porterà alla luce il debito invece di cancellarlo.

I settori più promettenti non sono quelli con il maggior numero di pagine, ma quelli in cui la scelta richiede molte relazioni. Ricambi industriali, elettronica, componenti, configuratori, eyewear, cataloghi B2B, viaggi complessi, assicurazioni self-service, console SaaS, procurement e assistenza tecnica hanno un problema comune: l'utente deve combinare vincoli, compatibilità, storico e disponibilità. In questi casi l'agente non sostituisce una bella vetrina; elimina ore di lavoro tra una vetrina e l'ordine corretto. Anche gli strumenti interni sono un terreno sensato perché l'azienda controlla utenti, browser, processi e rischio, e può misurare il guadagno prima di esporre le stesse capacità all'esterno.

Su un sito puramente editoriale o su una piccola attività il cui unico obiettivo è ricevere un modulo di contatto, il beneficio immediato è più modesto. Il video ipotizza agenzie che vendano conversioni WebMCP a dentisti, studi legali e imprese locali per migliaia di dollari più un canone mensile. Può diventare un servizio, ma quei prezzi sono un'idea commerciale, non una validazione del mercato. Se l'unico tool è book_consultation, l'agente potrebbe già completare il form con un buon browser assistant. Il valore cresce quando il sito offre una capacità specifica che sarebbe lenta, ambigua o impossibile da ricostruire osservando la pagina.

La sessione del browser è un vantaggio e una zona di pericolo

Nel racconto ottimistico, l'autenticazione sembra risolta: l'utente è già connesso e l'agente eredita la sessione. È vero dal punto di vista dell'esperienza, ma proprio questa comodità aumenta la posta in gioco. Un cookie valido dimostra che il browser può agire come l'utente; non dimostra che ogni decisione formulata dal modello sia stata compresa, voluta e autorizzata. Uno strumento ambiguo, un output contaminato da prompt injection o una descrizione malevola possono sfruttare un contesto che contiene dati provenienti da più siti.

La bozza della specifica elenca apertamente i problemi: tool poisoning nelle descrizioni, prompt injection nei risultati, perdita di informazioni tra origini e soprattutto falsa rappresentazione dell'intenzione. L'esempio più chiaro è una funzione chiamata finalizeCart: potrebbe sembrare una semplice conferma del carrello e invece eseguire l'acquisto. Un agente decide sulla base di parole in linguaggio naturale, mentre il codice può produrre effetti diversi. Security and Privacy Considerations

Per questa ragione un'implementazione seria parte da tool in sola lettura, registra soltanto le capacità necessarie nello stato corrente e separa sempre preparazione ed esecuzione. Un preventivo può essere calcolato automaticamente; l'invio deve avere una conferma. Un carrello può essere composto dall'agente; il pagamento deve usare un mandato o un consenso esplicito. Ogni operazione che modifica dati deve essere validata dal backend, idempotente, limitata per frequenza, tracciata e associata a permessi reali. I suggerimenti readOnlyHint e untrustedContentHint aiutano l'agente a ragionare, ma sono metadati, non barriere di sicurezza. La documentazione di Chrome raccomanda descrizioni precise, output brevi, tool non sovrapposti, gestione degli errori ed eval continui; per le azioni sensibili sta ancora evolvendo un meccanismo di consenso. WebMCP best practices, WebMCP tool security

Reddit, su questo punto, è più utile dell'entusiasmo iniziale. Le obiezioni ricorrenti non riguardano la capacità del modello di chiamare una funzione, ma ciò che succede dopo: blocco dello stato transazionale, doppie esecuzioni, limiti di velocità, conferme, audit e danni provocati da tool creati o condivisi da terzi. Sono le domande giuste. WebMCP può rendere l'interazione meno fragile, non rende automaticamente sicuro il processo aziendale che si trova dietro di essa. Discussione su r/ChatGPTCoding

Il sito del futuro non sarà senza interfaccia: avrà due interfacce

È facile immaginare l'agentic web come la fine dei siti, sostituiti da una conversazione universale. WebMCP suggerisce una direzione più interessante. Il sito rimane perché mostra, spiega, costruisce fiducia e consente alla persona di controllare il risultato. Accanto all'interfaccia umana compare però un'interfaccia operativa, meno visibile e molto più precisa, attraverso la quale l'agente può trasformare un'intenzione in una sequenza di azioni.

Questo richiederà un nuovo tipo di progettazione. Non basterà domandarsi se il pulsante è comprensibile; bisognerà definire che cosa significhi davvero l'azione, quando sia disponibile, quali informazioni accetti, quali effetti produca, quali permessi richieda e come possa essere annullata o ripetuta senza danni. Una pagina non sarà più soltanto contenuto e navigazione. Diventerà una dichiarazione eseguibile delle capacità dell'azienda.

Il sito che potrebbe ottenere un successo inatteso non è quindi quello che installa per primo il badge WebMCP. È quello che rende leggibile e utilizzabile il proprio vantaggio reale: un catalogo ben strutturato, una conoscenza specialistica, un configuratore, una disponibilità aggiornata, una rete di servizi, una logica di preventivazione o una procedura difficile da replicare. Quando gli agenti inizieranno a scegliere per conto delle persone, premieranno meno la promessa e più la capacità di portare a termine il compito. Ma per essere scelti serviranno ancora reputazione, prezzo, qualità dei dati, affidabilità e distribuzione. Il protocollo apre la porta; non crea il motivo per entrare.

La posizione di agent1

Oggi non proporremmo a un'azienda di

“rifare il sito in WebMCP”

Proporremmo di individuare i tre compiti ad alto valore che un agente dovrebbe riuscire a completare, verificare se la logica sottostante è già affidabile e costruire una piccola superficie sperimentale. Prima in lettura, poi con azioni reversibili, infine con conferme e controlli per ciò che produce conseguenze economiche. Ogni flusso andrebbe testato con modelli diversi e misurato su successo, tempo, costo, errori e richieste di intervento umano.

È un investimento in opzionalità. Se WebMCP cambierà forma, una buona architettura a capacità, i contratti degli strumenti, le validazioni e gli eval resteranno utili per MCP, API, assistenti interni e altri protocolli agentici. Se invece diventerà una funzione normale dei browser, l'azienda non dovrà iniziare in quel momento a capire che cosa sa fare davvero il proprio sito. Sarà già pronta a ricevere un cliente che non visita pagine: porta un'intenzione, chiede una capacità e si aspetta un risultato.