Tutorial WebMCP: crea siti web pronti per gli agenti con il nuovo standard di Chrome

Al momento, gli agenti AI navigano il web come un turista che legge un menù in una lingua straniera: strizzando gli occhi sui pixel, indovinando cosa fanno i pulsanti e sperando che la pagina non cambi layout a metà clic. Google e Microsoft hanno deciso che il problema meritava una soluzione seria.

A febbraio 2026, Chrome 146 ha distribuito un’anteprima iniziale di WebMCP, uno standard web proposto che permette ai siti di dire agli agenti esattamente cosa possono fare e come farlo. 

Niente più screen scraping. 

Niente più reverse engineering del DOM.

In questo tutorial, ti mostro cos’è davvero WebMCP, come configurare l’ambiente e come creare integrazioni funzionanti sia con l’approccio basato su HTML sia con quello basato su JavaScript. 

Coprirò anche suggerimenti di sicurezza per gestire le invocazioni degli agenti e come testare tutto con gli strumenti di debug di Chrome.

Che cos’è WebMCP?

WebMCP (Web Model Context Protocol) è un nuovo standard del browser che consente ai siti web di dichiarare le proprie funzionalità come strumenti strutturati che gli agenti AI possono chiamare direttamente. Invece di costringere un’AI a "leggere" e fare clic su un’interfaccia visiva, WebMCP trasforma la pagina stessa in una pulita API lato client.

Pensiamo a cosa succede quando oggi un agente prova a prenotare un volo su un sito di viaggi. Deve capire quale campo si aspetta la città di partenza, indovinare se il formato della data è MM/DD o YYYY-MM-DD, trovare il pulsante di ricerca e sperare che la pagina non si ricarichi con un layout mai visto prima. Se invece il sito potesse pubblicare uno strumento chiamato searchFlights con parametri tipizzati per origine, destinazione, date e numero di passeggeri, tutto quell’indovinare sparirebbe.

WebMCP lo rende possibile. Un sito registra strumenti tramite un’API del browser chiamata navigator.modelContext, dove ogni strumento ha un nome, una descrizione in linguaggio naturale e uno schema JSON per input e output. L’agente scopre questi strumenti, invia parametri conformi allo schema e riceve in cambio dati strutturati.

Ingegneri di Google e Microsoft hanno scritto insieme la specifica all’interno del gruppo di comunità W3C Web Machine Learning. L’architettura è esclusivamente lato client, il che la distingue dai tipici deployment MCP in cui un server backend separato gestisce l’esecuzione degli strumenti. Dove l’MCP standard collega gli agenti ai server backend tramite JSON-RPC, WebMCP mantiene tutto nella scheda del browser. 

Gli strumenti vengono eseguiti nel JavaScript della pagina; condividono qualunque sessione l’utente abbia già, e il browser media ciò che l’agente è autorizzato a fare. Se hai già lavorato con server MCP (per esempio, nel nostro tutorial sul Model Context Protocol (MCP)), i concetti di registrazione degli strumenti ti sembreranno familiari, ma il modello di deployment è molto diverso.

Funzionalità e capacità chiave di WebMCP

Sono disponibili due API, con scopi diversi:

• La API dichiarativa funziona tramite annotazioni HTML. Aggiungi gli attributi toolname e tooldescription a un elemento <form>, insieme agli opzionali toolparamdescription sui singoli campi, e il browser genera uno schema JSON dalla struttura del form esistente. I siti che hanno già form ben costruiti richiedono pochissime modifiche per diventare accessibili agli agenti.
• L’API imperativa ti dà pieno controllo programmatico. Chiami navigator.modelContext.registerTool() e definisci nome, descrizione, schema di input e una callback execute. È la strada giusta per tutto ciò che è troppo dinamico per un semplice form: workflow multi-step, chiamate API, risultati calcolati e logiche di validazione personalizzate.

