MCP e WebMCP: gli standard che stanno costruendo il web degli agenti AI

Ogni fase di evoluzione del software è stata accompagnata dall’emergere di standard capaci di definire un linguaggio comune tra sistemi diversi. Il web ha avuto HTML, che ha reso possibile la pubblicazione e la fruizione universale dei contenuti; le architetture distribuite hanno avuto le API, che hanno permesso ai servizi di interoperare indipendentemente dalle tecnologie sottostanti; il cloud ha consolidato protocolli e modelli condivisi attraverso cui costruire ecosistemi sempre più modulari, scalabili e componibili.

L’adozione degli agenti AI introduce una nuova esigenza architetturale. Il consumatore di un servizio digitale può essere oggi un sistema software capace di interpretare un obiettivo, pianificare una sequenza di attività ed eseguirla attraverso strumenti, applicazioni e fonti dati distribuite. In questo scenario, la capacità di un servizio di rendere esplicite le proprie funzioni a un agente diventa importante quanto la qualità dell’esperienza progettata per le persone.

È all’interno di questo cambiamento che stanno emergendo Model Context Protocol (MCP) e WebMCP. Entrambi puntano a rendere l’interazione tra agenti e sistemi digitali più strutturata, prevedibile e interoperabile, ma intervengono su livelli differenti dell’architettura. MCP collega le applicazioni AI a strumenti, dati e workflow esterni; WebMCP porta un modello analogo nel browser, permettendo alle applicazioni web di esporre capacità operative direttamente agli agenti.

Il Model Context Protocol affronta uno dei problemi centrali delle architetture agentiche: la frammentazione delle integrazioni tra applicazioni AI e sistemi esterni. Quando ogni applicazione, modello e strumento richiede un connettore sviluppato ad hoc, la complessità cresce rapidamente. Il risultato è un insieme di integrazioni fortemente dipendenti dai singoli vendor, più onerose da manutenere e difficili da governare su scala enterprise.

MCP introduce un’interfaccia standard attraverso cui un’applicazione AI può scoprire e utilizzare le capacità rese disponibili da sistemi esterni. Un server MCP può esporre tools, resources e prompts: i tool rappresentano le azioni invocabili, le resources rendono accessibili dati e contenuti contestuali, mentre i prompt possono fornire template e istruzioni riutilizzabili. L’applicazione host mantiene la relazione con l’utente e con il modello, mentre un client MCP gestisce la comunicazione con uno o più server.

Dal punto di vista architetturale, MCP crea quindi un layer di interoperabilità tra il ragionamento del modello e l’esecuzione nei sistemi aziendali. Le API esistenti continuano a gestire la comunicazione applicativa e la logica dei servizi, mentre il server MCP presenta all’agente una descrizione strutturata delle capacità disponibili, dei parametri richiesti e dei risultati attesi. Questo consente al modello di scegliere uno strumento sulla base dell’obiettivo dell’utente e di invocarlo attraverso un contratto esplicito.

Una configurazione tipica comprende tre componenti principali:

1. MCP host, cioè l’applicazione che ospita l’esperienza agentica, coordina il modello e gestisce il ciclo di interazione con l’utente.
2. MCP client, responsabile della connessione e dello scambio di messaggi con uno specifico server MCP.
3. MCP server, che espone strumenti, risorse o prompt collegandoli a database, repository, API, file system e servizi enterprise.

Questo disaccoppiamento permette di costruire una capacità una volta e renderla disponibile a molteplici applicazioni compatibili, riducendo il numero di integrazioni punto-punto richieste dall’ecosistema. La qualità dell’implementazione dipende comunque da aspetti come la definizione degli schemi, la gestione dell’identità, l’autorizzazione, l’osservabilità, la validazione degli input e il controllo delle azioni eseguibili.

L’interesse verso MCP deriva dalla convergenza di tre esigenze. La prima riguarda la tool discovery, perché un agente deve poter comprendere quali capacità siano disponibili senza conoscere in anticipo ogni implementazione. La seconda riguarda la predictability, perché l’esecuzione di una funzione con input e output strutturati offre un comportamento più controllabile rispetto all’interpretazione libera di un’interfaccia. La terza riguarda la portabilità, perché uno standard condiviso consente agli sviluppatori di separare maggiormente le capacità operative dal singolo modello o prodotto che le utilizza.

