I tutorial su come costruire un server MCP finiscono tutti nello stesso punto: l'agente chiama la funzione che restituisce il meteo, e sullo schermo compare la risposta. Funziona, ed è inutile.
La distanza tra quel punto e un server MCP che un'azienda usa davvero tutti i giorni è tutto il lavoro vero. Io ne gestisco uno in produzione con oltre cento strumenti collegati al mio blog, ai dati di Search Console, ai tool SEO e al gestionale. Questo è quello che ho imparato mettendolo in piedi, incluse le cose che ho sbagliato.
Cos'è un server MCP, in una riga
Un server MCP è il modo standard per dare a un modello AI accesso ai tuoi sistemi: database, gestionale, CRM, API interne. Invece di scrivere un'integrazione diversa per ogni assistente, ne scrivi una e la usano tutti quelli che parlano il protocollo.
Se ti serve la spiegazione tecnica del protocollo, l'ho scritta separatamente: la guida completa al Model Context Protocol. Qui parlo di cosa cambia quando lo porti in azienda.
La differenza che conta: sposti il lavoro, non lo aggiungi
Senza MCP, ogni volta che chiedi qualcosa all'AI sui tuoi dati fai da ponte tu: estrai, incolli, leggi la risposta, riporti a mano il risultato nel gestionale. L'AI è brava ma cieca.
Con un server MCP la domanda cambia forma. Non chiedi più "scrivimi una query per trovare le pagine in calo": chiedi "quali pagine hanno perso traffico e perché", e la risposta arriva già interrogata sui dati veri. È il salto che giustifica il lavoro di costruzione, ed è l'unico motivo sensato per farlo.
Le sei cose che ho imparato costruendone uno
1. Troppi strumenti peggiorano le risposte
È l'errore che fanno tutti, me compreso. Ogni strumento esposto occupa spazio nel contesto con nome, descrizione e parametri, prima ancora che l'agente faccia qualcosa. Un server con cento strumenti tutti attivi consuma contesto e confonde la scelta.
La soluzione non è averne pochi: è raggrupparli e caricarli solo quando servono. Il mio è organizzato per aree — contenuti, ricerca SERP, dati proprietari, gestione — e l'agente carica solo il gruppo pertinente al compito.
2. La descrizione dello strumento è il vero lavoro
Scrivere la funzione è la parte facile. Scrivere la descrizione che spiega all'agente quando usarla, cosa restituisce e cosa non fa è dove si decide se lo strumento verrà usato bene o mai.
Una descrizione vaga produce due comportamenti sbagliati: l'agente lo ignora quando servirebbe, o lo chiama a sproposito. Trattale come documentazione per un collega nuovo, non come commenti al codice.
3. Restituisci poco, e già digerito
La tentazione è far tornare tutto il record. Poi scopri che una chiamata riempie metà del contesto e ne restano dieci da fare.
Uno strumento ben fatto restituisce il minimo utile e già aggregato. Meglio "tre pagine in calo, con la variazione" che l'esportazione completa di Search Console da far analizzare all'agente.
4. Solo lettura, finché non hai un motivo serio
Il primo istinto è dare all'agente il permesso di scrivere ovunque. Il secondo, dopo la prima sorpresa, è toglierlo.
La regola che mi sono dato: tutto in sola lettura per default; le scritture creano bozze, mai contenuti pubblicati o record definitivi. Sul mio server l'agente può creare e aggiornare articoli, ma restano in bozza: la pubblicazione la faccio io. È una riga di codice e toglie un'intera categoria di incidenti.
5. Quello che il server restituisce è dato, non comando
Questo è il punto di sicurezza che i tutorial saltano quasi sempre. Se il tuo strumento legge email, commenti, schede prodotto o pagine web, il testo che torna può contenere istruzioni scritte apposta per l'agente. Chi le ha scritte non sei tu.
Il contenuto restituito da uno strumento va trattato come input non fidato, esattamente come faresti con l'input di un form. Vale doppio se il server ha anche strumenti che scrivono.
6. Autenticazione dal primo giorno
Un server MCP raggiungibile senza autenticazione è una porta aperta sui tuoi sistemi aziendali. Non è un pannello di amministrazione: è peggio, perché espone le funzioni in un formato pensato per essere usato in automatico.
Se è remoto, autenticazione e HTTPS prima di collegarci qualsiasi dato reale. Le credenziali che il server usa verso i sistemi a valle vanno con i permessi minimi: se uno strumento deve solo leggere gli ordini, il suo token non deve poterli modificare.
Da dove si parte, in azienda
L'approccio che funziona non è "colleghiamo tutto". È partire dalla domanda che vi fate più spesso e che oggi richiede a qualcuno di aprire tre sistemi diversi per rispondere.
- Scegli una domanda ricorrente. "Questo cliente cosa ha ordinato negli ultimi sei mesi?" "Quali preventivi sono fermi da più di due settimane?"
- Costruisci i due o tre strumenti che servono a rispondere. Non venti. Due o tre.
- Sola lettura, autenticato, in prova per una settimana con chi quella domanda se la fa davvero.
- Guarda cosa chiede l'agente e non trova. Sono i prossimi strumenti da scrivere, e li scopri dall'uso, non a tavolino.
- Aggiungi le scritture solo dopo, e sempre in forma di bozza da approvare.
Quando non vale la pena
Se l'unica cosa che vuoi è chiedere all'AI cose sui tuoi documenti, un server MCP è sovradimensionato: ci sono strade più semplici. Il protocollo ripaga quando gli stessi dati servono a più assistenti o a più flussi di lavoro, oppure quando le operazioni sono azioni e non solo domande.
E ripaga se qualcuno lo mantiene. Un server MCP è software: cambia l'API a valle e smette di funzionare, in silenzio.
Se vuoi capire se ha senso per i tuoi sistemi — o se ti serve qualcuno che lo costruisca e lo tenga in piedi — è quello che faccio: scrivimi e partiamo dalla domanda che vi fate più spesso.