Entrambe le API consentono la registrazione dinamica, ovvero gli strumenti possono comparire e scomparire al variare dello stato della pagina. Prima del login, potresti esporre solo uno strumento login. Dopo l’autenticazione, vengono registrati gli strumenti specifici dell’account.

• Gli schemi JSON su ogni strumento specificano tipi, enum, campi obbligatori e descrizioni dei parametri. Questa struttura impedisce agli agenti di inventare valori dei parametri o di inserire i dati nei campi sbagliati.
• Le pseudo-classi CSS forniscono feedback visivo durante le interazioni dell’agente. Chrome applica :tool-form-active a qualsiasi form che un agente sta compilando e :tool-submit-active al pulsante di invio di quel form. La persona che guarda lo schermo può vedere esattamente su quale form sta lavorando l’agente.

Non esiste ancora un meccanismo di discovery integrato. Un agente deve visitare la tua pagina prima di poter apprendere quali strumenti offri. Il team di Chrome ha discusso l’idea di un file manifest .well-known/webmcp per il discovery pre-visita, ma non è stato specificato nulla in tal senso.

Poiché WebMCP è ancora in anteprima iniziale, aspettati alcune asperità e cambiamenti in corso, soprattutto perché la specifica è già evoluta tra le versioni, inclusa la rimozione dei metodi provideContext e clearContext a marzo 2026. 

La discoverability degli strumenti è limitata alle pagine che hai già visitato, e preoccupazioni di sicurezza come il prompt injection e l’esfiltrazione dei dati tramite chaining di strumenti sono riconosciute nella specifica ma non ancora completamente risolte. Prima di iniziare, puoi controllare il changelog nella documentazione di Chrome, dato che la superficie dell’API potrebbe essere cambiata da quando questo tutorial è stato scritto.

Prerequisiti e setup dell’ambiente per WebMCP

Impostare l’ambiente richiede qualche minuto, ma la versione sbagliata di Chrome te ne farà perdere molti di più.

È necessaria Chrome Canary versione 146.0.7672.0 o superiore. Le versioni Stable, Beta e Dev di Chrome non includono il flag WebMCP. Diversi sviluppatori nei forum di Chrome hanno scritto di aver installato la versione sbagliata e aver perso tempo a chiedersi perché il flag mancasse. Scarica specificamente dalla pagina Canary.

Pagina di download di Chrome Canary

Oltre al browser, ti serve una conoscenza operativa dei form HTML e della gestione degli eventi in JavaScript. Se ti serve un ripasso, il corso Introduction to JavaScript di DataCamp copre i fondamentali. 

L’estensione Model Context Tool Inspector non è strettamente necessaria, ma vale la pena installarla. Elenca tutti gli strumenti registrati sulla pagina corrente, ti permette di eseguirli manualmente con parametri inseriti da te e ha il supporto integrato alla Gemini API per testare l’invocazione tramite linguaggio naturale.

Abilitare il flag sperimentale di WebMCP

Con Chrome Canary installato:

1. Vai a chrome://flags/#enable-webmcp-testing nella barra degli indirizzi.
2. Imposta il flag "WebMCP for testing" su Enabled.
3. Clicca Relaunch in fondo alla pagina.

La pagina chrome://flags con il flag WebMCP evidenziato e impostato su Enabled

Dopo il riavvio, apri DevTools (F12), vai alla scheda Console ed esegui:

console.log(navigator.modelContext);Offerto da

Console di DevTools che mostra l’oggetto navigator.modelContext.

La presenza di un oggetto in output (invece di undefined) conferma che l’API è disponibile. Da qui, puoi installare l’estensione Model Context Tool Inspector e aprire la demo di viaggi di Google per vedere la registrazione degli strumenti in azione su una pagina reale. 

Lì, ti basta avviare l’estensione, e dovresti vedere qualcosa di simile a quanto segue:

Verifica degli strumenti searchFlights usando l’estensione Model Context Tool Inspector di Chrome con il sito demo Flight Search di Google. 

