Per circa un anno, l’unico modo che avevo per far parlare un modello con Adobe Commerce era un connettore che mi ero scritto da solo. Un piccolo MCP server fatto in casa, cucito addosso ai progetti che seguivo: qualche tool per leggere ordini, uno per interrogare lo stock, un paio di gate per evitare che un agente combinasse guai su un catalogo di produzione. Funzionava, ma lo mantenevo io. Ogni update di Adobe Commerce era una cosa da tenere d’occhio.
Ad aprile, al Summit, Adobe ha annunciato il suo Commerce MCP ufficiale. Un server vendor, mantenuto da loro, che espone Adobe Commerce ai client agentici via Model Context Protocol. La prima domanda che mi sono fatto non è stata “è meglio del mio?”, ma “quando conviene l’uno e quando l’altro?”. Perché la risposta onesta, dopo averci lavorato per qualche settimana, è: dipende dal progetto. E vale la pena spiegare perché.
Cosa cambia con un MCP di casa Adobe
La differenza più grossa non è tecnica, è di responsabilità. Quando il connettore è mio, ogni breaking change dell’API, ogni nuova versione, ogni endpoint deprecato è un problema che risolvo io, di solito di sera. Con il server ufficiale quella manutenzione la porta Adobe. Sembra un dettaglio da poco finché non ti trovi a inseguire un cambiamento nelle REST API su tre ambienti diversi.
Il secondo vantaggio è la copertura. Il mio MCP esponeva i tool che mi servivano davvero: dieci, forse dodici. Il server Adobe copre un’area molto più ampia del dominio — catalogo, ordini, clienti, prezzi, promozioni — perché è pensato per chiunque, non per i miei tre casi d’uso. Se domani un progetto ha bisogno di un pezzo di Commerce che non avevo mai toccato, con lo standard vendor probabilmente c’è già un tool pronto. Con il mio, mi tocca scriverlo.
Il terzo è il supporto. Un MCP fatto in casa non ha nessuno a cui aprire un ticket. Se si rompe, il tuo team è l’unico team. Uno strumento ufficiale, integrato nel resto dell’ecosistema Adobe, ti dà una porta a cui bussare e — non meno importante — una roadmap che segue quella del prodotto. Quando esce una feature nuova di Commerce, è ragionevole aspettarsi che prima o poi il suo MCP la esponga. Il mio no, a meno che non me la costruisca.
Cosa resta meglio nel fatto-in-casa
Detto questo, non ho buttato via il mio connettore. E non per affezione.
La prima cosa che un server generico non può darti è il controllo. Il mio MCP non è solo un ponte verso le API: è un ponte con delle regole. Ci sono gate scritti apposta — per esempio, un agente non può applicare uno sconto sopra una certa soglia senza che l’operazione passi per un’approvazione umana. Non può toccare un ordine già evaso. Non vede certi campi sensibili del cliente perché a livello di tool quei campi non esistono proprio. Con uno standard vendor questi vincoli li devi mettere altrove, a valle, e diventa più difficile garantire che l’agente non abbia una scorciatoia.
La seconda sono i tool specifici. Su un merchant fashion con un catalogo complicato mi ero scritto un tool che, dato uno SKU, restituiva in un colpo solo disponibilità, prezzo attivo con le regole di catalogo applicate, e stato promozionale — tutto pre-masticato nel formato che serviva all’agente per rispondere a un operatore del customer care. Un MCP generico ti dà i mattoni: catalogo qui, prezzi là, promo altrove. Sta all’agente comporli, con più chiamate e più margine di errore. Il mio tool su misura fa una domanda di business e restituisce una risposta di business. È meno flessibile, ma per quel caso è più solido e costa meno token.
La terza è la forma dei dati. Un tool fatto in casa può restituire esattamente ciò che serve, con i nomi giusti e senza il rumore. Meno campi inutili nel contesto significa meno allucinazioni e meno costo. È una di quelle cose che non vedi in una demo ma senti dopo tre settimane in produzione.
Come decido, progetto per progetto
Non ho una regola dogmatica, ho un paio di domande che mi faccio all’inizio.
- Quanto è “standard” il caso d’uso? Se l’agente deve fare cose ordinarie su un’installazione Commerce ordinaria — leggere ordini, controllare stock, rispondere a domande sul catalogo — parto dal server ufficiale. Reinventarlo sarebbe solo debito tecnico che mi tengo sulle spalle.
- Quanto pesano i gate? Se il progetto tocca operazioni scrivibili e sensibili — prezzi, sconti, modifiche a ordini — il controllo fine che mi dà il connettore di casa vale la manutenzione in più. Preferisco un tool in meno ma con un gate di cui mi fido.
- Quanto è custom il modello dati? Su installazioni molto personalizzate, con attributi e logiche di business non standard, i tool su misura ripagano in fretta. Su installazioni pulite, il vendor copre già tutto.
Nella pratica, la configurazione che mi sta convincendo di più è ibrida: il Commerce MCP ufficiale come base per tutta la copertura di lettura e per le operazioni comuni, affiancato da un piccolo MCP mio con solo i pochi tool ad alto controllo — quelli che scrivono, quelli con i gate, quelli con il formato cucito addosso. Il grosso lo mantiene Adobe, il pezzo delicato lo mantengo io. Il fatto-in-casa smette di essere “tutto il ponte” e diventa “la corsia protetta accanto al ponte”.
C’è un onere onesto da mettere in conto: due server da orchestrare invece di uno, e la disciplina di non duplicare tool tra i due. Ma finora è un prezzo che pago volentieri, perché mi lascia il controllo dove serve e mi toglie la manutenzione dove non aggiunge niente.
La riga di fondo
Il momento in cui un vendor rilascia lo strumento standard è quello in cui vale la pena chiedersi cosa stavi costruendo davvero. Nel mio caso, buona parte del connettore fatto in casa esisteva solo perché non c’era alternativa: quella parte va ceduta al server ufficiale senza rimpianti. Quello che resta — i gate, i tool di business, il controllo sul formato — non era un ripiego, era il valore vero. E quello me lo tengo. Il fatto-in-casa non compete con lo standard: gli si mette accanto e fa il lavoro che lo standard, per definizione, non può fare per il tuo caso specifico.
In sintesi
- Il Commerce MCP ufficiale di Adobe conviene per manutenzione, copertura ampia del dominio e supporto con roadmap allineata al prodotto.
- Un MCP fatto in casa resta migliore per controllo fine, gate di sicurezza su misura, tool di business specifici e formato dei dati ottimizzato.
- La configurazione più solida è ibrida: server ufficiale come base, piccolo connettore proprietario per i pochi tool ad alto controllo.
- La scelta dipende da quanto è standard il caso d’uso, quanto pesano i gate di sicurezza e quanto è personalizzato il modello dati.
Domande frequenti
Il Commerce MCP di Adobe rende inutile un connettore fatto in casa?
No. Rende inutile la parte di connettore che serviva solo a colmare l’assenza di uno standard. Il valore del fatto-in-casa — gate di sicurezza, tool di business, controllo sul formato dei dati — resta e può affiancare lo strumento ufficiale.
Quando conviene lo standard vendor rispetto al custom?
Conviene quando il caso d’uso è ordinario su un’installazione Commerce standard: reinventare quella copertura significa solo prendersi debito tecnico e manutenzione evitabili.
Si possono usare insieme il Commerce MCP ufficiale e uno proprietario?
Sì, ed è la strada che preferisco. Il server ufficiale copre lettura e operazioni comuni, un piccolo MCP proprietario espone solo i tool scrivibili e ad alto controllo, con i gate su misura.
Sono un consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco MCP server e agenti per il mondo Adobe, e scrivo qui quello che imparo dietro le quinte, un progetto alla volta.