WebMCP: la svolta “agent-first” per controllare le web app senza screenshot e tentativi a vuoto

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:

1. scopre quali strumenti sono disponibili su quella pagina/app
2. invoca un tool con un input strutturato (schema)
3. 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.