Come puoi vedere, il Model Context Tool Inspector rileva lo strumento searchFlights ed espone il suo schema di input, offrendo al modello una comprensione molto più chiara di come interagire con la pagina.

Crea la tua prima integrazione WebMCP

Ci sono due modi per creare la tua prima integrazione WebMCP, e li descriviamo entrambi nelle sezioni seguenti:

L’approccio dichiarativo (HTML)

Il modo più semplice per registrare uno strumento WebMCP è annotare un form già presente nella tua pagina. Ecco un form di ricerca prodotti standard senza annotazioni WebMCP:

<form action="/search" method="GET">
  <label for="query">Search term</label>
  <input type="text" name="query" id="query" required>

  <label for="category">Category</label>
  <select name="category" id="category">
    <option value="all">All categories</option>
    <option value="electronics">Electronics</option>
    <option value="books">Books</option>
    <option value="clothing">Clothing</option>
  </select>

  <button type="submit">Search</button>
</form>Offerto da

Quattro attributi trasformano questo form in uno strumento richiamabile da un agente. toolname e tooldescription vanno sul tag <form> stesso. Sui singoli campi, toolparamtitle e toolparamdescription sovrascrivono le etichette predefinite quando non sono abbastanza descrittive perché un agente le capisca:

<form toolname="search_products"
      tooldescription="Search the product catalog by keyword and optional category filter"
      action="/search" method="GET">

  <label for="query">Search term</label>
  <input type="text" name="query" id="query" required
         toolparamdescription="The keyword or phrase to search for in product titles and descriptions">

  <label for="category">Category</label>
  <select name="category" id="category"
          toolparamtitle="Product Category"
          toolparamdescription="Filter results to a specific product category. Use 'all' for no filter.">
    <option value="all">All categories</option>
    <option value="electronics">Electronics</option>
    <option value="books">Books</option>
    <option value="clothing">Clothing</option>
  </select>

  <button type="submit">Search</button>
</form>Offerto da

Quello che fa il browser con questi attributi è generare internamente uno schema JSON. Il nome dello strumento, i tipi dei parametri, i valori enum dalle opzioni del <select> e i marker required dall’HTML vengono mantenuti senza ulteriore configurazione.

Per testarlo, crea un semplice file .html sul tuo computer con qualsiasi editor di testo, incolla il codice qui sopra e aprilo in Chrome usando file:///{your_document_path.html}; per far funzionare l’estensione con il file locale, devi anche aprire le impostazioni dell’estensione, andare su Dettagli e abilitare l’accesso agli URL file, come mostrato nello screenshot qui sotto.

Consentire all’estensione di accedere ai file locali.

Altrimenti, il browser non riuscirà a interagire con il tuo file HTML locale. Fatto questo, se apri il file con Chrome e controlli l’estensione WebMCP, dovresti vedere qualcosa di simile allo screenshot seguente. 

L’estensione che mostra lo schema generato per lo strumento search_products dopo l’aggiunta delle annotazioni.

Cosa succede effettivamente quando un agente chiama questo strumento? 

Chrome mette a fuoco il form, compila i campi con i valori forniti dall’agente e si ferma lì. L’utente deve comunque cliccare Invia. Questo comportamento predefinito è voluto, perché l’umano dovrebbe confermare l’azione prima che venga eseguita.

Aggiungere l’attributo toolautosubmit al tag form rimuove quel passaggio di conferma. Ha senso per operazioni in sola lettura come le ricerche. Per qualsiasi cosa modifichi dati, attivi un acquisto o cambi impostazioni dell’account, lascialo disattivato.

Esiste anche un modo per intercettare l’invio e restituire un risultato strutturato all’agente. Il metodo respondWith() sull’evento di submit accetta una promise, e qualunque valore tu risolva diventa l’output dello strumento:

<form toolname="search_products"
      tooldescription="Search the product catalog"
      toolautosubmit
      action="/search">
  <input type="text" name="query" required>
  <button type="submit">Search</button>
</form>

