Il problema che ti trovi davanti

Hai un agente che funziona bene su compiti generici, ma appena provi a chiedergli qualcosa che riguarda il tuo lavoro vero ti accorgi che non ha accesso a niente. Non vede i tuoi file, non sa dove cercare i numeri di un progetto, non può aprire un task nel tuo sistema di gestione. Per ogni cosa deve chiederti di copiaincollare, e a quel punto ti viene il dubbio che stai facendo più lavoro tu a imboccarlo che se lo facessi direttamente.

Questo capitolo parte da lì: hai capito come funziona un agente e come dargli istruzioni sensate, ma adesso hai bisogno che veda i tuoi dati e possa agire sui tuoi strumenti. E qui entra in scena MCP, che sta per Model Context Protocol.

L’idea dietro MCP

MCP è un protocollo aperto nato in Anthropic (la casa di Claude) per collegare gli agenti ai sistemi che usi davvero. L’analogia più semplice è quella di una presa elettrica standard: invece di cablare ogni elettrodomestico direttamente al muro in modo diverso, hai una spina universale che tutti capiscono. MCP fa la stessa cosa per gli agenti: definisce un modo standard per esporre dati e azioni, così l’agente può collegarsi a un server MCP senza che qualcuno debba riscrivere tutto ogni volta.

Un server MCP è un programma che gira da qualche parte (sul tuo computer, su un server aziendale) e si occupa di una cosa specifica: leggere il contenuto di una cartella, interrogare un database, creare task in Todoist, mandare mail. L’agente non tocca direttamente i tuoi sistemi: chiede al server MCP, che fa il lavoro sporco e gli riporta il risultato. Questo passaggio in mezzo è ciò che ti dà il controllo: il server decide cosa l’agente può vedere e cosa può fare.

Due tipi di server, due livelli di rischio

Ci sono server MCP che espongono dati e server che espongono azioni. La differenza pratica è enorme.

Un server che espone dati legge qualcosa per l’agente: il contenuto di una cartella, le righe di un foglio di calcolo, i messaggi di una chat aziendale. L’agente chiede «dammi gli ultimi dieci file della cartella progetti», il server glieli passa, e l’agente ci ragiona sopra. Il rischio è limitato: nel peggiore dei casi, l’agente legge qualcosa che non doveva leggere. Dipende da come hai configurato il server, ma non può cancellare, modificare o spedire niente.

Un server che espone azioni fa cose: crea un task, spedisce una mail, modifica un record in un database, posta un messaggio in un canale Slack. Qui il rischio sale. Se l’agente decide che per risolvere il tuo problema la mossa giusta è mandare una mail a tutto il team, e tu gli hai dato il permesso, quella mail parte. Non è un difetto: è esattamente ciò per cui lo hai collegato. Ma devi sapere cosa stai autorizzando prima di collegare il server.

Un esempio concreto: server filesystem e server GitHub

Immagina di avere un agente collegato a un server MCP filesystem configurato per leggere la cartella dei tuoi appunti di lavoro. Gli chiedi «riassumimi gli appunti dell’ultima settimana sul progetto X». L’agente chiede al server la lista dei file, il server glieli passa, l’agente li legge e ti fa il riassunto. Hai risparmiato mezz’ora di rilettura, e non è successo niente di rischioso: il server non scrive, solo legge.

Ora aggiungi un server MCP GitHub che espone anche azioni. L’agente può leggere issue e pull request, ma anche commentarle, creare nuove issue, aggiornare lo stato. Gli chiedi «sistema i task aperti in base alle priorità che ti ho mandato ieri». L’agente legge le issue, capisce quali spostare, e le sposta. Risparmio di tempo enorme, ma se ha capito male le tue priorità, hai trenta issue nel posto sbagliato. Il server ha fatto esattamente quello che doveva: eseguire l’azione che l’agente ha chiesto.

La lezione pratica è che con i server di sola lettura puoi permetterti di esplorare e sbagliare. Con i server che scrivono, controlli il primo risultato a mano prima di dare via libera.

Come valutare un server MCP nuovo

Quando trovi un server MCP che ti sembra utile, fatti tre domande prima di collegarlo:

