Da anni vivo con un piede in due mondi che, sulla carta, dovrebbero parlarsi molto più di quanto facciano. Da una parte Adobe: Commerce, Experience Manager, Analytics, Target, il posto dove passo le giornate a progettare e mantenere esperienze per chi vende online. Dall’altra l’AI agentica, che negli ultimi mesi seguo con un misto di curiosità e sano scetticismo professionale. Fino a poco tempo fa erano due binari paralleli. Poi ho iniziato a vedere comparire, in giro per GitHub e nelle discussioni tra addetti ai lavori, i primi server MCP pensati per il mondo Adobe. E ho fatto la cosa che faccio sempre quando una tecnologia mi incuriosisce: invece di scriverne, ho provato a costruirne uno.
Voglio essere chiaro subito, perché è il punto di tutto l’articolo: siamo a metà 2025 e quello che sto descrivendo è early-stage. Roba beta, sperimentale, work-in-progress messo insieme da singoli o da piccoli team, il mio prototipo compreso. Non è una suite matura, non è supportata ufficialmente, non è pronta per andare in produzione su un merchant serio. Ma è esattamente per questo che mi interessa: è il momento in cui una tecnologia smette di essere annuncio e inizia a essere codice che gira.
Cos’è MCP, in due righe, per chi sta su Adobe
Model Context Protocol è lo standard aperto che Anthropic ha rilasciato a fine 2024 per far dialogare un assistente come Claude con sistemi e dati esterni. Detta in modo brutale: invece di copiare-incollare a mano numeri e report dentro una chat, un server MCP espone strumenti e risorse che l’assistente può interrogare da solo. Il modello smette di essere una scatola isolata e diventa qualcosa che può leggere, e in prospettiva agire su, i sistemi che uso ogni giorno.
Chi lavora in ambito Adobe capisce subito perché la cosa mi ha acceso una lampadina. Adobe Commerce, AEM e Analytics hanno tutti delle API robuste: GraphQL e REST su Commerce, le Content Fragment API e il GraphQL di AEM, la Analytics 2.0 API. La materia prima per costruirci sopra un server MCP c’è già, ed è merito di Adobe che quelle piattaforme le ha aperte per bene molto prima che servissero a un agente. Quello che mancava era la colla. E la colla, adesso, chiunque sappia leggere una API può iniziare a scriversela.
Cosa immagino di poter chiedere in linguaggio naturale
Provo a raccontare non tanto quello che ho visto girare, perché per ora sono esperimenti grezzi, quanto quello che questi primi mattoni mi fanno intravedere. È qui che l’entusiasmo prende il sopravvento, e va bene così, purché resti lucido.
Su Adobe Analytics immagino di chiedere a Claude: “confronta il conversion rate del checkout mobile nelle ultime quattro settimane con lo stesso periodo dell’anno scorso e dimmi in quale step si perde più traffico”. Oggi quella domanda la traduco a mano in un report Analysis Workspace, con segmenti e metriche calcolate. Un server MCP ben fatto potrebbe far interrogare la Analytics API direttamente al modello, che mi restituisce i numeri e una lettura in prosa. Non è magia: è il modello che chiama un’API che avrei chiamato comunque, solo che salta il passaggio manuale.
Su AEM il caso che mi tenta di più è quello editoriale. “Quali Content Fragment del catalogo prodotti non hanno la description tradotta in tedesco?” oppure “elenca le pagine pubblicate nell’ultimo mese senza meta description”. Sono domande di governance dei contenuti che oggi richiedono query mirate o un giro noioso nell’author. Con un server MCP che si appoggia alle API di AEM, diventano conversazione.
E poi c’è Adobe Commerce, il mio terreno di casa. Qui il salto immaginato è ancora più grande, perché non parliamo solo di leggere ma di operare: “mostrami gli ordini in stato pending payment da più di 48 ore”, “trova i prodotti sotto la soglia minima di stock nella categoria calzature”, fino, un giorno, a “aggiorna il prezzo di questi SKU in staging”. Ed è proprio quando arrivo qui che l’entusiasmo deve incontrare la lucidità.
Il mio prototipo, e cosa ho imparato sbattendoci la testa
Nelle ultime settimane ho messo insieme un prototipo di server MCP contro un’istanza Commerce di test. Poca roba: quattro o cinque tool di sola lettura sugli ordini e sul catalogo, credenziali con scope minimo, tutto in locale. Mai, per nessun motivo, su dati di un cliente. Non è un prodotto, non lo sarà a breve, e non ho intenzione di raccontarvi che ho costruito una piattaforma. Ho costruito un giocattolo che funziona, ed è già abbastanza per aver capito tre cose che leggendo non avrei capito.
La prima è banale ma sottovalutata: la qualità della risposta dipende quasi interamente da come sono descritti gli strumenti. Il mio primo tentativo esponeva un tool generico “query orders” con una descrizione vaga. Claude ha iniziato a fare chiamate a caso, a chiedere campi che non esistevano, a inventarsi filtri. Non era il modello a essere stupido: ero io che gli avevo dato una mappa illeggibile. Quando ho riscritto le descrizioni con parametri espliciti, vincoli, valori ammessi ed esempi, le interrogazioni sono diventate sensate. È qui che la mia tesi su tutta questa faccenda diventa concreta: l’AI moltiplica se chi la guida sa cosa sta facendo. Chi conosce le API Adobe sa quali tool valga la pena esporre, come descriverli e dove mettere i paletti. Chi non le conosce ottiene un agente che sbaglia con eleganza.
La seconda è che questi progetti sono, ad oggi, fragili, e il mio non fa eccezione. Autenticazione gestita in modo artigianale, gestione degli errori quasi assente, nessuna standardizzazione tra un server e l’altro. Il mio prototipo si è piantato la prima volta che l’API ha risposto con un errore che non avevo previsto, e Claude, non ricevendo niente di sensato, ha provato a tirare a indovinare la risposta. Lezione: un tool che fallisce in silenzio è peggio di un tool che non esiste.
La terza è la più interessante e non me l’aspettavo: quando il ponte funziona, la parte difficile non è più tecnica. È capire quale domanda vale la pena fare. Il collo di bottiglia si sposta a monte, sull’idea.
I limiti e la sicurezza, che vengono prima dell’entusiasmo
Qui divento serio, perché è la parte che nel mio lavoro conta di più. Collegare un assistente AI ai dati Adobe significa aprire una porta, e le porte vanno progettate meglio dei muri.
- Read prima di write. La mia regola personale, oggi, è che un server MCP verso Adobe dovrebbe esporre solo operazioni di lettura, o al massimo scritture in staging. Far modificare prezzi, stock o contenuti in produzione a un modello, a metà 2025, non lo farei mai. Non perché il modello sia stupido, ma perché la catena di responsabilità non è ancora chiara.
- Least privilege sulle credenziali. Il server MCP eredita i permessi delle API key che gli dai. Se gli passi un service account con accesso completo a Commerce, gli stai dando le chiavi di casa. Vanno usati token con scope minimo, esattamente come faremmo per qualsiasi integrazione.
- Dati sensibili e privacy. Analytics e Commerce contengono dati personali. Prima di far transitare qualsiasi cosa verso un modello, va capito dove finiscono i dati, se vengono trattenuti, e se il contesto normativo lo permette. Su dati di clienti reali, questo per me è un no fino a prova contraria.
- Prompt injection e confused deputy. Se un contenuto AEM o un campo ordine contiene istruzioni malevole, un modello che legge quel dato e ha anche strumenti di scrittura può essere manipolato. È un rischio nuovo, poco discusso, e va messo in conto da subito.
- Log e baseline. Prima di discutere di rischi teorici, misuro cosa fa l’agente: quali tool chiama, con quali parametri, quante volte sbaglia. Senza log, ogni conversazione sulla sicurezza degli agenti è chiacchiera da convegno.
Nessuno di questi limiti mi fa spegnere l’entusiasmo. Mi fa solo tenere gli esperimenti dove devono stare adesso: in laboratorio, su dati finti, con permessi minimi.
Perché per me è comunque un momento
La mia opinione, netta: il fatto che nel giugno 2025 si possa costruire in qualche serata un ponte funzionante tra Claude e i dati Adobe non è un dettaglio tecnico da smanettoni. È il primo segnale concreto che i miei due mondi possono davvero parlarsi, e che per farlo non serve più un progetto di integrazione da mesi-uomo. Lo standard è aperto, le API Adobe ci sono, e la distanza tra “chiedere a parole” e “ottenere dai sistemi” si è accorciata.
Non ho idea di dove sarà questa roba tra un anno, e diffido di chiunque dica di saperlo. Non sto neanche dicendo che dovete correre a costruirvi un server MCP: se il vostro catalogo è un disastro, quel tempo è speso meglio a rimetterlo in ordine, perché un agente su dati sporchi amplifica il disordine invece di risolverlo. Dico solo cosa sto facendo io: continuo a sperimentare in locale, a rompere cose che non fanno male a nessuno, e a prendere appunti su cosa si rompe. È esattamente il momento della carriera in cui mi diverto di più: quando due competenze che ho coltivato separatamente iniziano, finalmente, a incrociarsi. E quando il codice che gira dice cose più interessanti delle slide.
Mini-FAQ
Cos’è un server MCP per Adobe?
È un connettore che espone le API di prodotti Adobe come Analytics, AEM o Commerce a un assistente AI tramite il Model Context Protocol, così che il modello possa interrogare quei sistemi in linguaggio naturale. A metà 2025 si tratta di progetti sperimentali, non ufficiali, il mio prototipo incluso.
Posso usarlo in produzione oggi?
No. A giugno 2025 questi server sono early-stage e adatti solo ad ambienti di test con dati non reali. Mancano autenticazione robusta, gestione errori e standardizzazione.
Qual è il rischio principale?
Concedere troppi permessi. Un server MCP eredita gli scope delle credenziali che riceve: vanno usati token a privilegio minimo e, per ora, limitarsi a operazioni di sola lettura o in staging.
Che tipo di domande posso immaginare di fare?
Interrogazioni di lettura: andamento del conversion rate su Analytics, Content Fragment senza traduzione su AEM, ordini in pending payment su Commerce. Le operazioni di scrittura in produzione, oggi, sono da evitare. E la qualità delle risposte dipende da come sono descritti i tool: è lì che serve chi conosce davvero le API Adobe.
Chi sono. Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da tempo affianco al lavoro sull’ecosistema Adobe l’approfondimento dell’AI agentica, in particolare Claude e il Model Context Protocol. Su questo blog racconto, da insider, cosa succede quando questi due mondi iniziano a parlarsi.