<script>
  document.querySelector("form").addEventListener("submit", (e) => {
    e.preventDefault();

    const query = new FormData(e.target).get("query");

    if (!query || query.trim().length === 0) {
      if (e.agentInvoked) {
        e.respondWith(Promise.resolve({
          error: "Search query cannot be empty. Please provide a keyword."
        }));
      }
      return;
    }

    const results = performSearch(query);

    if (e.agentInvoked) {
      e.respondWith(Promise.resolve({
        content: [{ type: "text", text: JSON.stringify(results) }]
      }));
    }
  });
</script>Offerto da

Quel boolean agentInvoked sull’evento di submit è true quando la sottomissione è stata attivata da un agente e false per un clic umano normale. Puoi usarlo per biforcare tra una formattazione di risposta specifica per l’agente e la tua gestione standard del form.

Quando non è presente un toolparamdescription su un campo, il browser prende la descrizione dall’elemento <label> associato, o in mancanza da aria-description. Quindi il markup accessibile fornisce già descrizioni dei parametri ragionevoli senza lavoro extra.

Una particolarità attuale: per un gruppo di elementi <input type="radio">, toolparamdescription deve andare sul primo pulsante radio del gruppo e si applica all’intero parametro.

L’approccio imperativo (JavaScript)

I form coprono molti casi, ma alcuni strumenti devono lavorare con lo stato dell’applicazione, effettuare chiamate API o restituire risultati calcolati che non corrispondono a un invio tradizionale di form. Ecco uno strumento di base che aggiunge elementi a una to-do list:

window.navigator.modelContext.registerTool({
  name: "addTodo",
  description: "Add a new item to the user's to-do list. Use when the user asks to create, add, or remember a task.",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "The task description"
      },
      priority: {
        type: "string",
        enum: ["low", "medium", "high"],
        description: "Task priority level. Default to 'medium' if not specified by the user."
      }
    },
    required: ["text"]
  },
  execute: ({ text, priority = "medium" }) => {
    const newItem = { id: Date.now(), text, priority, done: false };
    todoApp.addItem(newItem);
    todoApp.renderList();

    return {
      content: [{
        type: "text",
        text: Added task: "${text}" with ${priority} priority. The to-do list now has ${todoApp.getCount()} items.
      }]
    };
  }
});Offerto da

La callback execute riceve i parametri inviati dall’agente (che dovrebbero rispettare l’inputSchema), esegue la logica della tua applicazione e restituisce un array content. 

Un dettaglio che conta: aggiorna la UI prima di restituire. 

Gli agenti a volte controllano come appare la pagina dopo una chiamata allo strumento per verificare che abbia funzionato, quindi se la UI non è ancora cambiata, l’agente potrebbe supporre che la chiamata sia fallita. Puoi registrare e deregistrare strumenti man mano che lo stato della pagina evolve:

function onUserLogin(user) {
  navigator.modelContext.registerTool({
    name: "viewOrderHistory",
    description: "Show the user's past orders with dates and totals",
    inputSchema: {
      type: "object",
      properties: {
        limit: {
          type: "number",
          description: "Maximum number of orders to return. Defaults to 10."
        }
      }
    },
    execute: async ({ limit = 10 }) => {
      const orders = await fetchOrders(user.id, limit);
      return {
        content: [{ type: "text", text: JSON.stringify(orders) }]
      };
    }
  });
}

function onUserLogout() {
  navigator.modelContext.unregisterTool("viewOrderHistory");
}Offerto da

Uno scenario più realistico: una pagina di prenotazione ristorante che verifica la disponibilità dei tavoli. Questo esempio mostra anche la validazione nel codice, raccomandata dalla documentazione di Chrome perché i vincoli di schema aiutano gli agenti ma non sono applicati da tutti allo stesso modo.

