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. Ed è lì che, per me, i due binari hanno cominciato a curvarsi l’uno verso l’altro.
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, spesso work-in-progress messo insieme da singoli o da piccoli team. 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à. Quello che mancava era la colla, e quella colla adesso qualcuno ha cominciato a scriverla.
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à.
I primi esperimenti, e cosa ho imparato provandoli
Ho messo le mani su un paio di questi server in ambiente locale, contro istanze di test — mai, mai su dati di un cliente. La prima cosa che ho imparato è banale ma sottovalutata: la qualità della risposta dipende interamente da come sono descritti gli strumenti. Un tool MCP esposto con una descrizione vaga (“get analytics data”) porta il modello a fare chiamate a caso; uno descritto bene, con parametri chiari e vincoli espliciti, produce interrogazioni sensate. Chi conosce le API Adobe ha qui un vantaggio enorme, perché sa quali tool valga la pena esporre e con quali guardrail.
La seconda cosa è che questi progetti sono, ad oggi, fragili. Autenticazione gestita in modo artigianale, gestione degli errori quasi assente, nessuna standardizzazione tra un server e l’altro. È il classico paesaggio di una tecnologia a metà 2025: promettente e disordinato. Chi si aspetta un connettore Adobe ufficiale, plug-and-play, resterà deluso ancora per un bel po’. Chi invece ha voglia di sporcarsi le mani trova terreno fertilissimo.
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.
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 inizino ad apparire server MCP per il mondo Adobe non è un dettaglio tecnico da smanettoni. È il primo segnale concreto che i miei due mondi possono davvero parlarsi, senza integrazioni custom da mezzo milione di euro. Lo standard è aperto, le API Adobe ci sono, e la distanza tra “chiedere a parole” e “ottenere dai sistemi” si sta accorciando.
Non credo che tra sei mesi avremo Claude che gestisce un catalogo Commerce in autonomia — e onestamente non lo vorrei neanche. Credo però che chi oggi, con calma e senso critico, impara a costruire e valutare questi ponti, si troverà avanti quando la tecnologia maturerà. Io intanto continuo a sperimentare in locale, a rompere cose che non fanno male a nessuno, e a prendere appunti. È esattamente il momento della carriera in cui mi diverto di più: quando due competenze che ho coltivato separatamente iniziano, finalmente, a incrociarsi.
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.
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.
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.