# Il cliente gestisce l’admin da Claude. Un MCP privato, collegato alla produzione, in tre settimane. > Un cliente non tecnico ha ricevuto un MCP invece di altre schermate di amministrazione. Ora crea i prodotti del catalogo chattando, su un server che raggiunge la produzione con un solo utente autenticato e registra ogni chiamata. - Caso studio · AI e Automazione · Ago 2026 · 4 min di lettura - Fonte: https://giovannidimeo.com/it/blog/private-mcp-server-in-production/ - Autore: Giovanni Dimeo, https://giovannidimeo.com/it/ Un cliente non tecnico aveva una dashboard di amministrazione che continuava a crescere: un menu, un form e un pulsante per ogni cosa che la piattaforma vende. Invece di altre schermate gli ho dato un [server Model Context Protocol (MCP)](/it/#services) privato: crea le stesse risorse da una conversazione con Claude. Gira fuori dalla piattaforma, raggiunge la produzione tramite le API REST come **un solo utente autenticato**, **crea bozze prima di pubblicare** e **scrive ogni chiamata nell’audit log**. **Tre settimane di lavoro, da solo.** ## Contesto La piattaforma vende prodotti. Ognuno è più risorse insieme: il prodotto, la sua pagina pubblica, una pagina SEO, un piano di prezzo, la voce su Stripe e quella nell’indice di ricerca. Crearne uno voleva dire attraversare l’admin nell’ordine giusto e compilare bene ogni campo. A farlo è il cliente stesso, non un ingegnere. Conosce i prodotti a memoria e l’admin non gli piace. Guardarlo lavorare è stato il brief: la dashboard era corretta e completa, eppure restava la parte più lenta di ogni lancio. ## Il problema - Ogni nuovo prodotto era una sequenza di schermate, facile da sbagliare. - La conoscenza stava nei suoi documenti e nella sua testa, non in un form. - Altre funzioni nell’admin volevano dire altri menu, altri pulsanti, altra formazione. ## Cosa abbiamo deciso La mia proposta: tenere la dashboard come il posto dove controllare e aggiungere una seconda via d’ingresso per chi crea. Quella via è un server Model Context Protocol, privato per questo cliente, che Claude può chiamare. Quattro decisioni lo hanno definito. - L’MCP gira in un cloud suo e raggiunge la produzione solo tramite le stesse API REST che usa tutto il resto. **Niente di nuovo tocca il database.** - Un solo utente, scelto apposta. Accede con Google (OAuth); **il server MCP agisce con il suo token e niente di più.** - **Ogni chiamata a uno strumento finisce nell’audit log**: chi, cosa, risultato. - **Niente va online da una chat.** Gli strumenti creano bozze; lui le controlla nella dashboard e pubblica da lì. > La dashboard è rimasta la fonte di verità. L’MCP è diventato il modo veloce per riempirla. ## Cosa è stato costruito Nove strumenti, uno per ogni cosa che l’admin sa fare: creare e aggiornare un prodotto, scrivere la sua pagina e la pagina SEO, agganciare un piano, sincronizzarlo con Stripe, pubblicare, reindicizzare la ricerca, elencare le categorie. Ogni strumento valida l’input come i form dell’admin, così **un prezzo sbagliato o una categoria mancante si fermano prima della produzione**. L’MCP conserva il token Google dell’utente scelto e lo inoltra a ogni richiesta: l’autorizzazione è quella che quell’utente ha in produzione, non un centimetro di più. **Una chiamata da chiunque altro viene rifiutata all’ingresso.** Creazione e aggiornamento producono bozze, registrate come eventi a sé; pubblicare è uno strumento separato e, per ora, una decisione presa nella dashboard. ## Cosa è cambiato Il cliente crea le risorse dai suoi documenti chattando: incolla la descrizione di un prodotto, Claude chiama gli strumenti nell’ordine giusto e nella dashboard compare una bozza. Ha chiesto di raggiungere così altre risorse, ed è il risultato che mi interessa: **l’admin ha smesso di essere il collo di bottiglia.** L’MCP resta interno, costruito per un solo cliente, non pubblico. ## Cosa rifarei Mettere il server MCP fuori dalla piattaforma, dietro le API esistenti: la revisione di sicurezza riguarda allora un utente e un token, non un sistema nuovo. Dalla chat registrare tutto e pubblicare niente. E partire dai documenti della persona, non dai menu dell’admin: gli strumenti rispecchiano quello che vuole dire, non quello che i form vogliono sentirsi dire. Lo stesso strato di strumenti, con una persona nel giro, è quello che serve a un [chatbot per l’assistenza clienti](/it/blog/ai-customer-support-chatbot-human-in-the-loop/) per rispondere con i fatti invece che con un copione. ## In breve **Cosa abbiamo deciso.** - La dashboard resta il posto dove controllare. L’MCP è il modo veloce per creare. - Un solo utente scelto, accesso Google, il suo token e niente di più. - Bozze dalla chat. Pubblicare resta una decisione umana nell’admin. **Come resta sicuro.** - L’MCP gira in un cloud suo e raggiunge la produzione solo tramite le API REST. - Ogni chiamata a uno strumento finisce nell’audit log: chi, cosa, risultato. - Nove strumenti che validano come i form dell’admin. L’input sbagliato si ferma prima della produzione. ## Domande che arrivano **È sicuro collegare un server MCP alla produzione?** Può esserlo, se il server gira fuori dalla piattaforma, raggiunge la produzione solo tramite le API esistenti come un solo utente autenticato, crea bozze invece di pubblicare e scrive ogni chiamata nell’audit log. È la configurazione descritta in questo pezzo. **Chi può chiamare gli strumenti?** Un solo utente, scelto apposta, che accede con Google. Il server MCP agisce con il suo token, quindi può fare esattamente quello che lui può fare nell’admin e niente di più. Chiunque altro viene rifiutato. **Cosa succede se il modello manda un valore sbagliato?** Ogni strumento valida l’input come fanno i form dell’admin, quindi un prezzo sbagliato o una categoria mancante si fermano prima della produzione. Quello che passa diventa una bozza che la persona controlla nella dashboard.