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.
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. È esattamente il motivo per cui l’ho costruito su misura.
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 invece 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.
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 Milano”) 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: sul catalogo di un cliente non voglio scoprire un errore a valle di un reindex.
Cosa ci automatizzo davvero
Tolta la teoria, ecco l’uso reale — su casi anonimi, 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 un cliente segnala 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 un decimo del tempo e con la spiegazione già scritta.
Le lezioni imparate
Tre cose me le porto dietro.
Uno: 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.
Due: il context è 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.
Tre: i freni vanno progettati prima, non dopo. Il gate sulle azioni irreversibili l’ho messo dal primo giorno. Se lo aggiungi dopo, 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 costruisci tu.
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. Nel mio MCP ogni azione irreversibile passa da un gate di conferma esplicita, con un utente dedicato e permessi ritagliati per risorsa. 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 un consulente Adobe 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.