WebMCP e MCP sono due strumenti distinti che risolvono problemi diversi. MCP (Model Context Protocol) collega gli agenti AI ai servizi di un'azienda, ovunque si trovino e in qualsiasi momento. WebMCP, invece, collega gli agenti a un sito web finché è aperto in una scheda del browser, con l'utente che guarda.

Definizioni e origini

MCP è un protocollo aperto presentato da Anthropic nel novembre 2024. Un server MCP espone dati e azioni di un servizio, come un gestionale o un calendario, permettendo a un agente come Claude o ChatGPT di collegarsi per leggerli e usarli. WebMCP è una proposta di standard per il browser, nata nel Web Machine Learning Community Group del W3C con editori di Google e Microsoft. Permette a una pagina di dichiarare all'agente quali azioni sa compiere.

Differenze chiave

WebMCP è un insieme di API del browser che espone gli strumenti di una pagina all'agente integrato mentre la scheda è aperta. MCP, invece, è un protocollo lato server che rende dati e azioni disponibili agli agenti ovunque e in qualsiasi momento. La guida "When to use WebMCP and MCP" riassume il confronto in sei righe:

    • MCP: Backend, server dell'azienda, persistente, desktop, mobile, cloud, web, interfaccia esterna, registrazione specifica per ogni agente, azioni API in background.
    • WebMCP: Frontend, dentro la pagina, effimero, legato alla scheda, agenti che girano nel browser, dentro il browser, a contatto col DOM, la pagina registra gli strumenti durante la visita, navigare e agire su un'interfaccia web viva.

La differenza più significativa è la durata. Un server MCP resta attivo anche quando nessuno lo usa, mentre gli strumenti WebMCP nascono con la pagina e spariscono con la scheda. Con MCP, le app mostrano la propria interfaccia dentro quella dell'agente, mentre con WebMCP l'agente lavora sul sito così com'è, come un ospite della piattaforma.

WebMCP sostituisce MCP?

No. La documentazione di Chrome è chiara: WebMCP non è un'estensione o un sostituto di MCP. Lo stesso tweet del 26 ottobre ripete la sintesi in tre righe:

    • No, WebMCP non sostituisce MCP.
    • MCP collega gli agenti ai tuoi servizi.
    • WebMCP collega gli agenti al tuo sito web finché è aperto e l'utente è coinvolto.

L'architettura proposta ha due livelli. Il server MCP fa da livello di servizio e custodisce la logica di business, il recupero dei dati e i lavori in background. WebMCP resta lo strato contestuale, permettendo all'agente del browser di compiere azioni rapide e affidabili sul sito mentre l'utente lo ha davanti. Per i lavori che durano ore, che non hanno scheda a cui appoggiarsi, esiste già la strada lato server.

Come funziona WebMCP

La documentazione di Chrome prevede due strade. La prima, imperativa, definisce gli strumenti in JavaScript. La seconda, dichiarativa, aggiunge poche annotazioni ai form HTML che il sito ha già. Entrambe si presentano come un miglioramento progressivo, quindi un sito che le ignora continua a funzionare per tutti gli altri visitatori.

API imperativa

Secondo la pagina sull'API imperativa, lo strumento si registra con registerTool sull'oggetto document.modelContext e richiede nome, descrizione, schema JSON degli input e una funzione execute. Le annotazioni dicono al browser con che cautela trattarlo.

    • readOnlyHint segnala che non modifica nulla.
    • consequentialHint che l'azione è seria e può richiedere la conferma dell'utente.
    • untrustedContentHint che l'output contiene testo non attendibile.

Gli altri metodi servono a chi costruisce l'agente o il pannello di controllo. getTools elenca gli strumenti in ordine alfabetico, executeTool ne lancia uno a mano (e restituisce null se parte una navigazione), l'evento toolchange avvisa quando l'elenco cambia. Per ritirare uno strumento basta passare un AbortSignal alla registrazione e annullarlo.

API dichiarativa

Nella pagina sull'API dichiarativa non si scrive JavaScript. Al tag <form> si aggiungono toolname e tooldescription; il browser ricava lo schema dei campi da quello che c'è nel modulo, usando le etichette oppure l'attributo opzionale toolparamdescription. Senza toolautosubmit, l'invio resta all'utente, che deve cliccare il pulsante. Se un attributo viene rimosso, lo strumento sparisce.

Quando a compilare il modulo è un agente, l'evento di invio porta un campo agentInvoked impostato a vero, così l'applicazione può comportarsi in modo diverso. Con respondWith la pagina restituisce al modello l'esito dell'operazione, mentre gli eventi toolactivated e toolcancel segnalano quando l'agente ha precompilato i campi e quando l'utente ha cambiato idea.

Come lavorano insieme: il caso della compagnia aerea

Prendiamo un esempio nostro, che non viene dalla documentazione. Una compagnia aerea offre un'app sul sito e un'API per prenotare. Il server MCP gestisce le prenotazioni, il calendario e le informazioni sui voli, mentre WebMCP permette all'agente di interagire con il sito web in tempo reale. Ad esempio, un utente può chiedere all'agente di cercare un volo specifico, e l'agente utilizzerà WebMCP per interagire con il sito web della compagnia aerea, mostrando i risultati in tempo reale.

In questo modo, MCP e WebMCP lavorano insieme per offrire un'esperienza utente integrata e senza soluzione di continuità. MCP gestisce le operazioni di backend, mentre WebMCP permette all'agente di interagire con l'interfaccia utente del sito web in modo fluido e intuitivo.