navigator.modelContext.registerTool({
  name: "checkAvailability",
  description: "Check table availability for a given date and party size at this restaurant. Returns available time slots.",
  inputSchema: {
    type: "object",
    properties: {
      date: {
        type: "string",
        description: "The desired reservation date in YYYY-MM-DD format"
      },
      partySize: {
        type: "number",
        description: "Number of guests, between 1 and 12"
      }
    },
    required: ["date", "partySize"]
  },
  execute: async ({ date, partySize }) => {
    if (partySize < 1 || partySize > 12) {
      return {
        content: [{
          type: "text",
          text: "Party size must be between 1 and 12. For larger groups, please call the restaurant directly at (555) 123-4567."
        }]
      };
    }

    const parsedDate = new Date(date);
    if (isNaN(parsedDate.getTime()) || parsedDate < new Date()) {
      return {
        content: [{
          type: "text",
          text: "Please provide a valid future date in YYYY-MM-DD format."
        }]
      };
    }

    const slots = await api.getAvailableSlots(date, partySize);
    renderAvailabilityCalendar(date, slots);

    return {
      content: [{
        type: "text",
        text: JSON.stringify({
          date,
          partySize,
          availableSlots: slots.map(s => s.time),
          message: slots.length > 0
            ? Found ${slots.length} available time slots.
            : "No availability for this date. Try a different date or smaller party."
        })
      }]
    };
  }
});Offerto da

Vale la pena sottolineare alcuni punti dalla documentazione di Chrome. Accetta l’input grezzo dell’utente quando possibile. Se qualcuno dice "11:00 to 15:00", il tuo strumento dovrebbe accettare direttamente quelle stringhe invece di richiedere che l’agente le converta in minuti da mezzanotte o in qualche altro formato interno. 

Valida nel codice, non solo nello schema, perché l’applicazione dello schema varia tra gli agenti. E restituisci solo dopo che la UI è stata aggiornata, dato che gli agenti possono guardare la pagina per confermare che l’operazione sia andata a buon fine.

Per strumenti MCP lato server che possano completare un’implementazione WebMCP lato client, la nostra guida su come costruire server MCP con FastMCP copre nel dettaglio la configurazione.

Gestione dell’invocazione degli agenti e sicurezza in WebMCP

La specifica WebMCP presume che ci sia un umano che osserva. Gli autori di Google e Microsoft l’hanno progettata intorno a workflow cooperativi, non all’operatività autonoma. I meccanismi seguenti riflettono questa filosofia.

Rilevare utenti AI rispetto a utenti umani

Una nuova proprietà booleana chiamata agentInvoked appare sull’interfaccia SubmitEvent. Quando un agente attiva l’invio di un form, la proprietà è true. Quando una persona clicca normalmente su Invia, è false.

document.querySelector("form").addEventListener("submit", (e) => {
  if (e.agentInvoked) {
    console.log("AI agent submitted the form");
    if (!isWithinAgentRateLimit()) {
      e.preventDefault();
      e.respondWith(Promise.resolve({
        error: "Too many requests. Please wait before trying again."
      }));
      return;
    }
  }
});Offerto da

Oltre agli invii di form, ci sono due eventi a livello finestra che tracciano l’attività dell’agente. toolactivated si attiva dopo che un agente invoca uno strumento, e Chrome precompila i campi del form associato. toolcancel si attiva se l’utente annulla l’operazione o reimposta il form. 

Nessuno dei due eventi è annullabile, ma entrambi portano una proprietà toolName così sai quale strumento è stato coinvolto.

window.addEventListener("toolactivated", ({ toolName }) => {
  showAgentActivityBanner(toolName);
});

window.addEventListener("toolcancel", ({ toolName }) => {
  hideAgentActivityBanner();
});Offerto da

Applicare permessi con l’umano nel loop

Con gli strumenti dichiarativi, il comportamento predefinito è che l’umano debba cliccare Invia dopo che l’agente ha compilato i campi. Questo default dovrebbe rimanere per qualsiasi azione con conseguenze reali.

L’attributo toolautosubmit rimuove quel passaggio. Va usato su strumenti in sola lettura o a basso rischio: query di ricerca, controlli di disponibilità, verifiche di stato. 

