Gli agenti AI possono interagire con una pagina web simulando clic, compilazione dei campi e altri comportamenti dell’utente. WebMCP propone un approccio diverso: consentire al sito di dichiarare direttamente azioni strutturate, chiamate tool, che un agente può individuare e utilizzare.
Non si tratta, però, di una tecnologia da considerare già universale o definitiva. Nel materiale esaminato WebMCP risulta ancora un Community Group Draft, non uno standard W3C definitivo. Supporto, interoperabilità e misure di sicurezza dipendono inoltre dalle singole implementazioni.
Per web agency, agenzie marketing e sviluppatori freelance il tema è interessante soprattutto come sperimentazione: un possibile strato operativo aggiuntivo per rendere alcune funzioni del sito utilizzabili dagli agenti, senza eliminare API, interfacce tradizionali, accessibilità o SEO tecnica.
Di cosa parlerò in questa pagina
Che cos’è WebMCP
WebMCP permette a un’applicazione web di esporre agli agenti AI azioni strutturate. Ogni tool può includere:
- un nome che identifica l’azione;
- una descrizione del suo scopo;
- uno schema degli input richiesti;
- la logica di esecuzione;
- l’indicazione della natura dell’operazione.
Uno schema esplicito aiuta a collegare i dati ai parametri previsti, riducendo l’ambiguità rispetto alla sola interpretazione visuale di pulsanti, campi e contenuti della pagina. La possibile minore fragilità rispetto alle automazioni basate su selettori CSS, screenshot e clic resta comunque una conseguenza tecnica plausibile: il dossier non riporta benchmark indipendenti consolidati che ne quantifichino il vantaggio in produzione.
È altrettanto importante usare la terminologia con prudenza. WebMCP è descritto nel dossier come una bozza del Web Machine Learning Community Group, non come una specifica W3C definitiva sullo Standards Track.
Come funzionano i Site tools
La bozza prevede due modalità per definire i tool:
- API imperativa JavaScript, con cui l’applicazione registra funzioni invocabili dall’agente;
- API dichiarativa, basata sull’annotazione dei form HTML.
In entrambi i casi, l’agente deve visitare la pagina per scoprirne i tool. Questi operano sulla pagina aperta, sul suo stato e sull’eventuale sessione autenticata. Non sono descritti come connessioni API separate e permanentemente disponibili.
L’esecuzione resta visibile all’interno della pagina, permettendo all’utente di verificarne l’esito. Quando la pagina viene chiusa, i Site tools non rimangono a disposizione dell’agente.
Queste caratteristiche distinguono WebMCP sia da un’API tradizionale sia da un’automazione completamente esterna all’interfaccia. Il tool appartiene al contesto della pagina visitata e ne utilizza lo stato, ma deve comunque rispettare tutti i controlli applicativi e server-side.
Supporto attuale e limiti di interoperabilità
Secondo il dossier, il supporto OpenAI è circoscritto al browser integrato nell’app desktop di ChatGPT e la disponibilità dipende dall’account e dal modello. ChatGPT Work e Codex possono rilevare e usare i Site tools presenti sulla pagina aperta, nei casi in cui la funzione risulti disponibile.
La documentazione citata nella ricerca indica inoltre:
- un flag destinato allo sviluppo locale;
- un origin trial a partire da Chrome 149.
Questi elementi confermano il carattere sperimentale del supporto browser. Non consentono di affermare che WebMCP sia disponibile in tutto Chrome, in tutti i browser o presso qualsiasi agente AI.
Prima di pianificare un progetto è quindi necessario controllare lo stato aggiornato della bozza, la disponibilità prevista dall’account e dal modello utilizzato e la documentazione del browser coinvolto.
Casi d’uso per web agency e professionisti
Un primo progetto dovrebbe concentrarsi su una o due azioni a basso rischio, preferibilmente reversibili o preparatorie. Tra gli esempi riportati nel dossier rientrano:
- ricerca all’interno della documentazione;
- applicazione di filtri strutturati;
- diagnostica guidata;
- preparazione non definitiva di una richiesta di preventivo;
- prenotazioni e aggiornamenti del carrello, con adeguati controlli e conferme.
Esempio: preparare una richiesta di preventivo
Un’agenzia potrebbe sperimentare un tool che raccolga in modo strutturato dati come:
- tipo di progetto;
- budget;
- scadenza;
- indirizzo email.
Lo schema permetterebbe all’agente di associare ogni informazione al campo previsto. Il tool potrebbe preparare la richiesta e mostrarla nella pagina, lasciando all’utente la verifica e la conferma prima dell’invio.
Questo è un possibile caso d’uso, non una funzionalità già presente sul sito. Inoltre, nelle applicazioni con stato articolato o workflow complessi, l’integrazione potrebbe richiedere interventi di refactoring.
Come progettare un primo progetto pilota
WebMCP dovrebbe essere trattato come progressive enhancement: una capacità aggiuntiva che non rende inutilizzabile il servizio quando il browser o l’agente non la supportano.
- Scegliere un’azione limitata. Ricerca, consultazione o preparazione di dati sono punti di partenza più prudenti rispetto a operazioni irreversibili.
- Mantenere l’interfaccia tradizionale. Persone e browser non compatibili devono poter completare lo stesso flusso senza WebMCP.
- Separare lettura e scrittura. Un tool che recupera informazioni dovrebbe essere distinto da uno che modifica dati o invia contenuti.
- Validare tutti gli input. Lo schema del tool non sostituisce la validazione applicativa e server-side.
- Applicare il minimo privilegio. Ogni tool deve poter eseguire soltanto le operazioni necessarie al suo scopo.
- Verificare autorizzazioni e sessione sul server. La presenza di una sessione autenticata non rende automaticamente legittima o sicura un’azione.
- Richiedere una conferma esplicita. La conferma è essenziale per acquisti, invio di messaggi, condivisione di dati personali, cancellazioni e modifiche dei permessi.
API, accessibilità, interfacce per le persone e controlli server-side restano quindi componenti necessarie dell’architettura.
Sicurezza, affidabilità e aspettative da ridimensionare
Esporre azioni agli agenti amplia le possibilità operative del sito, ma introduce anche rischi che devono essere considerati fin dalla progettazione. Il dossier cita:
- prompt injection;
- tool poisoning;
- esfiltrazione di dati;
- descrizioni dei tool ingannevoli;
- esecuzione di operazioni non coerenti con l’intenzione dell’utente.
La sessione autenticata richiede particolare attenzione. Un tool capace di operare nel contesto di un utente non deve aggirare autorizzazioni, validazioni o conferme previste dall’applicazione. L’autenticazione identifica la sessione, ma non dimostra da sola che ogni azione richiesta sia autorizzata o desiderata.
Anche le aspettative commerciali vanno mantenute realistiche. Le fonti fornite non dimostrano che WebMCP produca:
- miglioramenti nel ranking SEO;
- più citazioni o raccomandazioni in ChatGPT;
- maggiore sicurezza automatica;
- incrementi delle conversioni;
- affidabilità superiore quantificata da benchmark indipendenti consolidati.
WebMCP non va quindi presentato come scorciatoia per la visibilità organica o come sostituto di un’architettura web solida.
WebMCP conviene già a un’agenzia?
Può essere sensato valutarlo se l’obiettivo è sperimentare un sito più agent-ready attraverso un caso d’uso circoscritto, misurabile e a basso rischio. È invece prematuro considerarlo un requisito generale o una tecnologia con interoperabilità garantita.
Una strategia prudente consiste nel:
- individuare un’azione preparatoria o reversibile;
- realizzare un prototipo limitato;
- mantenere invariati i flussi tradizionali;
- verificare autorizzazioni, validazione e conferme;
- controllare il supporto reale sugli ambienti scelti;
- evitare promesse SEO o commerciali non dimostrate.
In questo modo WebMCP può essere studiato come strato operativo aggiuntivo, senza sacrificare API, accessibilità, SEO tecnica e usabilità per le persone.
Vuoi valutare un tool a basso rischio o un piccolo progetto pilota? Contattami per saperne di più.
Domande frequenti su WebMCP
WebMCP è già uno standard W3C definitivo?
No. Nel dossier risulta un Community Group Draft, non uno standard W3C definitivo. Lo stato aggiornato della proposta deve essere verificato prima di avviare o pubblicare un progetto.
Come vengono definiti i tool WebMCP?
La bozza prevede un’API imperativa JavaScript e un’API dichiarativa basata sull’annotazione dei form HTML. Un tool può includere nome, descrizione, schema degli input, logica di esecuzione e natura dell’operazione.
WebMCP sostituisce le API o l’interfaccia tradizionale del sito?
No. I tool operano sulla pagina aperta, sul suo stato e sulla sessione disponibile; non sono descritti come connessioni API separate. WebMCP va adottato come progressive enhancement, mantenendo API, controlli server-side e interfacce utilizzabili dalle persone.
Quali agenti e browser supportano WebMCP?
Nel dossier, il supporto OpenAI riguarda il browser integrato nell’app desktop di ChatGPT e dipende dalla disponibilità per account e modello. Sono citati ChatGPT Work e Codex. La documentazione browser menziona un flag di sviluppo locale e un origin trial da Chrome 149, ma ciò non equivale a un supporto universale in Chrome o negli altri browser.
Quali rischi di sicurezza comporta WebMCP?
I rischi citati comprendono prompt injection, tool poisoning, esfiltrazione di dati, descrizioni ingannevoli e operazioni non coerenti con l’intenzione dell’utente. Sono necessari autorizzazione server-side, minimo privilegio, validazione degli input e conferme esplicite per le azioni sensibili.
WebMCP offre vantaggi SEO o migliora le citazioni in ChatGPT?
Le fonti fornite non contengono evidenze di benefici per il ranking SEO o per le citazioni in ChatGPT. Non deve essere proposto come tecnica SEO o come garanzia di visibilità presso gli agenti AI.
Fonti
- OpenAI Adds WebMCP Site Tools To ChatGPT’s Browser via @sejournal, @MattGSouthern (www.searchenginejournal.com)
- Using site tools in the ChatGPT desktop app | OpenAI Help Center (help.openai.com)
- WebMCP (webmachinelearning.github.io)
- WebMCP | AI on Chrome | Chrome for Developers (developer.chrome.com)
