Il cliente gestisce l’admin da Claude.Un MCP privato, collegato alla produzione, in tre settimane.

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) 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 per rispondere con i fatti invece che con un copione.