Ho passato le ultime settimane a costruire una cosa che mi ripromettevo da tempo: un connettore MCP su misura per Adobe Experience Manager. Non un plugin, non un’automazione preconfezionata. Un server MCP scritto da me, che espone un pugno di operazioni sul mio CMS a un agente, in modo che possa leggere e — con molta cautela — agire.
Voglio raccontarla da dietro le quinte, come l’ho fatta davvero: quali operazioni ho deciso di esporre, dove ho messo i freni a mano, cosa mi fa risparmiare tempo per davvero e perché, secondo me, costruirsi il proprio MCP dà un controllo che nessun connettore pronto all’uso ti restituisce.
Perché non ho usato un connettore pronto
Partiamo dall’obiezione ovvia. Il Model Context Protocol è ormai uno standard, c’è una Registry pubblica di server MCP, e la tentazione di installare qualcosa di generico è forte. Ho provato quella strada e l’ho abbandonata in fretta.
Il problema di un connettore generico su AEM non è che funziona male. È che decide lui cosa l’agente può toccare. Ti espone un’API ampia, spesso l’intera superficie REST o GraphQL, e demanda a te il compito di sperare che l’agente non faccia danni. In un CMS in produzione questo è esattamente il tipo di fiducia che non voglio concedere.
Quando costruisci il tuo MCP, sei tu a definire il contratto: l’agente può fare solo ciò che tu hai deciso di esporre come tool, con i parametri e i vincoli che hai scritto tu. Non è una sfumatura. È la differenza tra dare a un collaborante nuovo le chiavi di tutto l’ufficio e dargli il badge di una sola stanza.
Le operazioni che ho esposto (e quelle che non ho esposto)
Ho tenuto la superficie volutamente piccola. Ogni tool in più è un modo in più di sbagliare, e la mia esperienza con Adobe Commerce mi ha insegnato che le integrazioni muoiono di ambizione, non di prudenza.
Sul lato lettura, che è quello dove mi sono sentito subito a mio agio, ho esposto tre tool:
- find_pages — cerca pagine per path, template o proprietà, e restituisce metadati essenziali. È il tool che uso di più: mi fa dire all’agente “trovami tutte le pagine sotto /products che usano il template scheda e non hanno il campo SEO description compilato” senza aprire la console di AEM.
- read_content_fragment — legge un content fragment per ID o path e mi ritorna il modello con i suoi campi. Qui l’agente è bravissimo: capisce la struttura, mi segnala incoerenze, propone riscritture.
- list_assets — elenca gli asset in una cartella del DAM con i loro metadati, senza scaricare i binari.
Sul lato scrittura sono stato molto più stretto. Ho esposto solo update_content_fragment, e nient’altro. L’agente può aggiornare i campi testuali di un content fragment esistente. Non può crearne di nuovi, non può cancellare, non può pubblicare, non può toccare il layout delle pagine.
Questa è una scelta di merito, non un limite tecnico. Il layout di una pagina AEM e i contenuti già pubblicati sono le due cose che un agente non deve poter modificare senza un umano in mezzo. Un content fragment sbagliato lo correggi in trenta secondi. Un componente spostato in un template ereditato da cento pagine te lo porti dietro per giorni.
I freni a mano che ho costruito nel connettore
Qui sta la parte che un connettore pronto non ti dà: le guardie le ho messe io, dentro il tool, dove nessun prompt può aggirarle.
Backup prima di ogni scrittura. Il tool update_content_fragment, prima di scrivere, salva una copia dello stato corrente del fragment in un file locale con timestamp. Non mi fido dei revision manager quando c’è un agente di mezzo: voglio un mio artefatto, fuori dal sistema, che posso ripristinare a mano.
Nessuna pubblicazione automatica. Il tool scrive sull’ambiente di authoring e si ferma lì. La replica verso il publish resta un gesto umano, fatto dalla console. L’agente prepara, io pubblico.
Anteprima obbligatoria. Prima di applicare, il tool restituisce un diff campo per campo — valore vecchio, valore nuovo — e attende una conferma esplicita. È il pattern che uso ovunque ormai: l’agente propone, mi mostra cosa cambia, e io approvo. Su un CMS pubblico l’approvazione umana non è burocrazia, è l’unica ragione per cui mi fido di lasciar lavorare l’agente.
Cosa mi fa risparmiare davvero
Sarò onesto, perché è facile raccontare queste cose come rivoluzioni e non lo sono. Il risparmio non è nell’operazione singola. Aggiornare un content fragment a mano mi prende un minuto, e l’agente non me lo fa risparmiare in modo drammatico.
Il risparmio è nel lavoro ripetitivo e diffuso. Un caso reale, anonimizzato: un merchant con un catalogo editoriale gestito su AEM, qualche centinaio di content fragment con le descrizioni prodotto, e la necessità di allineare tono e lunghezza dei testi dopo un cambio di linea editoriale. A mano è mezza giornata di taglia-e-incolla che nessuno ha voglia di fare. Con il mio MCP: l’agente trova i fragment con find_pages e read_content_fragment, mi propone le riscritture, io scorro i diff e approvo a blocchi. Un paio d’ore, e con più attenzione di quanta ne avrei avuta al centoventesimo fragment fatto a mano.
L’altro risparmio, meno visibile ma per me più prezioso, è l’audit. Chiedere “quali pagine hanno metadati SEO mancanti” o “quali asset non hanno alt text” è banale da esporre come lettura, e trasforma una domanda che prima richiedeva uno script in una conversazione.
La lezione da builder
Se dovessi riassumere quello che ho imparato in una frase: il valore di un MCP su misura non è nei tool che espone, ma in quelli che sceglie di non esporre.
Un connettore pronto ottimizza per la copertura — vuole poter fare tutto, perché non sa cosa ti serve. Il connettore che scrivi tu ottimizza per il controllo — sa esattamente cosa vuoi, e può permettersi di essere piccolo. In un sistema come AEM, dove authoring, layout e pubblicazione sono responsabilità diverse con rischi diversi, questa differenza è tutto.
Costruirlo ha un costo, chiaro. Ho scritto codice, ho gestito l’autenticazione, ho testato i freni prima di fidarmi. Ma è un costo che paghi una volta e che ti compra una cosa che con i connettori generici non compri: la certezza di sapere, riga per riga, cosa l’agente può e non può fare sul tuo CMS.
Mini-FAQ
Che cos’è un MCP per AEM?
È un server che implementa il Model Context Protocol ed espone operazioni su Adobe Experience Manager — come cercare pagine, leggere e aggiornare content fragment, elencare asset — come tool che un agente AI può invocare in modo controllato.
Perché costruire un MCP custom invece di usarne uno pronto?
Perché con un connettore custom decidi tu quali operazioni esporre e con quali vincoli. Su un CMS in produzione questo controllo vale più della copertura ampia di un connettore generico.
Un agente può modificare il layout delle pagine AEM?
Nel mio connettore no, per scelta. Espongo solo l’aggiornamento dei content fragment esistenti. Layout e pubblicazione restano fuori dalla portata dell’agente e in mano a un umano.
Come si evitano danni ai contenuti pubblicati?
Con tre freni costruiti nel tool: backup dello stato prima di ogni scrittura, nessuna pubblicazione automatica (si scrive solo in authoring) e anteprima con diff che richiede approvazione umana esplicita.
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 l’ecosistema Adobe, e scrivo di quello che imparo mentre le metto in produzione.