Un paio di mesi fa ho collegato Claude a un’installazione Adobe Commerce. Non con un plugin comprato, non con uno di quei connettori generici che promettono di “parlare con qualsiasi API”: l’ho scritto io, un MCP server dedicato. In questo articolo racconto perché l’ho fatto, come l’ho impostato e cosa ci automatizzo davvero. Niente slide, niente demo patinate: solo quello che ho imparato tenendo le mani nel codice, errori compresi.
Perché i connettori generici non mi bastavano
Il Model Context Protocol, da quando è diventato lo standard di fatto per far dialogare gli assistenti con i sistemi esterni, ha generato una piccola industria di connettori universali. Ne ho provati diversi. Il problema è sempre lo stesso: un connettore REST generico ti dà accesso all’endpoint, non al dominio. Tradotto: l’assistente vede una chiamata HTTP, non capisce cosa sia uno SKU, cosa significhi “prodotto non visibile in vetrina”, perché un prezzo speciale possa non applicarsi per via di una regola di catalogo.
Su Adobe Commerce questo divario è ampio. L’API è potente ma verbosa: per capire perché un prodotto non compare a catalogo puoi dover incrociare stato, website assignment, stock, categoria e regole di prezzo. Un connettore generico costringe l’assistente a fare cinque chiamate a tentativi e a interpretare payload enormi, bruciando context e sbagliando. La mia opinione, netta: per un sistema complesso come Adobe Commerce, un MCP server generico è un giocattolo; serve uno strato che parli il linguaggio del dominio. E quello strato lo scrive chi il dominio lo conosce, non chi conosce solo l’AI.
Come l’ho impostato: i tool, non gli endpoint
La decisione progettuale più importante è stata questa: non ho esposto l’API di Adobe Commerce, ho esposto intenzioni. Ogni tool dell’MCP corrisponde a una domanda o a un’azione che ha senso nel lavoro quotidiano, non a una rotta HTTP. Sotto il cofano poi decido io se conviene REST o GraphQL.
La suddivisione che ho adottato, per area:
- Catalogo: ricerca prodotto per SKU o nome, dettaglio con stato, visibilità, categorie e website. Qui GraphQL è quasi sempre la scelta giusta: chiedo esattamente i campi che servono e riduco il payload a una frazione di quello che restituirebbe la REST.
- Ordini: lookup per increment ID, stato, storico, righe. Sola lettura, con paginazione forzata perché un merchant con volumi seri ha storici che non stanno in un context.
- Stock: quantità e stato per SKU, con il supporto al multi-source inventory (MSI) dove è attivo. È un dettaglio che i connettori generici ignorano e che cambia tutto quando ci sono più magazzini.
- Prezzi: prezzo base, special price, e soprattutto la spiegazione di quale catalog price rule sta agendo. È il tool che uso di più, perché “perché questo prodotto costa così?” è la domanda ricorrente.
Ogni tool restituisce un output già ripulito e normalizzato. Non giro all’assistente il JSON grezzo di Adobe Commerce: lo riduco ai campi che contano, con nomi leggibili. Questo è il vero lavoro di un MCP fatto bene, ed è invisibile in una demo ma decisivo in produzione: la qualità di un MCP server si misura da quanto poco context spreca, non da quanti endpoint copre.
Auth: la parte noiosa che non puoi sbagliare
Per l’autenticazione uso le integration token di Adobe Commerce, con un utente dedicato all’integrazione e permessi ritagliati per risorsa. Niente credenziali admin buttate in un file di config. L’MCP server gira in un ambiente controllato, i token stanno in variabili d’ambiente o in un secret manager, e l’account ha in ACL solo le risorse dei tool che ho esposto. Se un tool legge solo ordini, l’utente non ha diritti di scrittura sul catalogo, punto. È banale scriverlo, è meno banale resistere alla tentazione di dare accesso pieno “per comodità” durante lo sviluppo. Io ho ceduto, all’inizio, e ho dovuto tornare indietro.
Il gate sulle azioni irreversibili
Qui viene la parte su cui ho ragionato di più. Un assistente che può leggere è un assistente utile. Un assistente che può scrivere su un e-commerce di produzione è un rischio, se lo lasci senza freni. La mia regola: ogni azione irreversibile o che tocca dati di produzione passa da un gate di conferma esplicita.
In pratica ho separato i tool in due categorie. I tool di lettura girano liberi. I tool che scrivono, aggiornare uno stato prodotto, modificare uno stock, forzare un prezzo, non eseguono mai al primo colpo: restituiscono un piano (“sto per portare la quantità di SKU X da 12 a 0 sul source di quel magazzino”) e attendono una conferma prima di committare. In alcuni casi il write non lo faccio proprio passare dall’assistente: preferisco che produca il comando esatto e che sia una persona a lanciarlo. È una scelta conservativa e me la tengo.
Un’annotazione, perché su questo tema si sente molta ideologia. Il gate non serve a esorcizzare l’AI: serve a misurare cosa fa. Log di ogni chiamata, piano prima dell’esecuzione, diff. Meno paranoia teorica, più tracce concrete.
Cosa ci automatizzo davvero
Tolta la teoria, ecco l’uso reale, su casi anonimizzati, perché i dettagli dei clienti restano fuori da qui.
Il grosso è diagnosi in lettura. “Perché questo prodotto non si vede in vetrina?” è diventata una domanda che risolvo in secondi: l’assistente interroga stato, visibilità, website e stock in un colpo e mi dice dov’è il buco. Prima erano cinque schede aperte nell’admin. Stesso discorso per “perché questa promo non si applica”: il tool sui prezzi mi tira fuori la regola che agisce, o l’assenza di regola, senza che io debba spulciare a mano.
Poi c’è il controllo incrociato ordine-stock-prezzo quando arriva la segnalazione di un’anomalia: verifico l’ordine, controllo lo stato dello stock sul source giusto e confermo il prezzo applicato al momento dell’acquisto. Tre domande, tre tool, una risposta coerente. Le scritture, dove le uso, sono limitate a interventi semplici e sempre col gate: un aggiornamento di stock, un cambio di stato su un prodotto. Nulla che non potrei fare a mano, ma fatto in una frazione del tempo e con la spiegazione già scritta.
Il punto che mi interessa marcare è questo: l’agente non fa niente che io non sappia già fare. Fa in un decimo del tempo quello che facevo prima, perché sono io a dirgli dove guardare. Se non sapessi perché un prodotto sparisce da una category, non saprei nemmeno riconoscere quando la sua diagnosi è sbagliata. Ed è il motivo per cui questa roba non funziona allo stesso modo per chiunque.
Quello che ho imparato sbagliando
Modella i tool sul lavoro, non sull’API. Il valore non è nell’esporre Adobe Commerce, è nel tradurre l’API in azioni che hanno senso per chi le usa. Ogni volta che ho ceduto e aggiunto un tool generico l’ho poi tolto.
Il context, poi, è la risorsa scarsa. Un payload di Adobe Commerce non filtrato riempie la finestra e degrada le risposte. Normalizzare l’output non è un vezzo, è la differenza tra un assistente che ci prende e uno che allucina.
E i freni vanno progettati prima, non dopo. Il gate sulle azioni irreversibili l’ho messo dal primo giorno. Se lo aggiungi quando l’assistente scrive già in produzione, è troppo tardi.
Non è un progetto finito e non lo vendo. È uno strumento che uso, che sbaglia ancora in casi limite e che miglioro quando serve. Ma il principio è solido: quando il sistema è complesso, il connettore giusto lo costruisce chi quel sistema lo conosce.
Mini-FAQ
Cos’è un MCP server per Adobe Commerce?
È uno strato software che espone le funzioni di Adobe Commerce (catalogo, ordini, stock, prezzi) a un assistente AI tramite il Model Context Protocol, sotto forma di tool orientati al dominio anziché di semplici chiamate API.
Perché costruirlo su misura invece di usare un connettore generico?
Perché un connettore generico espone endpoint HTTP, non concetti di e-commerce. Su un sistema complesso come Adobe Commerce serve uno strato che normalizzi gli output e riduca il context, altrimenti l’assistente sbaglia e spreca risorse.
È sicuro far scrivere un assistente AI su un e-commerce di produzione?
Solo con dei freni, e soprattutto con delle tracce. Nel mio MCP ogni azione irreversibile passa da un gate di conferma esplicita, con un utente dedicato, permessi ritagliati per risorsa e log di ogni chiamata. Le letture sono libere, le scritture no.
REST o GraphQL?
Dipende dal tool. Per la lettura di catalogo uso GraphQL per chiedere solo i campi necessari e ridurre il payload; per altre operazioni la REST resta più diretta. La scelta la fa il tool, non l’utente.
Chi sono. Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco integrazioni AI agentiche basate su MCP per il mondo Adobe, e scrivo di quello che imparo mentre le realizzo.