Introduzione a MCP e WebMCP
WebMCP e MCP affrontano due esigenze diverse, e Chrome stesso sottolinea che il primo non sostituisce il secondo. MCP (Model Context Protocol) collega gli agenti di intelligenza artificiale ai servizi di un’azienda, indipendentemente da dove questi siano ospitati e a qualsiasi ora. WebMCP invece collega gli agenti a un sito web finché la pagina rimane aperta in una scheda del browser, con l’utente che osserva l’azione in tempo reale.
Dopo il browser, Google ha esteso lo stesso concetto al telefono con Android MCP e AppFunctions, in beta dal 31 ottobre. La precisazione è stata pubblicata il 26 ottobre sul profilo X di Chrome for Developers, l’team di Google responsabile della documentazione per gli sviluppatori web, dopo mesi in cui molti avevano interpretato WebMCP come “il nuovo MCP per il web”. Oggi chi gestisce un servizio online ha una scelta concreta: utilizzare entrambi, ciascuno dove è più efficace.
Definizioni di base
Per chi parte da zero, ecco le due definizioni fondamentali.
- MCP è un protocollo aperto presentato da Anthropic nel novembre 2024. Un server MCP espone dati e azioni di un servizio (ad esempio un software di gestione o un calendario); un agente come Claude o ChatGPT si collega per leggerli e usarli.
- WebMCP è una proposta di standard per il browser, nata all’interno del Web Machine Learning Community Group del W3C, con la partecipazione di Google e Microsoft. Consente a una pagina di dichiarare all’agente le azioni che è in grado di eseguire.
Illustrazione comparativa
WebMCP e MCP messi a confronto mostrano chiaramente le loro aree di competenza. La differenza principale è la durata: MCP resta persistente sul server anche quando nessuno lo utilizza, mentre WebMCP è effimero, legato alla vita della scheda del browser.
Come provare WebMCP
WebMCP è disponibile in versione di prova a partire da Chrome 149. Per attivarlo in locale, basta abilitare il flag chrome://flags/#enable-webmcp-testing e riavviare il browser. Per un sito online è necessario un token di origin trial. L’API è soggetta a cambiamenti e funziona solo con la scheda aperta.
Risorse utili:
Confronto dettagliato: WebMCP vs MCP
Il documento “When to use WebMCP and MCP”, firmato da André Cipriani Bandarra e Alexandra Klepper e aggiornato al 19 maggio 2026, riassume la comparazione in una tabella sintetica.
| Aspetto | MCP | WebMCP |
|---|---|---|
| Dove vive | Backend, server dell’azienda | Frontend, nella pagina |
| Durata | Persistente | Effimera, legata alla scheda |
| Dove arriva | Postazione, mobile, cloud, web | Agenti che girano nel browser |
| Interfaccia | Esterna, senza UI del sito | Nel browser, a contatto con il DOM |
| Scoperta degli strumenti | Registrazione per ogni agente | La pagina li registra durante la visita |
| Casistica tipica | Azioni API in background | Navigare e agire su un’interfaccia web viva |
La riga più significativa è la durata. Un server MCP rimane attivo anche quando nessuno lo utilizza, mentre gli strumenti WebMCP nascono con la pagina e scompaiono con la chiusura della scheda. Il controllo dell’interfaccia passa anche da mani diverse: con MCP le applicazioni mostrano la propria UI all’interno di quella dell’agente; con WebMCP l’agente opera sul sito così com’è, come ospite della piattaforma.
Interazione con l’utente e scenari d’uso
Poiché gli strumenti WebMCP girano nella pagina, le azioni si svolgono sotto gli occhi dell’utente (ad esempio, un modulo si riempie automaticamente) e sfruttano la sessione già aperta, evitando un secondo ciclo di autenticazione. Al contrario, un agente che deve prenotare un volo alle tre del mattino, quando il browser non è attivo, non può contare su WebMCP e deve ricorrere a MCP.
In sintesi, WebMCP non sostituisce MCP. La documentazione di Chrome è chiara: WebMCP è un insieme di API ispirate a MCP, non un’estensione o una sostituzione di MCP. Il tweet del 26 ottobre lo riassume in tre frasi:
No, WebMCP isn’t replacing MCP.
MCP connects agents to your services.
WebMCP connects agents to your website while it’s open and the user’s in the loop.
Architettura a due livelli
L’architettura proposta prevede due strati. Il server MCP funge da livello di servizio, gestendo logica di business, recupero dati e compiti di background. WebMCP costituisce il livello contestuale, consentendo all’agente del browser di compiere azioni rapide e affidabili sul sito mentre l’utente lo osserva.
Per attività che durano ore, senza una scheda di riferimento, la via server è già disponibile (ad esempio, MCP Tasks su Claude Code). La bozza di specifica descrive una pagina dotata di WebMCP come un server MCP i cui strumenti sono scritti sul client anziché sul backend, mantenendo le valutazioni di rischio e le mitigazioni tipiche di MCP.
Le due API di WebMCP
La documentazione di Chrome (pubblicata il 18 maggio 2026 e aggiornata il 7 ottobre) prevede due modalità di integrazione:
- API imperativa: definizione degli strumenti in JavaScript.
- API dichiarativa: annotazioni HTML sui form già esistenti.
Entrambe sono progressive: un sito che ignora queste API continua a funzionare per tutti gli altri visitatori.
API imperativa
L’API imperativa utilizza registerTool sull’oggetto document.modelContext. È necessario fornire nome, descrizione, schema JSON degli input e una funzione execute. Le annotazioni guidano il browser su quanto sia prudente l’azione:
readOnlyHint: l’strumento non modifica dati.consequentialHint: l’azione è significativa e può richiedere conferma.untrustedContentHint: l’output contiene testo non affidabile.
Esempio di registrazione di uno strumento “cerca_vol”:
await document.modelContext.registerTool({
name: "cerca_vol",
description: "Cerca i voli disponibili per destinazione e data.",
inputSchema: {
type: "object",
properties: {
destinazione: { type: "string" },
data: { type: "string" }
},
required: ["destinazione", "data"]
},
annotations: { readOnlyHint: true },
execute: async ({ destinazione, data }) => {
const r = await fetch(`/api/voli?to=${destinazione}&date=${data}`);
return await r.text();
}
});
Altre funzioni utili includono getTools (elenca gli strumenti), executeTool (avvia manualmente uno strumento) e l’evento toolchange (notifica modifiche alla lista). Per rimuovere uno strumento basta fornire un AbortSignal all’atto di registrazione e poi annullarlo.
API dichiarativa
L’API dichiarativa non richiede codice JavaScript. Si aggiungono gli attributi toolname e tooldescription al tag <form>. Il browser deduce lo schema dei campi dal contenuto del form (etichetta, attributi name, ecc.) e da un eventuale toolparamdescription. Se non è presente toolautosubmit, l’invio rimane a carico dell’utente.
Esempio HTML:
<form toolname="richiestaAssistenza"
tooldescription="Invia una richiesta di assistenza."
action="/invia">
<label for="nome">Nome</label>
<input name="nome">
<select name="team" toolparamdescription="Seleziona il team di supporto">
<option value="tech">Tecnico</option>
<option value="billing">Fatturazione</option>
</select>
<button type="submit">Invia</button>
</form>
Se un attributo viene rimosso, lo strumento scompare automaticamente.
Linee guida per la scelta
La decisione su quale tecnologia adottare dipende da tre fattori chiave:
- Persistenza dei dati: se l’azione deve rimanere disponibile anche quando l’utente non è online, scegliere MCP.
- Contesto dell’utente: per operazioni visibili e interattive, dove l’utente osserva l’azione, WebMCP è ideale.
- Complessità dell’integrazione: MCP richiede un server dedicato e la gestione di token di autenticazione; WebMCP può essere aggiunto con pochi flag o attributi HTML.
In pratica, molti scenari beneficiano di un approccio ibrido: MCP gestisce le operazioni di lunga durata e di background, mentre WebMCP gestisce le interazioni rapide e contestuali direttamente nella pagina.
Conclusioni
WebMCP e MCP non sono concorrenti, ma complementari. MCP fornisce un canale persistente e server‑side per collegare gli agenti IA ai servizi aziendali, indipendente dalla presenza dell’utente. WebMCP, invece, consente agli agenti di agire in tempo reale su un sito web aperto, sfruttando la sessione utente e il DOM. La raccomandazione di Chrome è chiara: usare entrambi dove più appropriato, sfruttando la persistenza di MCP per compiti lunghi e la reattività di WebMCP per interazioni immediate.