In ambito enterprise, questo approccio può diventare particolarmente rilevante quando un agente deve accedere a più sistemi mantenendo policy coerenti. Un server MCP può fungere da confine esplicito tra l’agente e il dominio applicativo, definendo quali operazioni risultano disponibili e attraverso quali contratti. La standardizzazione dell’interfaccia, tuttavia, rappresenta soltanto uno degli elementi necessari: identità, permessi, audit, protezione dei dati, conferme utente e gestione degli errori devono essere progettati come parti integranti dell’architettura.

MCP assume così un ruolo simile a quello svolto da altri standard infrastrutturali: riduce il costo cognitivo e tecnico dell’integrazione, favorisce la composabilità e crea le condizioni per un ecosistema in cui modelli, agenti e strumenti possano evolvere con un grado maggiore di indipendenza reciproca.

WebMCP affronta una sfida differente, collocata nel frontend e nel runtime del browser. Una parte significativa dei processi digitali vive all’interno di applicazioni web in cui identità, stato della sessione e logica d’interazione sono strettamente collegati alla pagina. Per operare su queste applicazioni, molti agenti ricorrono oggi all’analisi del DOM, dell’accessibility tree o della pagina renderizzata, per poi simulare click, compilazione di campi e percorsi di navigazione.

Questo modello richiede all’agente di dedurre il significato operativo dell’interfaccia a partire dalla sua rappresentazione visiva o strutturale. La posizione di un elemento può cambiare, un componente può essere caricato dinamicamente e due controlli simili possono avere finalità diverse. WebMCP propone un’alternativa più esplicita: l’applicazione registra nel browser strumenti descritti attraverso schemi, nomi e funzioni, così che un agente browser-based possa scoprire le capacità disponibili e richiamarle direttamente.

L’esecuzione avviene nel contesto vivo della pagina, dove sono già presenti lo stato dell’interfaccia, la sessione autenticata e il modello di sicurezza del browser. Questa caratteristica rende WebMCP adatto alle operazioni strettamente legate all’esperienza frontend, come interagire con un configuratore, utilizzare una dashboard, compilare un workflow applicativo o agire su dati che esistono nello stato corrente della pagina.

WebMCP porta quindi nel frontend lo stesso principio alla base delle tool-based architectures: l’agente riceve una funzione esplicita da invocare, invece di ricostruire l’intenzione dell’applicazione osservando esclusivamente pulsanti e campi. Il vantaggio architetturale consiste nella possibilità di separare la semantica dell’azione dalla sua rappresentazione visiva, mantenendo al tempo stesso l’esecuzione dentro i confini del browser.

La differenza può essere sintetizzata in termini di posizione della funzionalità. Quando la capacità appartiene al backend, deve essere disponibile su più canali o richiede un’integrazione diretta con sistemi esterni, MCP rappresenta il modello più naturale. Quando la capacità dipende dall’interfaccia aperta, dalla sessione dell’utente o dallo stato corrente della pagina, WebMCP consente di esporla nel luogo in cui viene effettivamente eseguita.

Le due tecnologie possono convivere nella stessa esperienza. Un’applicazione web potrebbe utilizzare WebMCP per dichiarare le azioni disponibili nel frontend e delegare a servizi MCP attività trasversali, elaborazioni backend o accesso a sistemi enterprise. L’architettura risultante distribuisce le responsabilità tra browser e server sulla base del contesto, dei requisiti di sicurezza e della natura dell’operazione.

L’automazione del browser viene spesso realizzata attraverso screenshot, computer vision, selettori CSS, coordinate o analisi dell’accessibility tree. Queste tecniche restano utili nei siti che non espongono capacità strutturate, ma dipendono in larga misura dalla stabilità della presentazione. Un redesign, la modifica di un’etichetta o l’introduzione di un componente dinamico possono alterare il percorso previsto dall’agente.

L’approccio dichiarativo di WebMCP sposta l’interazione dal livello della presentazione a quello dell’intento applicativo. Un sito può esporre, per esempio, una funzione per aggiungere un prodotto al carrello o aggiornare una configurazione, specificando parametri e risultato atteso. Il front-end mantiene il controllo delle capacità disponibili, mentre l’agente opera attraverso contratti leggibili dalla macchina.

Questa evoluzione può ridurre la quantità di inferenza necessaria per completare un’attività e migliorare la robustezza dei workflow agentici. Introduce anche nuove responsabilità per i team di sviluppo: progettare strumenti con una granularità adeguata, fornire descrizioni non ambigue, validare gli input, gestire gli errori e stabilire quali azioni richiedano una conferma esplicita dell’utente.

