L’8 settembre Adobe Commerce 2.4.9 è andata in produzione, e il modo in cui viene raccontata negli annunci ufficiali è quasi dimesso: una nuova regola di prezzo “free gift” con attivazione e scadenza schedulabili, qualche endpoint REST in più per configurazione ed email. Letta così, sembra una release di manutenzione. Non lo è, se la leggi dal punto di vista di chi sta cercando di far parlare un agente con il backend di Adobe Commerce.
Quello che cambia davvero: il pannello di configurazione diventa un’API
I due dettagli che mi hanno fatto fermare sono gli endpoint REST per leggere e aggiornare i valori di configurazione di sistema, e quelli per aggiornare ed eliminare i template email personalizzati. Fino a ieri, per toccare la configurazione di sistema in modo programmatico servivano o l’accesso diretto al database, o script eseguiti lato server con privilegi ampi: non esattamente il tipo di superficie che vuoi esporre a un agente, per quanto ben progettato sia il gate di conferma che ci metti davanti.
Con 2.4.9, quella configurazione entra nella stessa API REST che già uso per prodotti, ordini e clienti. È un dettaglio tecnico con una conseguenza precisa: un MCP server può, in teoria, offrire un tool “cambia questo parametro di configurazione” con lo stesso livello di controllo (autenticazione, permessi granulari, audit) che già applica agli altri tool, invece di dover bucare l’architettura con una connessione diretta al database ogni volta che serve toccare un’impostazione.
Non l’ho ancora messo alla prova, e lo dico apertamente
Non ho ancora integrato questi endpoint nel mio MCP: quello che segue è un ragionamento su cosa cambierebbe, non il resoconto di un’integrazione fatta. Lo scriverei diversamente, con numeri e casi, se avessi già i tool in produzione.
Il primo tool che costruirei non è “cambia la configurazione”, è il suo contrario: “leggi la configurazione e spiegami cosa fa questo parametro”. Nella mia esperienza, la parte più lenta di una diagnosi su un ambiente Adobe Commerce che non conosco non è trovare il valore di un’impostazione, è capire perché è stato messo a quel valore e cosa succede se lo cambio. Un agente che legge configurazione e la mette in relazione con il comportamento osservato (un metodo di spedizione che sparisce, una regola di prezzo che non si applica) accorcia quella fase molto più di un agente che può solo scriverla.
Sulla scrittura, invece, sarei molto più cauto di quanto suggerisce l’entusiasmo del momento. Un tool che scrive configurazione di sistema tocca cose che un errore di prodotto o di prezzo non tocca: modalità di manutenzione, credenziali di integrazione, impostazioni fiscali. È esattamente il tipo di superficie per cui, scrivendo del blueprint di Anthropic, mi sono convinto che l’approval gate debba vivere a livello di server e non essere un’aggiunta opzionale per i tool “più delicati”: qui sono delicati quasi tutti.
Il contro-argomento: non è una novità così grande
Si potrebbe obiettare che l’accesso via API alla configurazione non è un’invenzione di Adobe: altri CMS e piattaforme e-commerce lo offrono da anni, e non è che il mondo si sia fermato ad aspettare. È vero, e non è il punto. Il punto non è la novità in astratto, è il tempismo: questo endpoint arriva mentre l’ecosistema attorno agli agenti su Adobe Commerce si sta consolidando, tra il Commerce MCP Server di Adobe e il Catalog Agent. In quel contesto, chiudere un buco di superficie API che prima costringeva a bypassare l’architettura per arrivarci con un agente non è un dettaglio da changelog, è un pezzo che mancava.
Cosa farò
Nelle prossime settimane proverò l’endpoint di lettura sul mio MCP, in un ambiente di test, prima di considerare quello di scrittura. Se mi convince, ne scriverò con il resoconto vero al posto del ragionamento.
Mini-FAQ
Cosa introduce Adobe Commerce 2.4.9 sul fronte API?
Nuovi endpoint REST per leggere e aggiornare i valori di configurazione di sistema, e per aggiornare ed eliminare i template email personalizzati, oltre a una nuova regola di prezzo “free gift” con attivazione e scadenza schedulabili. In produzione dall’8 settembre 2026.
Perché la configurazione via REST è rilevante per gli agenti AI?
Perché prima richiedeva accesso diretto al database o script con privilegi ampi: superfici difficili da esporre a un agente in modo controllato. Con l’endpoint REST, la configurazione entra nello stesso perimetro di autenticazione e permessi degli altri tool di un MCP server.
È già stato testato su un MCP reale?
Non dal sottoscritto, non ancora: questo pezzo ragiona sull’endpoint prima di averlo integrato, dichiarandolo esplicitamente.
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.