Un agente del browser vede un pulsante e ne stima la posizione. Può funzionare. Ma un'applicazione web può anche comunicarne il significato in modo più esplicito: questa azione cerca appuntamenti disponibili, si aspetta una data e restituisce un elenco. È proprio questo passaggio dalla posizione del clic allo strumento descritto a rendere interessante WebMCP.
Secondo lo stato documentato, WebMCP è una proposta sperimentale. L'attuale explainer tratta la registrazione imperativa tramite JavaScript e document.modelContext. Gli strumenti dichiarativi basati su moduli HTML vengono esplorati separatamente e al momento non fanno parte di questa specifica. La pagina panoramica di Chrome datata 18 maggio 2026 non è quindi un motivo per annunciare a ottobre una nuova funzione universale del browser.
Uno strumento inizia con un'azione limitata
Il nostro esempio si chiama «trova appuntamenti disponibili». Il suo compito termina con un'informazione. Non crea una prenotazione. Già la descrizione stessa dovrebbe chiarirlo, affinché un agente non trasformi un risultato di ricerca in un appuntamento confermato.
L'input contiene una data e un servizio offerto. Il risultato indica lo stesso riferimento insieme alle fasce orarie disponibili. Un valore isolato come «10:30» sarebbe più debole: potrebbe appartenere a un altro giorno o a un altro servizio. Un risultato strutturato è particolarmente utile quando le sue voci possono essere interpretate in modo univoco.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Questo è il nostro schema didattico, non una registrazione WebMCP pronta da copiare. La data futura e il servizio sono inventati. Mostra il contratto che un'implementazione reale dovrebbe specificare. Per la sintassi concreta dell'API fa fede l'attuale documentazione sperimentale.
Anche gli errori hanno bisogno di un significato comprensibile
Una data non valida, nessun appuntamento disponibile e un servizio non raggiungibile per motivi tecnici sono tre risultati diversi. Se tutti producessero semplicemente un elenco vuoto, l'agente dovrebbe indovinarne la causa. La risposta dello strumento dovrebbe quindi contenere uno stato comprensibile e le informazioni necessarie per la decisione successiva.
Lo stesso vale per le informazioni parziali. La ricerca è completa o mancano ancora dei dati? La risposta si riferisce alla richiesta più recente? Nel frattempo la persona ha cambiato la data? Domande di questo tipo esistono indipendentemente dal fatto che l'interfaccia venga utilizzata tramite uno screenshot o tramite uno strumento.
Una descrizione non è un'autorizzazione
Uno schema di input corretto dice quale forma dovrebbe avere una richiesta. Non decide se chi chiama è autorizzato a leggere queste informazioni. L'applicazione deve comunque far rispettare le proprie regole. Un nome di strumento dal suono gradevole non è né un accesso né un controllo degli accessi.
Anche il passaggio alla prenotazione ha bisogno di un significato proprio. «Cerca orari disponibili» e «prenota questo orario per me» hanno conseguenze diverse. Non dovrebbero fondersi silenziosamente in un'unica funzione. Una prenotazione reale dovrebbe tenere conto dell'elemento confermato e dell'istruzione intesa.
Per un primo esercizio di progettazione innocuo bastano quindi dati di esempio fissi. Descrivi tre stati di risposta e stabilisci quale azione successiva sarebbe ragionevole in ciascun caso. Così puoi verificare quanto sia comprensibile il contratto senza simulare una prenotazione reale o un runtime WebMCP esistente.
WebMCP non è automaticamente un server MCP remoto esistente
La parola MCP compare in vari contesti tecnici. Un'azione descritta lato browser non è, solo per questo, lo stesso tipo di connessione di un server di strumenti remoto raggiungibile tramite HTTP. Per una connessione specifica contano il client, il trasporto, l'accesso e gli strumenti effettivamente offerti.
Un accesso MCP remoto esistente non dimostra quindi che un sito web supporti WebMCP. Allo stesso modo, una proposta sperimentale per i browser non garantisce che ogni agente possa già utilizzarla. Questa distinzione è pratica: evita che un nome simile porti a un piano di integrazione sbagliato.
La domanda trasferibile resta chiara. Un'applicazione è in grado di esprimere quale azione, con quali input, ha quale risultato e quale effetto? Più precisa è questa risposta, meno un agente deve indovinare a partire da una posizione sullo schermo. Buoni contratti per gli strumenti rendono più comprensibile il margine di manovra; le regole dell'applicazione restano comunque sotto la sua responsabilità.
Fonti e stato
Ricerca e documentazione aggiornate al 25 ottobre 2026. WebMCP · Explainer di WebMCP.