1. Cosa espone? Legge dati, esegue azioni, o entrambe le cose? Se esegue azioni, quali? Un server ben documentato te lo dice in modo esplicito. Se non è chiaro, è un segnale d’allarme.

2. Come configuri i permessi? I server seri ti permettono di delimitare cosa l’agente può vedere e fare: solo questa cartella, solo questo progetto, solo azioni di lettura. Se un server ti chiede accesso pieno a un sistema senza opzioni di limitazione, è un problema.

3. Chi l’ha scritto e quanto è usato? I server MCP pubblicati da Anthropic, da team aziendali conosciuti o da progetti open source con una community attiva hanno più probabilità di essere sicuri e aggiornati. Un server scritto da uno sconosciuto tre settimane fa, senza issue né discussioni, è da prendere con più cautela.

La regola pratica è che se stai collegando un server a un agente che usi sul lavoro vero, devi capire cosa fa. Se la documentazione non basta, guardi il codice. Se il codice non ti convince, non lo colleghi.

Una cosa da fare

Scegli un compito che fai spesso e che richiede di pescare dati da qualche parte: riassumere gli ultimi appunti di un progetto, controllare lo stato di alcuni task, cercare un numero in un foglio. Poi guarda se esiste un server MCP che espone quei dati in sola lettura. Per la cartella di appunti, c’è il server filesystem. Per Todoist, c’è un server MCP ufficiale. Per Google Sheets, ne esistono diversi.

Installa il server, configuralo per esporre solo la cartella o il progetto che ti serve, collegalo all’agente e prova a fargli fare il compito. Controlli il risultato a mano, ma se il server è di sola lettura non può succedere niente di irreversibile. È il modo più sicuro per prendere confidenza con MCP.

Prompt pronti

Quando provi un server MCP nuovo, usa questo per capire cosa l’agente vede davvero:

Ho appena collegato un server MCP per [sistema o cartella].
Fammi vedere cosa puoi leggere: lista i primi cinque elementi che vedi, senza elaborare.
Poi dimmi se puoi anche scrivere o solo leggere.

Quando vuoi che l’agente usi un server per un compito vero:

Devi [obiettivo concreto, es. riassumere gli appunti dell'ultima settimana sul progetto X].
Usa il server MCP [nome] per leggere [dati specifici].
Fammi vedere cosa hai trovato prima di elaborare il riassunto.

Il “fammi vedere prima” è importante: ti dà la possibilità di fermare tutto se l’agente sta leggendo la cartella sbagliata o ha capito male.

Fallo davvero

Il primo server della “una cosa da fare” qui sopra si monta in dieci minuti, e il corso ti dà la configurazione già scritta: mcp-filesystem.json. Sono nove righe che dicono al tuo strumento di lanciare il server filesystem ufficiale del progetto MCP, esponendo una sola cartella a tua scelta.

I passi. Primo: scegli la cartella, per esempio quella degli appunti di un progetto, e metti il suo percorso assoluto nella configurazione al posto del segnaposto. Secondo: incolla il blocco nella configurazione MCP del tuo strumento. In Claude Desktop la voce si chiama Developer nelle impostazioni; in Claude Code basta salvare il file come .mcp.json nella cartella del progetto; anche gli altri client MCP (Cursor, Zed, e la lista cresce) accettano lo stesso blocco mcpServers in posizioni documentate. Terzo: riavvia lo strumento e usa il primo prompt qui sopra, quello che chiede la lista di cinque elementi senza elaborare.

Serve Node installato, perché il server parte con npx alla prima richiesta e si scarica da solo. Nota come la configurazione applichi la lezione del capitolo sui confini: il server vede la cartella indicata nella riga della configurazione e nient’altro, quindi il limite sta scritto in un file che puoi rileggere, non nella buona volontà dell’agente.

Dove andare adesso

Nel prossimo capitolo, Dare memoria e stato: agenti che ricordano, vediamo cosa succede quando l’agente collegato ai tuoi sistemi deve anche ricordare, da una sessione all’altra, cosa ha già fatto. Se invece vuoi capire meglio come funzionano i server esistenti, il registro ufficiale MCP di Anthropic è il punto di partenza.