Il Suo prodotto necessita di un server MCP: esporre i dati commerce agli agenti AI in sicurezza

Il Model Context Protocol è passato da interessante a strutturale più rapidamente di quanto riescano la maggior parte degli standard di integrazione. Shopify fornisce server MCP a ogni negozio; i principali assistenti possono utilizzare strumenti su sistemi esterni; e una quota significativa del traffico web ora arriva da sistemi automatizzati, non da utenti in navigazione.

Per chi gestisce una piattaforma commerciale o un prodotto SaaS, questo pone una domanda concreta con una risposta tutt’altro che ovvia: ha già un’API — perché un agente ne richiede una diversa?

Perché la Sua REST API non basta

Una REST API è pensata per uno sviluppatore che legge la documentazione, conosce il suo dominio e scrive codice che chiama gli endpoint nell’ordine corretto. Un agente non ha questi vantaggi: dispone di un elenco di strumenti, una descrizione per ciascuno, e una sola occasione per scegliere quello giusto.

Le differenze rilevanti:

• Scoperta. Un agente deve apprendere in tempo reale cosa può fare il suo sistema, direttamente dall’interfaccia. La sua OpenAPI spec descrive gli endpoint, non l’intento.
• Granularità. Le REST API sono modellate sulle risorse: recupera l’ordine, il cliente, le righe, e unisca i dati manualmente. Un agente vuole una sola chiamata che risponda a qual è lo stato dell’ultimo ordine di questo cliente: orientata al compito, non alla risorsa.
• Ambiguità. Uno sviluppatore risolve quello blu, taglia media leggendo il modello delle varianti. Un agente ha bisogno di uno strumento che accetti quella formulazione e la interpreti.
• Gestione degli errori. Un 422 con un oggetto di validazione aiuta uno sviluppatore. Un agente necessita di un errore che indichi, a parole, cosa modificare.
• Blast radius. L’errore di uno sviluppatore viene intercettato dal test suite. Quello di un agente avviene in produzione, per conto di un cliente, in tempo reale.

Un server MCP non è un semplice wrapper della sua API. È un’interfaccia diversa, progettata per un utilizzatore differente, che si appoggia alla stessa logica di dominio.

Progettare gli strumenti in base ai compiti, non alle risorse

Il fattore principale che determina se un agente utilizza correttamente il suo prodotto è la denominazione e la portata degli strumenti. È preferibile offrire pochi strumenti, ben descritti e orientati al compito, piuttosto che una mappatura fedele del modello dati.

L’insieme iniziale tipico di un prodotto commerciale comprende:

• search_products — query in linguaggio naturale, risultati ordinati con gli attributi necessari per scegliere. Non un dump grezzo del catalogo.
• get_product_details — tutte le informazioni utili alla decisione: varianti, disponibilità, tempi di consegna, condizioni di reso.
• check_availability — quantità e posizione, fornite direttamente invece che dedotte da un oggetto stock.
• get_order_status — la domanda che i clienti pongono realmente, risolta in una sola chiamata.
• start_return — una scrittura protetta, soggetta alle regole reali di ammissibilità.
• get_policy — condizioni di reso, spedizione e garanzia in formato testuale, così che l’agente citi la sua policy e non una sua interpretazione.

Scriva le descrizioni degli strumenti come se fossero per un nuovo collega competente al primo giorno: cosa fa, quando usarlo, quando non usarlo e cosa rifiuterà. Queste descrizioni sono l’unico manuale utente che l’agente leggerà, e incidono sulla correttezza più di qualsiasi qualità del modello.

Cosa non deve mai diventare uno strumento

Le esclusioni contano più delle inclusioni, perché uno strumento esposto sarà prima o poi chiamato in modi non previsti.

• Qualsiasi operazione che coinvolga strumenti di pagamento. Tokenizzi, deleghi e mantenga i dati delle carte completamente fuori dalla superficie accessibile all’agente.
• Esportazione massiva di dati. Uno strumento che restituisce l’intero catalogo o la lista clienti è un endpoint di scraping più educato.
• Operazioni amministrative. Modifiche di prezzo, aggiustamenti di inventario, gestione utenti. Se è presente nell’area amministrativa, non deve essere nel server MCP.
• Qualsiasi operazione senza controllo dei permessi per tenant, applicato lato server a ogni chiamata.
• Query cross-customer. Un agente che agisce per un cliente deve essere strutturalmente impossibilitato a vedere i dati di altri — non solo improbabile che lo faccia.

