Il problema degli agenti AI che “guardano” il browser

Chi ha provato a far navigare un agente AI su un sito web sa quanto sia fragile il paradigma attuale: screenshot della pagina, analisi visiva per capire dove cliccare, simulazione del click, nuovo screenshot per verificare cosa è successo, e via così ad ogni passaggio. Funziona, ma è lento, costoso in token e si rompe alla prima modifica del layout o al primo elemento che carica in ritardo. È lo stesso problema che affligge da anni gli script di web scraping tradizionali, solo applicato ad agenti che devono anche “capire” cosa stanno guardando.

WebMCP (Web Model Context Protocol) nasce per rovesciare questo approccio: invece di far indovinare all’agente dove cliccare, è il sito stesso a dichiarare quali azioni sono disponibili, con che parametri, e come invocarle direttamente in codice. Cloudflare ha da poco reso disponibile il supporto sperimentale a WebMCP nella sua piattaforma Browser Run, un’occasione utile per capire come funziona davvero questo standard ancora in bozza.

Cos’è WebMCP e chi lo sta sviluppando

La proposta iniziale è stata pubblicata nell’agosto 2025 da ingegneri di Microsoft e Google, e oggi è portata avanti principalmente dal team Chrome come bozza sperimentale — non è ancora uno standard web consolidato, ma è già implementabile e testabile in Chrome beta. L’idea centrale è una nuova API del browser, navigator.modelContext, che qualsiasi pagina web può usare per registrare “tool” strutturati, nello stesso spirito del Model Context Protocol usato da Claude e altri assistenti per esporre funzionalità a un LLM — solo che qui il “server” MCP è JavaScript in esecuzione lato pagina, e l’host è il browser stesso.

navigator.modelContext.registerTool({
  name: "scroll_to_section",
  description: "Scorre la pagina fino a una sezione specifica",
  inputSchema: {
    type: "object",
    properties: { id: { type: "string" } },
    required: ["id"]
  },
  async execute({ id }) {
    document.getElementById(String(id))?.scrollIntoView({ behavior: "smooth" });
    return "ok";
  }
});

Un agente che visita la pagina può interrogare l’elenco dei tool disponibili in un dato momento — che cambia dinamicamente in base allo stato della pagina — ed eseguirli con parametri tipizzati, invece di simulare interazioni DOM.

Provarlo con Cloudflare Browser Run

Cloudflare ha aggiunto un pool sperimentale di sessioni browser con Chrome beta (dove WebMCP è disponibile) alla sua piattaforma Browser Run, separato dal pool di produzione che resta su Chrome stabile. Per avviare una sessione di test basta la CLI wrangler:

# assicurarsi di avere l'ultima versione di wrangler
npm i -g wrangler@latest

# creare una sessione browser "lab" con keep-alive di 5 minuti
wrangler browser create --lab --keepAlive 300

Dalla console DevTools della sessione si può interrogare direttamente l’elenco dei tool esposti da un sito che implementa WebMCP (Cloudflare fornisce come demo pubblica una finta catena di hotel):

navigator.modelContextTesting.listTools();
// [
//   { "name": "view_hotel", "description": "...", "inputSchema": "..." },
//   { "name": "search_location", "description": "...", "inputSchema": "..." },
//   { "name": "lookup_amenity", "description": "...", "inputSchema": "..." }
// ]

Eseguire un tool è altrettanto diretto:

await navigator.modelContextTesting.executeTool(
  "search_location",
  JSON.stringify({ query: "Paris" })
);

Un dettaglio interessante per chi progetta flussi che coinvolgono azioni sensibili (pagamenti, prenotazioni, conferme): la specifica prevede nativamente lo human-in-the-loop. Un tool come complete_booking può sospendere l’esecuzione in attesa che l’utente confermi manualmente un’azione nell’interfaccia, prima di restituire il risultato all’agente.

Collegare un agente AI reale

Per far interagire un vero agente con siti WebMCP, Cloudflare consiglia di appoggiarsi a Chrome DevTools MCP, configurabile in client come Claude Code o Cursor puntando al WebSocket endpoint della sessione lab:

{
  "browser-rendering-cdp": {
    "command": [
      "npx", "-y", "chrome-devtools-mcp@latest",
      "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser?keep_alive=600000&lab=true",
      "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}"
    ]
  }
}

Il parametro lab=true è ciò che instrada la connessione verso una sessione con WebMCP abilitato invece che verso il pool di produzione standard.

Il lato server: esporre i tool di un Worker al browser

Per chi già costruisce agenti su Cloudflare Workers usando McpAgent, il pacchetto agents include un adapter sperimentale, registerWebMcp, che fa da ponte tra i tool esposti da un server MCP remoto e il registro navigator.modelContext della pagina:

import { registerWebMcp } from "agents/experimental/webmcp";

const handle = await registerWebMcp({
  url: "/mcp",
  prefix: "remote.",
  getHeaders: async () => ({ Authorization: `Bearer ${await getToken()}` })
});

L’adapter scopre i tool del server (tools/list), li registra come shim locali il cui execute inoltra la chiamata al server via client.callTool(), e si mantiene sincronizzato ascoltando le notifiche tools/list_changed. Il risultato pratico è una separazione naturale: tutto ciò che riguarda il DOM (scorrimento, focus, clipboard, stato locale in Zustand o IndexedDB) resta tool in-page; tutto ciò che richiede storage durevole, credenziali segrete o chiamate a API di terze parti resta lato server, ma diventa comunque visibile e invocabile dall’AI del browser attraverso lo stesso registro.

Cosa considerare prima di adottarlo

Vale la pena essere chiari sulla maturità dello standard: le API navigator.modelContext e navigator.modelContextTesting funzionano oggi solo in sessioni Chrome beta o “lab”, non in produzione stabile, e sia la specifica sia l’adapter di Cloudflare sono etichettati esplicitamente come sperimentali, soggetti a modifiche non retrocompatibili. Sul fronte sicurezza, esporre tool strutturati a un agente terzo significa anche esporre una superficie potenzialmente sfruttabile — collisioni di nomi tra tool silenziose, o un agente compromesso che invoca un tool con parametri malevoli, sono scenari da considerare al pari di qualsiasi altra API pubblica. Per chi sviluppa siti pensati per essere “agent-friendly” — e-commerce, prenotazioni, dashboard SaaS — è comunque il momento giusto per iniziare a sperimentare, prima che il pattern diventi lo standard de facto per l’interazione tra agenti AI e web.

Conclusione

WebMCP propone un cambio di paradigma sensato: far dichiarare alle applicazioni web le proprie capacità in modo strutturato, invece di costringere gli agenti AI a reverse-engineering visivo dell’interfaccia. Non è ancora pronto per la produzione, ma la direzione — supportata sia da Google sia da Microsoft, e ora testabile concretamente su Cloudflare Browser Run — merita di essere seguita da chi sviluppa applicazioni web che prima o poi dovranno “parlare” anche con un agente, non solo con un umano davanti a un browser.

Fonte: Cloudflare Browser Run Docs – WebMCP e Cloudflare Agents – WebMCP adapter