Nel corso degli anni, gestendo store su Adobe Commerce, il gesto che ho ripetuto più spesso non è stato scrivere codice: è stato aprire l’admin, filtrare una griglia, esportare un CSV, incrociarlo con un altro export e cercare la riga che non tornava. Ore di lavoro che non producono nulla di nuovo, solo risposte a domande che avrei potuto fare a voce. Da qualche mese ho iniziato a farle a voce, letteralmente, collegando Claude al mio Adobe Commerce tramite MCP. Voglio raccontarvi come, cosa automatizzo davvero e — soprattutto — dove mi fermo.
Cosa vuol dire, in pratica, collegare Claude ad Adobe Commerce
MCP (Model Context Protocol) è lo standard aperto con cui un modello come Claude dialoga con sistemi esterni. Non è magia: è un server che espone un set di strumenti (tool) e li descrive in modo che l’agente sappia quando e come chiamarli. Nel mio caso il server MCP parla con le REST API di Adobe Commerce, quelle che uso da sempre per le integrazioni. La differenza è chi le chiama: non più uno script che ho scritto per un compito preciso, ma un agente che decide quale endpoint interrogare in base a quello che gli chiedo in linguaggio naturale.
Concretamente: ho un tool search_products, uno get_order, uno get_stock, uno per leggere i prezzi e le regole di catalogo, e un paio in scrittura per preparare aggiornamenti. Ognuno è un guscio sottile sopra le API native: autenticazione OAuth, un integration token con permessi ristretti, e un log di ogni chiamata. Claude non ha accesso al database, non ha una shell, non tocca il filesystem del server. Vede solo i tool che ho deciso di esporgli. Questo è il primo principio: l’agente è potente quanto la superficie che gli concedi, non di più.
Cosa automatizzo davvero
Parto dalle cose noiose, perché sono quelle che rendono di più. Le interrogazioni in lettura sono il 90% del valore quotidiano e non hanno praticamente rischio.
- Ricerca prodotti e diagnosi di visibilità. “Perché questo SKU non compare in categoria?” è la domanda più frequente in assistenza. Prima aprivo prodotto, controllavo status, visibility, website assignment, stock, la categoria, l’eventuale reindex pendente. Ora lo chiedo e Claude interroga in sequenza gli endpoint giusti e mi torna una diagnosi: “prodotto disabled sul website X, stock a zero, non è un problema di categoria”. Dieci secondi invece di dieci minuti.
- Controllo stock, prezzi e regole. Su un catalogo di qualche decina di migliaia di SKU, le anomalie di prezzo si nascondono bene. Chiedo “trovami i prodotti con prezzo speciale scaduto ancora attivo a griglia” oppure “quali SKU hanno special_price maggiore del price?” e ottengo la lista. Sono le stesse query che avrei scritto a mano, ma non devo ricordarmi la struttura esatta della risposta API.
- Lettura ordini. “Dammi lo stato dell’ordine 100034219, i pagamenti e le note.” Oppure, in aggregato, “quanti ordini sono in stato payment_review da più di 48 ore?”. Roba che nell’admin richiede filtri manuali e che qui è una frase.
- Preparazione di aggiornamenti al catalogo. Qui inizia la parte delicata. Claude mi prepara il payload — per esempio l’aggiornamento di un attributo su un set di prodotti — me lo mostra, e io decido. La preparazione è automatica, l’esecuzione no. Ci torno tra un attimo.
Un caso reale, anonimizzato: un merchant fashion sui €15M di GMV mi ha girato la classica segnalazione “la promo 3×2 non si applica al checkout”. In passato avrei perso mezz’ora tra cart price rules, priorità, date, coupon e customer group. Ho chiesto a Claude di leggermi la regola, le condizioni e le azioni, e di dirmi se ci fossero regole con priorità superiore che la escludevano. In due minuti avevo la risposta: c’era una seconda regola, priorità più alta, con discard subsequent rules attivo. Non ha risolto lui — ha fatto il lavoro investigativo che io avrei fatto più lentamente.
I gate: dove l’agente si deve fermare
Questa è la sezione che, se saltate il resto, vi chiedo di leggere. Un agente che sa fare tutto e non chiede mai è un incidente in attesa di accadere. La mia architettura ha tre gate, e non sono negoziabili.
Primo gate: separazione netta tra lettura e scrittura. I tool in lettura girano liberi. I tool in scrittura sono pochi, espliciti, e ognuno richiede una conferma umana prima di eseguire. Claude propone l’azione — “sto per aggiornare status a 2 su questi 340 SKU” — e mostra l’elenco. Nulla parte finché non do l’ok. Le azioni irreversibili o massive (cambi di prezzo, disabilitazioni in bulk, qualsiasi cosa tocchi gli ordini) hanno questa barriera per definizione.
Secondo gate: backup e reversibilità. Prima di ogni scrittura non banale, l’agente salva lo stato precedente dei record che sta per toccare. Se aggiorno un attributo su 340 prodotti, ho da qualche parte i 340 valori vecchi. Non mi fido dell’undo — non esiste un undo su Adobe Commerce — quindi me lo costruisco io. È la stessa disciplina che applico da sempre agli script di data migration, solo che ora è parte del workflow dell’agente.
Terzo gate: permessi minimi lato Commerce. L’integration token che il server MCP usa non è admin. Ha i permessi che servono ai tool esposti e nulla più. Se domani l’agente venisse indotto a fare qualcosa che non deve — prompt injection attraverso il testo di un ordine, per dire — il danno massimo è limitato da quel token, non dalla fantasia del modello. La sicurezza vera non sta nel prompt di sistema, sta nei permessi del sistema sottostante.
Uso ancora l’ambiente di staging per tutto ciò che è nuovo. L’agente lavora prima lì, verifico il comportamento, e solo dopo replico in produzione con le stesse conferme. Chi ha gestito deploy su Commerce sa perché.
Perché serve conoscere sia Adobe Commerce sia gli agenti
Ed eccoci al punto che mi interessa davvero. Vedo due mondi che si guardano da lontano. Da un lato chi conosce Adobe Commerce a fondo ma tratta l’AI come un giocattolo. Dall’altro chi costruisce agenti brillanti ma non ha mai fatto un reindex alle due di notte, non sa cosa succede quando cambi un attribute set su un prodotto configurabile, non ha idea di quanto sia fragile la relazione tra stock, website e source in MSI.
Il valore, secondo me, sta esattamente nell’intersezione. Un agente su Adobe Commerce è utile in proporzione a quanto chi lo progetta conosce dove sono i cadaveri nel data model. So quali endpoint mentono, so che salable_quantity non è qty, so che una regola di catalogo applicata male non dà errore, dà solo prezzi sbagliati in silenzio. Questa conoscenza è ciò che mi permette di decidere quali tool esporre, con quali guardrail, e dove mettere le conferme umane. Un agente generico non lo sa, e chi lo costruisce senza aver vissuto la piattaforma finisce per dargli troppa fiducia sulle cose sbagliate.
Non credo che questo sostituisca il consulente o lo sviluppatore. Credo che sposti dove spendiamo il tempo: meno a estrarre dati, più a decidere cosa farne. La parte investigativa e ripetitiva la fa l’agente; il giudizio resta umano, e per ora è giusto così.
Statement da portare a casa
- MCP collega Claude ad Adobe Commerce chiamando le REST API native tramite un integration token a permessi ristretti; l’agente vede solo i tool esposti, non il database.
- Il 90% del valore quotidiano è in lettura: ricerca prodotti, diagnosi di visibilità, controllo stock e prezzi, lettura ordini.
- Ogni azione di scrittura passa da tre gate: conferma umana, backup dello stato precedente, permessi minimi lato Commerce.
- Il vantaggio competitivo non è l’agente in sé, ma progettarlo conoscendo il data model di Adobe Commerce.
Mini-FAQ
Serve modificare Adobe Commerce per usare Claude via MCP?
No. Il server MCP parla con le REST API esistenti. Non installo moduli invasivi sullo store: serve solo un integration token con i permessi giusti.
L’agente può cambiare prezzi o ordini da solo?
No, per scelta di design. Le azioni in scrittura, in particolare quelle irreversibili o massive, richiedono conferma umana esplicita e un backup dello stato precedente prima di eseguire.
Qual è il rischio principale e come lo limito?
Che l’agente faccia troppo. Lo limito con permessi minimi sul token, separazione tra lettura e scrittura, e test in staging prima della produzione. La sicurezza sta nei permessi del sistema, non nel prompt.
Perché non usare solo l’admin di Adobe Commerce?
L’admin resta la fonte di verità. L’agente serve per le domande trasversali e le diagnosi che nell’admin richiedono molti passaggi manuali: le fai in una frase invece che in dieci filtri.
Chi sono — Fabio Canovi, consulente Adobe presso il gruppo Lutech. Certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Lavoro all’incrocio tra la piattaforma Adobe e l’AI agentica (Claude, MCP, Agent SDK), costruendo strumenti che uso davvero sul campo.