Autenticazione, permessi e limiti

Qui la maggior parte delle implementazioni è più debole, perché la parte interessante è la progettazione degli strumenti, mentre tutto il resto è ripetitivo.

1. Autentichi l’agente e, separatamente, stabilisca per chi agisce. Sono due fatti distinti, e confonderli porta ad accessi cross-customer.
2. Limiti le credenziali allo stretto necessario. Un agente che esplora i prodotti non deve accedere allo storico ordini. Rilasci credenziali per singolo scopo e con scadenza.
3. Applichi rate limit per tenant e per strumento. Gli agenti riprovano spesso. Un limite generoso per un umano viene facilmente superato da un ciclo automatizzato.
4. Registri ogni chiamata con argomenti e risultato. In caso di problemi dovrà ricostruire esattamente cosa è stato richiesto e restituito. Questo log è anche la prima difesa contro gli abusi.
5. Versioni i suoi strumenti. Modificare il comportamento di uno strumento senza preavviso interrompe gli agenti che vi fanno affidamento, e a differenza di un’integrazione sviluppatore, nessuno leggerà il changelog.
6. Utilizzi chiavi di idempotenza per gli strumenti di scrittura. Un agente che va in timeout e riprova non deve generare due resi.

I dati sottostanti determinano tutto

Un server MCP espone i dati di prodotto. Se questi dati sono scarsi, incoerenti o errati, l'agente li presenterà comunque fedelmente — in modo rapido e sicuro, al cliente.

Prima di sviluppare l'interfaccia, occorre valutare con onestà se il catalogo sottostante sia in grado di sostenerla. Completezza degli attributi, tassonomia coerente, dati accurati su stock e spedizione, e una politica di resi disponibile come testo strutturato (non solo in PDF) sono prerequisiti essenziali. Abbiamo descritto il processo che adottiamo per portare un catalogo a questo livello; è un lavoro concreto, spesso poco visibile, ma rappresenta il vero progetto.

Vale la pena sviluppare questa soluzione ora?

Una valutazione onesta è necessaria: il settore evolve rapidamente e anticipare troppo i tempi comporta costi reali.

Proceda ora se: utilizza una piattaforma che già espone MCP e intende estenderla; il suo prodotto è rivolto agli sviluppatori, dove l'uso assistito da agenti è già prassi; oppure se vende articoli che un assistente potrebbe ragionevolmente cercare per conto del cliente.

Rimandi se: i dati di prodotto non sono ancora in uno stato che accetterebbe vengano citati da una macchina; non ha risorse per monitorare e migliorare una superficie agente attiva; oppure se i suoi clienti non la raggiungono tramite questi canali e ne ha verificato l'effettiva assenza.

In ogni caso, svolga ora il lavoro preliminare. Dati di prodotto puliti, politiche strutturate e un'API di dominio orientata alle attività sono risorse utili a prescindere dal protocollo che prevarrà, e rappresentano la parte più impegnativa. Lo strato MCP è relativamente rapido da implementare.

La nostra pratica Node.js realizza queste interfacce; la questione più ampia di dove inserire i canali agenti nella strategia commerciale è ciò a cui rispondono il nostro lavoro di integrazione AI e il team di ingegneria AI. Se la sua priorità è essere trovato dagli assistenti più che transare tramite essi, si tratta di un progetto correlato ma distinto — veda come far raccomandare i suoi prodotti da ChatGPT e Perplexity.

Inizi con l'elenco degli strumenti

Prima di scrivere codice, elenchi sei azioni che un agente dovrebbe poter compiere sui suoi prodotti e sei che non deve mai eseguire. Quel documento costituisce gran parte della progettazione. Lo redigeremo insieme a Lei. Contatti il nostro team; rispondiamo entro un giorno lavorativo.