Dalle automazioni fragili basate su computer vision a strumenti JavaScript nativi esposti dal browser: come cambiano affidabilità, costi e tempi degli AI agent sul web.
Il problema dei browser agent “a screenshot”: funziona, ma non è progettato per farlo
Negli ultimi mesi l’idea di computer use è diventata quasi banale: agent che aprono il browser, cliccano bottoni, compilano form e navigano siti come faremmo noi. Il punto non è se si possa fare, ma quanto sia affidabile.
Il meccanismo classico è fragile per un motivo strutturale: l’agent deve continuamente ricostruire lo stato dell’interfaccia osservandola. In pratica:
- esegue un’azione (click, input, select…)
- acquisisce uno screenshot
- interpreta lo screenshot
- decide il prossimo passo
- ripete
È un loop costoso e lento, e soprattutto introduce errori “banali”: un elemento non è dove ci si aspetta, un modale copre il pulsante, un caricamento cambia layout, una label è ambigua. La UI è pensata per umani, non per agent.
Sintomo tipico: ripartire da zero invece di proseguire
Un comportamento frequente è la mancanza di continuità operativa: quando l’utente chiede una variante (“ok, ora filtrami solo in centro”), l’agent spesso non applica un delta sullo stato corrente, ma rifà il flusso dall’inizio. Se la task è semplice, è solo fastidioso; se la task è un form lungo o una procedura articolata, diventa impraticabile.
L’alternativa: smettere di far “indovinare” la UI e dare strumenti nativi
Qui entra in gioco WebMCP: un’API pensata per permettere alle web app di esporre tools JavaScript direttamente agli AI agent.
Invece di interpretare pixel e layout, l’agent:
- scopre quali strumenti sono disponibili su quella pagina/app
- invoca un tool con un input strutturato (schema)
- riceve un risultato strutturato
È un cambio di paradigma: dall’interazione “visiva” (computer vision) a un’integrazione agent-first, dove il frontend diventa un vero “provider” di azioni.
Perché è più affidabile
- Niente ambiguità: un tool moveIssueToColumn è più chiaro di “trascina quel ticket lì”.
- Meno stato implicito: lo stato è gestito dall’app, non dedotto dall’agent.
- Meno fragilità da layout/CSS: riorganizzare la UI non rompe i tools.
Cos’è WebMCP, in termini concreti
WebMCP è attualmente una spec in bozza in ambito W3C (community group dedicato alle tecnologie ML sul web). La definizione, semplificando, è:
Un’API che consente alle web application di fornire strumenti (tools) basati su JavaScript agli AI agent.
Questa API non “uccide” MCP: lo estende nel contesto web. Il modello mentale resta quello dei tool-call che già conosciamo: nome + descrizione + schema input + execute().
Obiettivi e non-obiettivi: cosa aspettarsi (e cosa no)
Dalle linee guida della spec emergono alcuni punti importanti.
Obiettivi
- Human-in-the-loop: flussi dove l’utente rimane nel controllo, con conferme e supervisione.
- Integrazione più semplice agent ↔︎ sito web.
- Meno disintermediazione: invece di “scrapare” e automatizzare alla cieca, il sito offre punti di integrazione ufficiali.
- Migliorare accessibilità e scenari headless tramite agent.
Non-obiettivi
- Automazione fully autonomous stile “lancio un browser headless e fa tutto da solo senza supervisione”. Non è il focus.
- Sostituzione dell’integrazione backend: WebMCP non rimpiazza API server-side o MCP server; è un complemento lato web.
- Sostituzione della UI: l’interfaccia per umani resta fondamentale; qui si aggiunge una corsia preferenziale per agent.
Performance: accuratezza, tempo e costo (la parte che interessa davvero)
Quando si confrontano diverse tecniche per far agire un agent in un browser (computer vision, DOM+vision, accessibility tree…), WebMCP tende a primeggiare su tre metriche che nel lavoro quotidiano contano più di quanto si ammetta:
- accuratezza più alta
- tempo mediano per task drasticamente inferiore
- costo per task molto più basso
Il motivo è semplice: con i tools l’agent fa meno “ragionamento di contorno”, consuma meno contesto e non spreca turni in screenshot/interpretazione.
E questo cambia anche la strategia operativa: se un’esecuzione fallisce, ritentare costa poco (in tempo e token). Con computer use, un retry può significare minuti.
Come si usa WebMCP oggi: Chrome e flag
Al momento l’adozione è ancora in fase iniziale. In Chrome è disponibile tramite flag sperimentale (area chrome://flags), dove si abilita la voce di testing relativa a WebMCP.
Questo aspetto è importante: non stiamo parlando di una feature “ovunque e sempre”, ma di una tecnologia che sta maturando e che vale la pena iniziare a conoscere adesso.
Due modi per esporre tools: API imperativa e dichiarativa
WebMCP prevede due stili complementari.
1) API imperativa (JavaScript)
È l’approccio più flessibile: dalla pagina si ottiene un model context e si registrano tools con:
- name: corto ma descrittivo
- description: precisa, orientata all’agent (evitare ambiguità)
- inputSchema: schema dei parametri
- execute(input): implementazione che compie l’azione e ritorna un risultato
Qui valgono le stesse best practice dei tool MCP lato server: nomi consistenti, descrizioni operative, schema rigoroso, error handling esplicito.
Punto chiave frontend: l’execute non può “barare”. Deve aggiornare davvero lo stato dell’app (store, cache, UI) come se l’azione fosse stata fatta da un utente. In React, ad esempio, significa orchestrare correttamente setState/store actions e side effects.
2) API dichiarativa (HTML/forms)
È l’approccio più “zero effort” quando hai già form ben strutturati.
L’idea: un form può diventare un tool. Definisci attributi che descrivono tool e azione (nome/descrizione), e i campi del form diventano automaticamente l’input del tool, con tipi dedotti (text, select, ecc.).
È particolarmente interessante per:
- pagine di supporto (ticket, richieste)
- onboarding e wizard
- configurazioni e pannelli amministrativi
Debug: ispezionare i tools esposti dalla pagina
Per chi sviluppa, diventa essenziale capire “cosa vede” un agent. Esistono estensioni per Chrome che mostrano:
- elenco tools registrati
- descrizioni
- input schema
- possibilità di testare invocazioni
Questo pezzo di tooling è più importante di quanto sembri: se un agent sbaglia, spesso non è “colpa dell’agent”, ma di tools poco chiari, schema debole o risultati non deterministici.
Implicazioni pratiche per chi fa frontend
WebMCP spinge verso un’idea molto concreta: oltre alla UI per umani, la tua web app può (e probabilmente dovrà) avere una superficie di azioni stabili pensata per agent.
In pratica:
- identifica le azioni frequenti (crea, sposta, approva, esporta, cerca)
- esponile come tools con naming consistente
- progetta input schema “anti-ambiguità” (id, enum, vincoli)
- rendi l’esecuzione idempotente quando possibile
- cura i risultati: ritorna info utili (es. id creato, stato aggiornato, errori validazione)
Sintesi: meno UI-guessing, più contratti
Il computer use basato su screenshot è un compromesso: utile per demo e integrazioni rapide, ma intrinsecamente lento e incerto perché chiede all’agent di interpretare una UI pensata per umani.
WebMCP propone una direzione più pulita: trasformare le azioni chiave della web app in tools con contratti (descrizione + schema + execute). Il beneficio non è solo “più accuratezza”: è soprattutto meno tempo e meno costo per ottenere risultati ripetibili.
Se oggi stai progettando un prodotto con flussi operativi complessi (dashboard, backoffice, workflow, form lunghi), iniziare a ragionare in ottica agent-first non è futurismo: è un modo pragmatico per rendere l’automazione finalmente affidabile.
Articolo originale: https://frontendfacile.it/blog/webmcp-la-svolta-agent-first-per-controllare-le-web-app-senza-screenshot-e-tenta
Top comments (0)