Il Model Context Protocol ha appena due mesi. Anthropic lo ha presentato a fine novembre 2024 e, come capita con quasi tutto ciò che esce dal mondo AI, la prima reazione tipica è stata l’alzata di sopracciglio: l’ennesimo standard che nessuno userà. Io la penso diversamente, e in queste settimane ho deciso di metterci del tempo vero, la sera, sul codice, non sulle slide. Voglio spiegare perché, senza vendervi nulla e senza fingere che sia già tutto risolto: al momento ho qualche prototipo che gira e un discreto numero di dubbi.
Cos’è MCP, in una riga onesta
MCP è un protocollo aperto che standardizza il modo in cui un assistente AI si collega a dati e strumenti esterni. L’immagine che uso più spesso quando ne parlo con i colleghi è quella della porta USB-C: prima ogni integrazione tra un modello e un sistema (un ERP, un CMS, un database di prodotti) era un cavo su misura, costruito per quella coppia specifica. MCP prova a essere il connettore unico. Da un lato c’è il modello, dall’altro c’è un server MCP che espone verso l’esterno le funzioni di un sistema: leggi questi ordini, cerca questi prodotti, aggiorna questa pagina.
Il punto che mi ha convinto non è tecnologico, è economico. Fino a ieri, se scrivevo un’integrazione tra un modello e il gestionale di un merchant, quel lavoro era legato a doppio filo a quel modello e a quel progetto. Con MCP scrivo un server una volta e lo riutilizzo con assistenti e agenti diversi, senza riscrivere la logica di accesso ai dati. È la differenza tra costruire una strada e costruire un’auto che va bene solo su quella strada.
Perché lo chiamo un investimento riutilizzabile
Nel mio lavoro di consulenza su Adobe Commerce e sull’ecosistema Adobe, il collo di bottiglia non è quasi mai il modello. I modelli sono già bravi abbastanza. Il collo di bottiglia è l’accesso ai dati del merchant: catalogo, ordini, giacenze, contenuti, logiche promozionali. Sono informazioni sparse tra Adobe Commerce, un ERP, magari un PIM, un sistema di customer care. Ogni volta che qualcuno vuole “provare l’AI” su un e-commerce, la gran parte dell’effort finisce lì, nel tubo che porta i dati al modello, e quasi nessuno lo mette a preventivo.
MCP mi permette di trattare quel tubo come un asset. Se costruisco un server MCP che espone in modo pulito le entità di un catalogo Adobe Commerce, quel componente non muore con il singolo esperimento. Lo ricollego al progetto successivo, a un altro assistente, a un agente che ancora non esiste. Un connettore MCP scritto bene sopravvive al modello per cui è nato. Questa, per me, è la definizione di investimento: qualcosa che continua a rendere anche dopo che l’hype iniziale si è spento.
C’è poi una ragione che va oltre il risparmio, ed è quella che mi interessa di più. Con un accesso strutturato ai sistemi posso provare un’idea senza aprire un progetto di sviluppo, senza impegnare un team, senza aspettare uno sprint. Il valore si sposta a monte: non su come si fa una cosa, ma su quale cosa vale la pena fare. Detto brutalmente: MCP non rende superflua la competenza, la rende decisiva. Chi ha in testa il modello dati di un e-commerce e sa quali domande valga la pena porre, con questi strumenti va dieci volte più veloce di prima. Chi non ce l’ha, produce esperimenti eleganti che non servono a nessuno, solo più in fretta.
Cosa sto iniziando a costruire e a immaginare
Sono nella fase in cui si sporca il codice più di quanto si scrivano slide, ed è la fase che preferisco. Nessun toolkit maturo, per carità: prototipi. Sto lavorando su tre direzioni, in ordine di maturità.
- Un server di sola lettura sul catalogo. Espone prodotti, categorie, attributi e prezzi di un’istanza Adobe Commerce a un assistente, così che possa rispondere a domande operative (“quali prodotti di questa categoria sono senza immagine?”) senza che nessuno apra il pannello admin. È il caso più semplice, ed è già utile.
- Un connettore verso i dati di ordini e clienti, con permessi molto più stretti. Qui l’obiettivo non è la conversazione ma l’analisi ripetitiva: anomalie negli ordini, pattern di reso, segmenti che si comportano in modo strano. Questo è ancora molto acerbo.
- L’orchestrazione tra più sistemi. Questa per ora è più immaginazione che codice, e voglio essere onesto su questo. L’idea è che un agente, attraverso più server MCP, colleghi la giacenza dell’ERP, il contenuto del CMS e i dati di comportamento, e proponga azioni. Non ci siamo ancora, ma l’architettura di MCP rende lo scenario pensabile senza integrazioni monolitiche.
In un caso dal campo, con un merchant fashion di taglia media, il problema quotidiano era banale e frustrante: capire ogni mattina quali prodotti nuovi erano andati online senza dati completi. Un prototipo di server MCP in lettura sul catalogo trasforma quella caccia manuale in una domanda in linguaggio naturale. Non è rivoluzione, è attrito che scompare. E l’attrito che scompare, moltiplicato per i giorni dell’anno, è esattamente ciò che i merchant pagano volentieri.
Ma ho anche una cosa da raccontare che non ha funzionato, e mi ha insegnato più del resto. Sul primo tentativo avevo esposto il catalogo così com’era, con tutti gli attributi grezzi, convinto che al modello bastasse “vedere i dati”. Il risultato è stato pessimo: sullo stesso concetto commerciale c’erano tre attributi diversi popolati a metà, e l’assistente rispondeva con sicurezza usando quello sbagliato. Errori plausibili, quindi peggiori di errori evidenti. La lezione è che un server MCP non è un dump: è un modello semantico che qualcuno deve avere il coraggio di decidere. Su un catalogo mal modellato l’AI non mette ordine, amplifica il disordine. E se non hai già in testa la risposta giusta, non ti accorgi che sta sbagliando: il costo nascosto di questa tecnologia si chiama competenza.
I limiti di oggi, detti chiaramente
Sarei disonesto se mi fermassi all’entusiasmo. A due mesi dal lancio, MCP è un ecosistema giovane, e questo si sente.
Il primo limite è la maturità. Lo standard è di Anthropic e per ora l’adozione ruota intorno al suo mondo. Perché diventi davvero lo standard che il nome promette, serve che lo adottino attori diversi, e questo non è ancora scontato. Sto investendo su una scommessa informata, non su una certezza. Se tra un anno l’ecosistema si fosse frammentato in tre protocolli concorrenti, parte di questo lavoro andrebbe rivista. Lo metto in conto, e non è una postura: è la ragione per cui tengo i prototipi piccoli.
Il secondo limite, più serio per chi come me lavora con dati di merchant, è la sicurezza. Un server MCP è, di fatto, una porta aperta verso sistemi che contengono ordini, clienti, prezzi. Il protocollo è giovane e le pratiche di autenticazione, gestione dei permessi e audit sono ancora in assestamento. La tentazione di dare a un agente accesso in scrittura su un gestionale è forte; la disciplina di partire in sola lettura, con permessi minimi e log completi, è ciò che separa un esperimento serio da un incidente che aspetta di accadere. Con i dati di un merchant si parte sempre in lettura. È una regola che mi sono dato e da cui non mi muovo. E aggiungo: meno paranoia teorica, più misurazione. Log di cosa chiede l’agente, cosa riceve, cosa combina. Senza quello si discute di rischi al buio.
C’è poi un limite di ergonomia: costruire e far girare server MCP richiede oggi una manualità che non è ancora alla portata di chi non mette le mani nel codice. Migliorerà, immagino, ma oggi è così.
Perché ci investo lo stesso
Metto insieme le due cose: da un lato un asset riutilizzabile che sopravvive ai modelli, dall’altro un ecosistema acerbo e questioni di sicurezza aperte. La mia scelta è investire adesso proprio perché è presto. Le competenze che si costruiscono quando uno standard è ancora ruvido sono quelle che contano di più quando lo standard matura. Ho vissuto la stessa dinamica anni fa con Magento, quando pochi in Italia ci scommettevano davvero: essere presto sulla curva, con prudenza, è stato il vantaggio più duraturo della mia carriera.
Se devo essere sincero fino in fondo, il motivo per cui ci sono finito dentro non è nemmeno strategico. È curiosità da smanettone: ho iniziato a giocarci, ho visto che reggeva più di quanto mi aspettassi, e a un certo punto ho smesso di considerarlo un gioco. MCP non è ancora lo standard. Ma è il candidato più credibile che io abbia visto per collegare i modelli ai sistemi reali dei merchant, e questo, per il mio lavoro, vale il tempo che ci sto mettendo.
Mini-FAQ
Cos’è il Model Context Protocol (MCP)?
È un protocollo aperto presentato da Anthropic a fine novembre 2024 che standardizza il collegamento tra un assistente AI e sistemi esterni come ERP, CMS o cataloghi e-commerce, tramite componenti chiamati server MCP.
Perché MCP viene definito un investimento riutilizzabile?
Perché un connettore MCP si scrive una volta e si riutilizza con assistenti e agenti diversi, senza riscrivere la logica di accesso ai dati. Il componente sopravvive al singolo modello per cui è stato creato.
Quali sono oggi i limiti principali di MCP?
Due su tutti: l’ecosistema è ancora giovane e l’adozione è concentrata, quindi la sua affermazione come standard non è garantita; e la sicurezza, perché un server MCP espone dati sensibili e le pratiche di autenticazione e permessi sono ancora in assestamento. Aggiungo un terzo, meno tecnico: su un catalogo modellato male un server MCP amplifica il disordine invece di risolverlo.
Come conviene partire con MCP su un e-commerce?
In sola lettura, con permessi minimi e log completi, e solo dopo aver messo un minimo di ordine negli attributi. Un buon primo caso è un server MCP che espone il catalogo per rispondere a domande operative, prima di pensare a scenari con accesso in scrittura.
Chi sono. Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech. Sono certificato su Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target, e da mesi approfondisco l’AI agentica e Claude applicati all’e-commerce. Su questo blog racconto, senza vendere nulla, cosa penso di ciò che si muove nell’ecosistema Adobe Commerce e nell’AI, e cosa significa per chi vende online.