Qualunque cosa crei, modifichi o elimini dati dovrebbe richiedere un clic manuale.

Puoi stilizzare lo stato di interazione dell’agente con pseudo-classi CSS:

form:tool-form-active {
  border: 2px solid #2563eb;
  background-color: #eff6ff;
  font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">1rem;
  border-radius: 8px;
}

form:tool-form-active::before {
  content: "AI agent is filling this form";
  display: block;
  font-size: 0.875rem;
  color: #2563eb;
  font-weight: 600;
  font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">0.5rem;
}Offerto da

Un form con lo stile :tool-form-active applicato, che mostra il bordo blu e la dicitura "AI agent is filling this form".

Gli strumenti imperativi pongono una sfida diversa. Non c’è un form e nessun pulsante Invia, quindi l’esecuzione parte immediatamente quando l’agente chiama lo strumento. 

Per qualsiasi operazione che non dovrebbe avvenire senza approvazione umana, devi integrare la conferma nello strumento stesso:

navigator.modelContext.registerTool({
  name: "deleteAccount",
  description: "Permanently delete the user's account and all associated data. Cannot be undone.",
  inputSchema: {
    type: "object",
    properties: {
      confirmPhrase: {
        type: "string",
        description: "The user must type 'DELETE MY ACCOUNT' to confirm."
      }
    },
    required: ["confirmPhrase"]
  },
  execute: ({ confirmPhrase }) => {
    if (confirmPhrase !== "DELETE MY ACCOUNT") {
      return {
        content: [{
          type: "text",
          text: "Confirmation phrase does not match. Ask the user to confirm explicitly."
        }]
      };
    }

    return new Promise((resolve) => {
      showConfirmationModal("Are you sure?", {
        onConfirm: async () => {
          await api.deleteAccount();
          resolve({ content: [{ type: "text", text: "Account deleted." }] });
        },
        onCancel: () => {
          resolve({ content: [{ type: "text", text: "Deletion cancelled by user." }] });
        }
      });
    });
  }
});Offerto da

Il pattern nell’ecosistema MCP è coerente: l’agente esprime l’intenzione, l’umano conferma l’esecuzione. Per una visione più ampia di come funzioni nelle diverse implementazioni MCP, vedi la nostra panoramica dei migliori server e client MCP.

Testare la tua implementazione WebMCP

Una volta che hai la tua prima integrazione WebMCP in esecuzione, è il momento di testarla. 

Uso del simulatore di agenti in Chrome DevTools

Dopo aver installato l’estensione Model Context Tool Inspector, un piccolo badge sulla sua icona ti dice quanti strumenti sono stati registrati dalla pagina corrente. Aprendo il pop-up vedi ogni strumento con nome, descrizione e schema di input. Se uno strumento che hai registrato non appare qui, la registrazione non ha funzionato correttamente.

Il pannello dell’estensione che mostra un elenco di più strumenti registrati con i relativi schemi espansi.

Per provare il simulatore di agenti, torniamo al sito demo Flight Search di Google. Ora possiamo testare come eseguire questa app manualmente o usando il linguaggio naturale. 

Approccio di esecuzione manuale

L’esecuzione manuale rimuove l’elemento non deterministico dal testing degli agenti. Seleziona uno strumento dal menu a tendina nel pannello dell’estensione, digita un oggetto JSON nel campo "Input Arguments" e clicca "Execute Tool". L’estensione chiama direttamente lo strumento usando i parametri che hai fornito.

L’estensione con lo strumento searchFlights selezionato, parametri JSON compilati e il pulsante Execute Tool visibile.

Questo è utile per isolare i problemi. Quando uno strumento funziona correttamente con parametri scritti a mano ma fallisce quando lo chiama l’agente, sai che il problema è nella descrizione o nello schema dello strumento, non nella funzione execute. Per esempio, usando la demo di viaggi di Google:

{
  "origin": "LON",
  "destination": "NYC",
  "tripType": "round-trip",
  "outboundDate": "2026-06-10",
  "inboundDate": "2026-06-17",
  "passengers": 2
}Offerto da

La pagina della demo di viaggi che mostra i risultati della ricerca dopo l’esecuzione manuale dello strumento.

Test con linguaggio naturale

Il test con linguaggio naturale usa la Gemini API. Incolla una chiave da AI Studio nelle impostazioni dell’estensione, quindi digita un prompt come 

Search for round-trip flights from London to New York leaving June 10th, returning June 17th, for 2 passengers.Offerto da

L’estensione invia quel prompt a Gemini 2.5 Flash insieme alle tue definizioni di strumenti, e il modello decide quale strumento invocare e quali parametri passare.

Il campo di input in linguaggio naturale dell’estensione con un prompt digitato e la risposta dell’agente sull’invocazione dello strumento.

Se l’agente sceglie lo strumento sbagliato o mappa i parametri in modo scorretto, probabilmente le descrizioni dei tuoi strumenti devono essere più specifiche. Descrizioni efficaci spiegano positivamente cosa fa lo strumento ("usa questo per verificare la disponibilità dei voli"), non per cosa non andrebbe usato.

Una sequenza di test pratica:

1. Verifica che gli strumenti compaiano nell’estensione dopo il caricamento della pagina.
2. Esegui ogni strumento manualmente con i parametri corretti. Conferma che la logica di execute funzioni e che la UI si aggiorni come previsto.
3. Esegui con parametri errati. Verifica che la tua validazione intercetti gli errori e che i messaggi siano abbastanza chiari da permettere all’agente di autocorreggersi.
4. Testa con linguaggio naturale. Vedi se l’agente sceglie lo strumento giusto e mappa correttamente le parole dell’utente ai parametri dello schema.
5. Prova i casi limite: utenti non autenticati, form disabilitati, downtime delle API e chiamate ripetute rapide.

Per contesto sugli strumenti MCP nell’ecosistema Google in particolare, il nostro tutorial su Google MCP Servers copre diversi pattern rilevanti. E per una visione più ampia del panorama dei protocolli oltre Chrome, vedi Top Remote MCP Servers.

Conclusione

WebMCP offre ai siti web un canale di comunicazione diretto con gli agenti AI. Invece di far indovinare agli agenti come muoversi in una pagina, il sito pubblica definizioni di strumenti strutturate e l’agente le chiama con parametri tipizzati. L’API dichiarativa trasforma i form esistenti in strumenti richiamabili dagli agenti con poche attributi HTML. L’API imperativa copre tutto il resto più complesso. Il modello di sicurezza mantiene l’umano al controllo delle azioni importanti.

La specifica è ancora agli inizi, disponibile solo in Chrome Canary dietro un flag, e non adatta all’uso in produzione. Ma il fatto che Google e Microsoft la stiano redigendo insieme, con la governance del W3C, suggerisce un reale percorso verso uno standard web stabile. Investire tempo nell’API ora significa che capirai già i pattern di progettazione degli strumenti e i meccanismi di sicurezza quando arriverà la release stabile.

Se vuoi iniziare a prepararti, esamina i form sui tuoi siti esistenti e identifica quelli che beneficerebbero maggiormente dell’accesso degli agenti. I form di ricerca e i checker di disponibilità sono punti di partenza a basso rischio. Quando ti sentirai a tuo agio con l’API dichiarativa su questi, passa agli strumenti imperativi per i workflow che richiedono logica personalizzata. 

Per continuare a esplorare l’argomento, ti consiglio:

• Tutorial sul Model Context Protocol (MCP) per i concetti fondamentali alla base di WebMCP.
• Costruire server MCP con FastMCP per strumenti MCP lato server che completano WebMCP lato client.
• Tutorial su Google MCP Servers per pattern di integrazione specifici di Google.
• Top Remote MCP Servers e Migliori server e client MCP per l’ecosistema più ampio.