Per oltre vent’anni il design digitale ha ottimizzato la relazione tra persone e interfacce attraverso i principi della User Experience. L’arrivo degli agenti aggiunge un nuovo livello progettuale, perché un’applicazione deve comunicare correttamente sia con chi utilizza l’interfaccia sia con il sistema software che agisce per conto dell’utente.

Questa prospettiva può essere definita Agent Experience (AX). La qualità dell’esperienza agentica dipende dalla capacità di un sistema di rendere comprensibili le proprie funzioni, offrire feedback strutturati, comunicare limiti e conseguenze delle azioni, preservare il controllo dell’utente e mantenere un comportamento osservabile. Una buona AX nasce quindi dall’incontro tra interaction design, architettura software, sicurezza e AI engineering.

Progettare per gli agenti significa anche valutare quali passaggi possano essere automatizzati, quali richiedano supervisione e quali debbano rimanere sotto il controllo diretto della persona. In un processo di acquisto, per esempio, l’agente potrebbe ricercare opzioni e compilare una configurazione, mentre la conferma finale potrebbe restare esplicitamente associata all’utente. La progettazione dell’esperienza deve rendere visibile questa distribuzione dell’autonomia.

MCP e WebMCP ampliano il significato di composable architecture. In un’architettura composabile tradizionale, dati, servizi e interfacce vengono organizzati come componenti indipendenti e orchestrabili. L’introduzione degli agenti aggiunge un ulteriore livello: ogni componente deve poter descrivere semanticamente che cosa offre, in quale contesto può essere utilizzato e quali vincoli accompagnano la sua esecuzione.

Per le aziende, l’adozione di questi standard richiede una valutazione che coinvolga l’intero ciclo di vita applicativo. Le API e i servizi devono essere mappati in capacità comprensibili dagli agenti; identità e autorizzazioni devono propagarsi in modo coerente; log e tracing devono consentire di ricostruire le decisioni e le azioni; i tool devono essere versionati e testati come qualsiasi altra interfaccia software.

Anche il modello di sicurezza cambia. Un agente può concatenare più strumenti e trasformare una richiesta in una sequenza di operazioni distribuite. La valutazione del rischio deve quindi considerare la singola funzione, le possibili combinazioni tra funzioni e il contesto in cui vengono eseguite. Least privilege, separazione delle responsabilità, allowlist, validazione degli schemi e human-in-the-loop diventano principi architetturali centrali.

La scelta dipende dal punto dell’architettura in cui vive la capacità da esporre. MCP è indicato quando un agente deve collegarsi a database, API, repository, file system o workflow backend, oppure quando la stessa funzione deve essere accessibile da applicazioni diverse. WebMCP è indicato quando l’operazione dipende dalla pagina aperta, dallo stato corrente dell’interfaccia o dalla sessione autenticata nel browser.

Un criterio utile consiste nel chiedersi dove risiedano la source of truth e l’autorità necessaria per completare l’azione. Se dati e logica appartengono a un servizio enterprise, la capacità dovrebbe essere esposta vicino a quel servizio attraverso MCP. Se l’azione esiste specificamente nell’esperienza web e utilizza lo stato del frontend, WebMCP può rappresentare il livello più coerente. Nei sistemi complessi, un’architettura ibrida permette di utilizzare entrambi in modo complementare.

Il web degli agenti sarà costruito attraverso standard capaci di rendere dati, strumenti e interfacce comprensibili alle macchine, mantenendo al tempo stesso governance, sicurezza e controllo umano. MCP sta consolidando un linguaggio comune per collegare applicazioni AI e sistemi esterni; WebMCP porta lo stesso orientamento dichiarativo nel browser e nelle applicazioni web.

La questione strategica per le organizzazioni riguarda quindi la capacità dei propri sistemi di partecipare a questo nuovo ecosistema. Rendere un’applicazione agent-ready significa superare la semplice disponibilità di un’API e progettare capacità semanticamente chiare, governabili, osservabili e utilizzabili in contesti differenti.

MCP e WebMCP rappresentano due componenti di questa infrastruttura emergente. Il primo abilita l’interoperabilità tra agenti e servizi; il secondo rende le esperienze web direttamente interpretabili e utilizzabili dagli agenti browser-based. Insieme delineano un passaggio dall’Internet delle applicazioni a un ambiente digitale in cui persone, software e agenti collaborano attraverso contratti condivisi.