WebMCP nel 2026: l'API con cui gli agenti usano il tuo SaaS

WebMCP è un'API del browser con cui una pagina registra i propri strumenti, ognuno descritto in JSON Schema, così che un agente AI dentro il browser possa chiamarli direttamente invece di leggere lo schermo e indovinare a cosa serve un pulsante.

Oggi è un Draft Community Group Report del W3C Web Machine Learning Community Group, curato da ingegneri di Google e Microsoft, e gira come origin trial su Chrome dalla versione 149. Non è uno standard W3C e non è nemmeno sul percorso di standardizzazione. A leggere la bozza adesso dovrebbero essere i team che rilasciano checkout, dashboard, ricerca e prenotazioni: sono le operazioni che un agente proverà a portare a termine al posto dell'utente.

La versione in trenta secondi

Un agente nel browser oggi usa il prodotto come farebbe una persona, ma peggio. Legge l'accessibility tree o uno screenshot, deduce l'intenzione dalle etichette, clicca, aspetta, rilegge. Ogni giro costa token. Ogni giro si inceppa su una modale, su una lista caricata in ritardo, su tre pulsanti che nella stessa pagina dicono tutti Continua.

WebMCP ribalta il flusso. La pagina dichiara cosa sa fare. L'agente chiama la funzione dichiarata. Il gestore gira nel contesto JavaScript della pagina stessa, con la sessione con cui l'utente ha già fatto login. Nessuna seconda API, nessuna autenticazione a parte, nessun lavoro lato server.

Perché far indovinare il DOM a un agente costa caro

Il costo si misura. Un paper del 2025 pubblicato su arXiv con lo stesso nome webMCP, un prototipo client-side distinto dalla bozza di Google e Microsoft, ha eseguito 1.890 chiamate API reali su flussi di acquisto, autenticazione e gestione contenuti. Inserire nella pagina i metadati strutturati dell'interazione ha ridotto del 67,6% il carico di elaborazione mantenendo il 97,9% di task completati, con un costo per interazione più basso tra il 34% e il 63% (Perera, arXiv:2508.09171).

Sono numeri di un prototipo, non dell'implementazione di Chrome: vanno letti come direzione, non come promessa. La direzione non è controversa. Una chiamata a funzione tipizzata costa meno di uno screenshot più una catena di deduzioni.

Come funziona l'API

L'interfaccia espone tre metodi e un evento: registerTool, getTools, executeTool e il gestore ontoolchange. Uno strumento è un nome, una descrizione, uno schema di input e una funzione asincrona.

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add an item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: { text: { type: "string", description: "The todo item text" } },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return { content: [{ type: "text", text: "Added todo: " + text }] };
  }
});

Chrome documenta due strade. Quella imperativa è il codice qui sopra: strumenti definiti in JavaScript per navigazione, compilazione di form e cambi di stato. Quella dichiarativa permette di annotare un normale form HTML perché il browser lo esponga come strumento senza scrivere altro codice. I DevTools di Chrome hanno un pannello sperimentale che elenca gli strumenti registrati sulla pagina, li invoca a mano e verifica il JSON Schema (Chrome for Developers).

A che punto è la specifica a settembre 2026

• Stato. Draft Community Group Report del W3C Web Machine Learning Community Group. Non è uno standard e non è sul percorso di standardizzazione.
• Chrome. Origin trial dalla versione 149, annunciato a maggio 2026.
• L'API si è spostata. Il getter è passato da navigator.modelContext a document.modelContext. Chrome 150 ha deprecato il nome su navigator tenendolo come alias: il codice vecchio continua a funzionare e il cambiamento passa facilmente inosservato.
• Un metodo è sparito. provideContext() è uscito dalla bozza a marzo 2026. Ogni guida che lo mostra ancora è vecchia.
• Edge. Microsoft è co-curatrice della specifica, ma WebMCP non compare come rilasciato nelle note pubbliche della piattaforma Edge. Le affermazioni di terzi su un supporto nativo in Edge restano non confermate.
• Firefox e Safari. Partecipano al community group. Nessuno dei due si è impegnato su una data.

È un bersaglio in movimento. Tutto quello che si sviluppa su questa base nel 2026 è un esperimento con una manutenzione da pagare.

Cosa cambia per il design delle interfacce SaaS

Il lavoro interessante qui è di design, non solo di sviluppo.

