È la domanda che gira di più da quando Chrome ha pubblicato la documentazione di WebMCP: WebMCP sostituirà MCP?
No. E non è nemmeno una sua estensione, né una sua versione JavaScript. Sono due tecnologie che risolvono lo stesso problema in due posti diversi, e la confusione nasce dal nome, che purtroppo suggerisce una parentela più stretta di quella reale.
La risposta breve dipende da una domanda sola: la funzione di cui stiamo parlando deve funzionare anche quando il tuo sito è chiuso? Se sì, è MCP. Se ha senso solo mentre qualcuno sta guardando la pagina, è WebMCP.
Tutto il resto discende da lì.
Cosa hanno in comune #
Prima delle differenze conviene fissare la parte identica, perché è sostanziosa e spiega perché si assomigliano.
Tutti e due esistono per lo stesso motivo: dare a un agente un modo dichiarato e prevedibile di usare le tue funzioni, invece di lasciarlo indovinare. Tutti e due offrono le stesse tre funzioni.
Scoperta strutturata. L’agente può chiedere "cosa sai fare?" e ricevere un elenco leggibile da una macchina, con i parametri e lo scopo di ogni strumento.
Esecuzione prevedibile. Una chiamata dichiarata al posto di una sequenza di clic simulati. Il clic dipende da dove hai messo il pulsante oggi, la chiamata no.
Intento esplicito. Le capacità sono dichiarate, non dedotte. Senza nessuno dei due, l’agente tira a indovinare guardando l’interfaccia.
Se hai già scritto un tool per un modello, la forma la riconosci: nome, descrizione, schema JSON degli input. È la stessa in entrambi.
Dove vivono, che è tutta la differenza #
MCP: lavora sul server #
MCP è un protocollo che collega un agente a sistemi esterni: banche dati, servizi, flussi di lavoro. È universale, spesso viaggia su JSON-RPC, e si implementa con un SDK nel linguaggio che già usi.
Vive sul server. Questo vuol dire che i suoi strumenti sono persistenti: esistono che il tuo sito sia aperto o chiuso, che l’utente sia sul tuo dominio o dentro una conversazione con un modello, alle tre di notte mentre nessuno guarda.
WebMCP: lavora nella pagina #
WebMCP è una proposta di standard del browser, con due API che parlano solo con l’agente integrato nel browser. Si scrive in JavaScript o con attributi HTML, e a fare da tramite fra il tuo sito e l’agente è il browser stesso.
Vive nella pagina. Quindi i suoi strumenti sono effimeri: esistono finché la scheda è aperta. L’utente cambia pagina o chiude, e l’agente non può più fare niente sul tuo sito.
Sembra un limite, ed è anche un limite. Ma è quello che gli dà il suo unico superpotere: dentro la pagina ha accesso alla sessione viva, ai cookie, allo stato del DOM. Cose che un server esterno non ha, e che non può ricostruire.
La documentazione Chrome usa un paragone che rende bene: MCP è il call center, raggiungibile ovunque e a qualsiasi ora. WebMCP è il commesso esperto dentro il negozio, che sa tutto ma esiste solo se nel negozio ci sei entrato.
Di chi è l’interfaccia, con MCP e con WebMCP #
Questa è la parte che quasi nessuno racconta, ed è quella che in un progetto vero cambia le decisioni.
Con MCP, la tua applicazione è ospite dentro l’agente. Se l’agente mostra qualcosa della tua applicazione, lo mostra dentro la propria interfaccia, con i suoi vincoli. Il tuo marchio, le tue scelte di progetto, il tuo modo di guidare una persona attraverso un flusso: tutto passa attraverso il filtro di qualcun altro. E spesso significa costruire una seconda applicazione, separata da quella che hai già.
Con WebMCP, l’agente è ospite sul tuo sito. Le chiamate agli strumenti girano in modo visibile sulla tua pagina, davanti all’utente, dentro la tua interfaccia. Chrome disegna perfino un contorno tratteggiato sul modulo mentre l’agente lo compila. L’utente vede i campi riempirsi.
Non è un dettaglio estetico. È la differenza fra una persona che si fida perché vede cosa sta succedendo, e una che deve credere sulla parola a un riassunto.
Un esempio: un negozio online #
Prendiamo un e-commerce vero e dividiamo le funzioni. Nessuna di queste scelte è opinabile: discendono tutte dalla domanda del secondo paragrafo.
Va in MCP, perché deve funzionare a sito chiuso:
get_order_status: l’utente chiede al proprio assistente dov’è il pacco, mentre è in una conversazione, senza aprire il tuo sito.search_catalog: un agente confronta i tuoi prezzi con altri due negozi per conto dell’utente.check_stock: un gestionale di un cliente business interroga la disponibilità ogni notte.
Va in WebMCP, perché ha senso solo sulla pagina:
refine_search(priceRange = "0-49.99"): l’utente sta guardando i risultati adesso, e i filtri sono quelli di questa pagina, in questo stato.add_to_wishlist(productId, quantity): serve il carrello di questa sessione, con questo utente riconosciuto da questo cookie.pick_delivery_date: il calendario delle consegne dipende dal magazzino scelto due schermate fa.
Le due liste, del resto, non si sovrappongono per caso. Quelle sopra riguardano dati, quelle sotto riguardano lo stato dell’interfaccia. È la formulazione più utile della regola: MCP espone i tuoi dati, WebMCP spiega la tua interfaccia.
Tabella per decidere #
| MCP | WebMCP | |
|---|---|---|
| Dove vive | Server | Pagina, nel browser |
| Quando funziona | Sempre | Solo a scheda aperta |
| Ciclo di vita | Persistente | Effimero |
| Accesso a sessione e cookie | No | Sì |
| Chi possiede l’interfaccia | L’agente | Il tuo sito |
| Come si scrive | SDK, spesso JSON-RPC | JavaScript o attributi HTML |
| Serve un’applicazione nuova | Spesso sì | No, si annota quella che hai |
| Stato oggi | Adottato | Proposta, origin trial da Chrome 149 |
Quando non ti serve nessuno dei due #
Vale la pena dirlo, perché nessuna documentazione di prodotto lo dice mai.
Se il tuo sito è fatto di pagine da leggere, non ti serve niente. Un sito vetrina, un portfolio, un blog: lì l’agente deve capire un testo, e leggere testi è ciò che i modelli sanno fare meglio. Aggiungere strumenti significa scrivere codice per un problema che non hai.
La soglia è semplice: hai qualcosa da fare, o solo qualcosa da leggere? Se non c’è una transazione, uno stato, un modulo lungo o un catalogo da filtrare, la risposta è che il tuo HTML scritto bene sta già facendo il suo lavoro.
Domande frequenti su MCP e WebMCP #
WebMCP sostituisce MCP? #
No, e non è nemmeno una sua estensione. MCP collega un agente a sistemi esterni e funziona sempre; WebMCP vive nella pagina e funziona solo mentre è aperta. Sono complementari: MCP espone i dati, WebMCP spiega l’interfaccia.
Posso usarli tutti e due sullo stesso prodotto? #
Sì, ed è il caso normale per chi ha un e-commerce o un gestionale. La divisione utile è: in MCP le funzioni che devono valere anche a sito chiuso, in WebMCP quelle che dipendono dallo stato della pagina, dalla sessione o dai cookie.
WebMCP è MCP scritto in JavaScript? #
No. La documentazione Chrome lo definisce un insieme di API "ispirate a MCP", non una sua implementazione. È pensato per il browser e lascia fuori concetti lato server come le risorse.
Qual è il vantaggio pratico di WebMCP rispetto a MCP? #
Tre. La comunicazione è quasi istantanea, perché non c’è un viaggio fino a un server remoto. Gli strumenti sono agganciati alla logica dell’applicazione e non al disegno, quindi puoi rifare la grafica senza rompere l’agente. E l’azione avviene davanti all’utente, sulla tua interfaccia, invece che dentro quella di qualcun altro.
E lo svantaggio? #
Che sparisce quando la scheda si chiude. Nessun lavoro in sottofondo, nessun agente che opera mentre l’utente dorme, e un client scopre i tuoi strumenti solo visitando la tua pagina: non esiste un registro pubblico dove annunciarli.
Da cosa comincio se ho poco tempo? #
Da MCP se il valore è nei dati, cioè se la domanda tipica del tuo utente è "qual è lo stato di", "quanto costa", "cerca fra i tuoi". Da WebMCP se è in un modulo lungo o in un flusso complicato che le persone sbagliano. E da nessuno dei due se il tuo sito è fatto di pagine da leggere.
Fonti #
Quando usare WebMCP e MCP e la documentazione WebMCP su developer.chrome.com, aggiornate al 1 settembre 2026. WebMCP è una proposta in evoluzione: verifica prima di fidarti.