Introduzione a MCP e WebMCP

WebMCP e MCP risolvono due problemi distinti, e Chrome sottolinea che il primo non deve sostituire il secondo. MCP (Model Context Protocol) è un protocollo aperto, introdotto da Anthropic nel novembre 2024, che consente agli agenti di intelligenza artificiale di connettersi ai servizi di un’azienda, indipendentemente dalla loro posizione o dal momento in cui vengono invocati.

WebMCP è invece una proposta di standard per il browser, nata nel Web Machine Learning Community Group del W3C con la partecipazione di Google e Microsoft. Permette a una pagina web di dichiarare all’agente quali azioni sa eseguire, ma solo mentre la scheda è aperta e l’utente è presente.

Questa distinzione è stata chiarita il 26 ottobre 2026 dal profilo X di Chrome for Developers, dopo mesi di confusione in cui molti hanno interpretato WebMCP come “il nuovo MCP per il web”. Per chi gestisce un servizio online la scelta è concreta: usare entrambi, ognuno dove rende di più.

Definizioni di base

MCP è un protocollo server‑side. Un server MCP espone dati e azioni di un servizio (ad esempio un gestore di calendario). Un agente, come Claude o ChatGPT, si collega per leggere questi dati e invocare le azioni. La comunicazione avviene tramite chiamate di rete, ed è persistente: il server rimane attivo anche se nessun agente lo utilizza.

WebMCP è una serie di API del browser che espone gli strumenti di una pagina al agente integrato, ma solo finché la scheda è aperta. La pagina dichiara le proprie capacità e il browser le mette a disposizione dell’agente, che può così interagire direttamente con il DOM della pagina.

Prova immediata di WebMCP

WebMCP è testabile gratuitamente in Chrome 149 o versioni successive. In locale basta attivare il flag chrome://flags/#enable-webmcp-testing e riavviare il browser. Per un sito in produzione è necessario un token di origin trial. L’API è ancora in fase sperimentale, può cambiare e funziona solo con la scheda aperta.

Confronto dettagliato: MCP vs WebMCP

La guida “When to use WebMCP and MCP”, firmata da André Cipriani Bandarra e Alexandra Klepper e aggiornata al 19 maggio 2026, riassume le differenze in una tabella di sei righe.

    • Dove vive: MCP risiede nel backend, sui server dell’azienda; WebMCP vive nel frontend, all’interno della pagina.
    • Durata: MCP è persistente; WebMCP è effimero, legato alla vita della scheda.
    • Ambito: MCP copre desktop, mobile, cloud e web; WebMCP è limitato agli agenti che girano nel browser.
    • Interfaccia: MCP è esterno, senza UI del sito; WebMCP opera dentro il browser, in contatto diretto con il DOM.
    • Scoperta degli strumenti: MCP richiede una registrazione specifica per ogni agente; WebMCP permette alla pagina di registrarli durante la visita.
    • Caso tipico: MCP gestisce azioni di API in background; WebMCP permette di navigare e agire su un’interfaccia web viva.

La riga più decisiva è la durata. Un server MCP resta attivo anche se nessuno lo usa, mentre gli strumenti di WebMCP nascono con la pagina e scompaiono con la chiusura della scheda. Inoltre, il controllo della UI cambia: con MCP le app mostrano la propria interfaccia dentro quella dell’agente, mentre con WebMCP l’agente opera sul sito così com’è, come un ospite della piattaforma.

Di conseguenza, le azioni di WebMCP sono visibili all’utente (ad esempio il riempimento automatico di un form) e sfruttano la sessione già autenticata, senza richiedere un nuovo ciclo di login. Al contrario, un agente che deve cercare un volo alle tre del mattino con il browser spento non può fare affidamento su WebMCP; deve usare MCP.

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 testo parla di partner, non di concorrenti. Il tweet del 26 ottobre 2026 riassume la sintesi in tre righe:

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.

Questo messaggio è stato accompagnato da un diagramma che mostra come i due livelli si completano: il server MCP fornisce logica di business, recupero dati e lavori in background; WebMCP agisce come livello contestuale, consentendo all’agente del browser di compiere azioni rapide e affidabili sul sito mentre l’utente lo osserva.

Architettura a due livelli

Nel modello proposto, il server MCP funge da “layer di servizio”, custodendo la logica di business, la persistenza dei dati e le operazioni di lunga durata. WebMCP, invece, è il “layer contestuale” che permette all’agente di interagire direttamente con l’interfaccia web in tempo reale.

Per compiti che richiedono ore, senza una scheda attiva, si utilizza la via server‑side, ad esempio tramite MCP Tasks in Claude Code. La bozza della specifica descrive una pagina con WebMCP come un “server MCP le cui tool sono scritte sul client anziché sul backend”. Il documento dichiara che adotterà le valutazioni di rischio e le mitigazioni di MCP, ma non fissa il formato con cui gli strumenti arrivano all’agente del browser, lasciando spazio all’uso di MCP o di altri sistemi di function calling.

Le due API di WebMCP

La documentazione di Chrome (18 maggio 2026, aggiornata 7 ottobre) prevede due modalità di integrazione:

    • API imperativa: le tool sono definite in JavaScript.
    • API dichiarativa: si aggiungono semplici annotazioni ai form HTML esistenti.