L'elenco degli strumenti è l'architettura dell'informazione, detta ad alta voce

Registrare gli strumenti obbliga a nominare quello che il prodotto fa, con verbi che uno sconosciuto capisce. Se un team non riesce a elencare otto strumenti della propria dashboard senza discutere, le funzioni del prodotto non erano chiare nemmeno prima. Scrivere un server MCP produce lo stesso effetto: dare i nomi è un esercizio di prodotto travestito da esercizio di API.

Le descrizioni degli strumenti sono microcopy di interfaccia

Il modello legge la descrizione per decidere se chiamare lo strumento. È il lavoro che l'etichetta di un pulsante fa per una persona, con un lettore diverso. "Aggiorna impostazioni" è inutile per un agente quanto lo è per un utente. "Cambia l'email per le notifiche di questo workspace" no.

Letture e scritture vanno trattate diversamente

Le linee guida di Chrome prevedono readOnlyHint per gli strumenti che non cambiano nulla e untrustedContentHint per quelli che restituiscono dati presi da fuori. Ordinare una tabella e disdire un abbonamento non si registrano con lo stesso atteggiamento.

La conferma si sposta sul confine

Un agente che chiama uno strumento capace di cancellare record, mandare messaggi o spostare denaro ha bisogno di una persona nel giro. Quella conferma è una schermata, e qualcuno deve disegnarla. L'interfaccia non sparisce quando arriva l'agente: si concentra nei punti in cui sbagliare costa.

Lo schermo deve comunque funzionare

Ogni strumento registrato dalla pagina ha un corrispettivo umano sulla stessa pagina. Due contratti da tenere allineati, due percorsi da testare. È un costo reale ed è l'argomento onesto per aspettare. Su come una schermata viene letta da un utente non umano abbiamo scritto qui.

Quando invece conviene aspettare

Quattro casi in cui oggi la risposta è no.

• Il traffico è umano. Se nessuna quota misurabile delle sessioni arriva da un agente, si paga manutenzione per un'ipotesi.
• I flussi critici sono irreversibili. Pagamenti, cancellazioni e messaggi in uscita hanno il rischio di injection più alto e la tolleranza più bassa a una chiamata sbagliata.
• Non c'è modo di osservare le chiamate. Senza log su quale strumento è partito, con quali argomenti e con quale risposta, non si fa né debug né audit.
• Il team ha già un server MCP con le stesse capacità. Duplicare il contratto prima che l'API del browser si assesti porta disallineamento, non copertura.

Cosa segnala Chrome sul fronte sicurezza

Chrome pubblica una pagina dedicata alla sicurezza degli agenti e gli avvertimenti sono precisi (Agent security considerations for WebMCP). Una pagina malevola può nascondere istruzioni nei nomi degli strumenti, nelle descrizioni e negli output: è prompt injection indiretta con un nuovo canale di consegna. Strumenti con troppi parametri si lasciano convincere a far uscire dati dell'utente. Uno strumento può dichiarare una cosa e farne un'altra.

Le contromisure non sono affascinanti: limiti stretti sui caratteri di nomi e descrizioni, hint che marcano gli strumenti di sola lettura e i contenuti non affidabili, conferma umana esplicita prima di qualsiasi azione irreversibile, log su ogni chiamata. Chi ha già blindato un server MCP riconosce la forma del lavoro. La versione lato server l'abbiamo raccontata in blindare un server MCP per l'enterprise.

WebMCP e MCP non sono la stessa cosa

I nomi si somigliano, le architetture no. Un server MCP sta sulla tua infrastruttura, parla un transport, si porta dietro la propria autenticazione e serve qualsiasi client si colleghi. WebMCP sta nella pagina, gira nel browser e usa la sessione che l'utente ha già. Il primo espone il prodotto a qualunque agente, ovunque. Il secondo espone la pagina che l'utente sta guardando all'agente che gliela guarda da sopra la spalla.

Molti team SaaS finiranno per averli entrambi, con compiti diversi. Se il dubbio è sul lato server, si parte da cos'è MCP e perché un SaaS ha bisogno di un server, poi dalla scelta tra gestito e self-hosted. La specifica in sé è corta abbastanza da leggersi in un pomeriggio (bozza WebMCP), ed è la ricerca meno costosa che un team di prodotto possa fare in questo trimestre.