Entrambe le modalità sono progressive: un sito che le ignora continua a funzionare per gli altri visitatori.

1. API imperativa (JavaScript)

Secondo la pagina sull’API imperativa, la tool si registra con registerTool sull’oggetto document.modelContext. È necessario fornire nome, descrizione, schema JSON degli input e una funzione execute. Inoltre, si aggiungono annotations per indicare al browser come trattare la tool:

    • readOnlyHint: indica che la tool non modifica lo stato.
    • consequentialHint: segnala che l’azione è significativa e può richiedere conferma dell’utente.
    • untrustedContentHint: avverte che l’output contiene testo non affidabile.

Esempio di registrazione di una tool per la ricerca di voli:

await document.modelContext.registerTool({\n  name: \"buscar_vuelo\",\n  description: \"Cerca i voli disponibili per destinazione e data.\",\n  inputSchema: {\n    type: \"object\",\n    properties: {\n      destino: { type: \"string\" },\n      fecha: { type: \"string\" }\n    },\n    required: [\"destino\", \"fecha\"]\n  },\n  annotations: { readOnlyHint: true },\n  execute: async ({ destino, fecha }) => {\n    const r = await fetch(`/api/vuelos?to=${destino}&date=${fecha}`);\n    return await r.text();\n  }\n});\n

Altri metodi utili per chi costruisce l’agente o il pannello di controllo includono:

    • getTools: elenca le tool in ordine alfabetico.
    • executeTool: avvia manualmente una tool (restituisce null se avvia una navigazione).
    • Evento toolchange: notifica quando la lista delle tool cambia.
    • Per rimuovere una tool, si passa un AbortSignal al momento della registrazione e lo si annulla.

2. API dichiarativa (HTML)

Con l’API dichiarativa non è necessario scrivere JavaScript. Si aggiungono attributi al tag <form>:

    • toolname: nome della tool.
    • tooldescription: descrizione della tool.
    • toolparamdescription
    • toolautosubmit: se presente, il form viene inviato automaticamente dall’agente.

Esempio di form dichiarativo per una richiesta di supporto:

<form toolname=\"solicitudSoporte\" tooldescription=\"Invia una richiesta di assistenza.\" action=\"/invia\">\n  <label for=\"nome\">Nome</label>\n  <input name=\"nome\">\n  <select name=\"team\" toolparamdescription=\"Il team a cui inviare la richiesta.\">\n    <option>Resi</option>\n    <option>Spedizioni</option>\n  </select>\n  <button type=\"submit\">Invia</button>\n</form>\n

Quando il form è compilato da un agente, l’evento di invio include il campo agentInvoked=true, permettendo all’applicazione di reagire diversamente. Con respondWith la pagina può restituire al modello il risultato dell’operazione.

Quando scegliere MCP, quando WebMCP

La decisione dipende principalmente dalla durata e dal contesto di utilizzo:

    • MCP è ideale per:
      • Operazioni di lunga durata o batch (es. elaborazione di dati notturna).
      • Servizi che devono essere disponibili indipendentemente dalla presenza di una scheda aperta.
      • Integrazioni con agenti che operano su più piattaforme (desktop, mobile, cloud).
    • WebMCP è consigliato per:
      • Interazioni in tempo reale con l’interfaccia utente (riempimento di form, click su pulsanti).
      • Azioni che beneficiano della sessione già autenticata dell’utente.
      • Scenari in cui l’utente è attivamente coinvolto e osserva l’operazione.

In molti casi la soluzione ottimale è una combinazione: MCP gestisce la logica di back‑end e le operazioni asincrone, mentre WebMCP fornisce un “colpo di scena” immediato quando l’utente è davanti al browser.

Considerazioni di sicurezza e mitigazioni

WebMCP eredita dal protocollo MCP le valutazioni di rischio e le mitigazioni. Tra le principali misure:

    • Le annotations (come readOnlyHint o consequentialHint) guidano il browser nel decidere se richiedere conferma all’utente.
    • Le tool sono registrate solo per la durata della scheda, riducendo la superficie di attacco.
    • Il modello di origine (origin trial) richiede un token, garantendo che solo siti autorizzati possano abilitare le API.

Il documento di specifica prevede inoltre che i server MCP possano fornire valutazioni di rischio aggiuntive, rendendo possibile un controllo centralizzato anche per le tool client‑side.

Conclusioni

WebMCP e MCP non sono concorrenti ma complementari. MCP offre un’interfaccia persistente e server‑side per collegare agenti IA a servizi aziendali, mentre WebMCP consente un’interazione rapida e visibile direttamente nella pagina web aperta. La chiave è capire quando la durata effimera di una scheda è sufficiente (interazioni UI) e quando è necessario un servizio sempre attivo (processi di back‑end, compiti lunghi).

Per gli sviluppatori, la strada consigliata è:

    • Implementare MCP per esporre le API di servizio e le operazioni di lunga durata.
    • Aggiungere WebMCP per le azioni contestuali che l’utente può vedere e confermare.
    • Utilizzare le annotazioni di sicurezza per definire il livello di fiducia di ogni tool.

In questo modo si ottiene una piattaforma robusta, sicura e capace di sfruttare al meglio le potenzialità degli agenti IA sia sul server che nel browser.