MCP spiegato semplice: il Model Context Protocol
Immagina di aver costruito tre agenti AI: uno che legge le email, uno che interroga il tuo database e uno che cerca file su Google Drive. Ognuno funziona. Poi arriva un collega e ti chiede di collegare tutti e tre allo stesso assistente, più altri cinque servizi. È qui che scopri il vero costo nascosto degli agenti: ogni strumento è collegato a mano, con codice diverso, formati diversi, autenticazioni diverse. Con tre modelli e dieci strumenti ti ritrovi a scrivere e mantenere trenta integrazioni, ognuna fragile a modo suo. Questo è il problema che il Model Context Protocol (MCP) è nato per risolvere.
Se hai già capito cos'è un agente e come funziona il tool use, MCP è il passo successivo naturale: non un concetto nuovo, ma uno standard che rende quel meccanismo riutilizzabile. Questo articolo te lo spiega da zero, senza dare per scontato che tu sappia cosa sia un protocollo.
Il problema: N modelli per M strumenti
Torniamo al collega. Senza uno standard, collegare i modelli agli strumenti è un problema di moltiplicazione. Ogni volta che aggiungi un modello devi reintegrare tutti gli strumenti; ogni volta che aggiungi uno strumento devi ricollegarlo a tutti i modelli. Cresce come N × M: è il classico incubo dell'integrazione, quello che l'informatica ha già incontrato mille volte, dai driver delle stampanti ai caricabatterie dei telefoni.
La soluzione, storicamente, è sempre la stessa: mettersi d'accordo su un linguaggio comune. Se lo strumento parla quel linguaggio e il modello parla quel linguaggio, non serve più un adattatore su misura per ogni coppia. Costruisci lo strumento una volta e qualsiasi assistente compatibile può usarlo; costruisci l'assistente una volta e può usare qualsiasi strumento compatibile. La moltiplicazione N × M diventa una somma N + M. MCP è esattamente questo accordo, applicato al collegamento tra LLM e il mondo esterno.
L'analogia: la USB-C dell'AI
L'immagine più usata, e la più azzeccata, è quella della porta USB-C. Prima dello standard, ogni dispositivo aveva il suo connettore: un cavo per il telefono, uno per la fotocamera, uno per l'hard disk. La USB-C ha imposto un'unica porta: adesso lo stesso cavo carica il portatile, collega il monitor e trasferisce i file. Non perché tutti i dispositivi siano uguali, ma perché tutti hanno accettato la stessa forma di presa.
MCP è la porta USB-C tra un modello di linguaggio e tutto ciò che sta fuori da lui: i tuoi file, un database, un'API di terze parti, il gestionale aziendale. Il modello non ha bisogno di sapere come è fatto ciascun servizio; deve solo sapere che parla MCP. E chi costruisce il servizio non deve sapere quale modello lo userà: gli basta esporre una presa MCP. È uno standard aperto — chiunque può implementarlo, non è proprietà di una singola azienda — e questo è il motivo per cui in poco più di un anno è diventato il modo di fatto in cui gli agenti si collegano agli strumenti.
Come è fatto: host, client e server
MCP definisce tre ruoli. Vale la pena tenerli distinti, perché i nomi si assomigliano.
Il server MCP è il pezzo che espone una capacità: "so leggere i file di questa cartella", "so cercare nel tuo Google Drive", "so eseguire query su questo database". Chi possiede un servizio scrive un server MCP una volta, e da quel momento è disponibile a chiunque.
Il client MCP è il componente che parla con un server. Di solito non lo scrivi tu: è già dentro l'applicazione che usi.
L'host è l'applicazione che l'utente vede — l'assistente, l'editor di codice, il chatbot aziendale — e che contiene uno o più client, uno per ogni server a cui vuole collegarsi. Quando l'host si connette a tre server (file, database, email), apre tre client, uno per ciascuno.
La dinamica è quella che già conosci dagli agenti: l'host chiede al server quali strumenti mette a disposizione, il modello decide quali usare, il server li esegue e restituisce il risultato. MCP standardizza semplicemente il formato di questa conversazione, così che host e server scritti da persone diverse si capiscano al primo colpo.
Non solo strumenti: risorse e prompt
Un server MCP può offrire tre tipi di cose, ed è utile conoscerli perché coprono bisogni diversi:
- I tool sono azioni che il modello può eseguire: cerca, scrivi, invia, calcola. Sono l'equivalente diretto del tool use che hai già visto.
- Le risorse sono dati che il modello può leggere: il contenuto di un file, una tabella, una pagina di documentazione. Servono a dargli contesto, non a fargli compiere azioni.
- I prompt sono modelli di istruzione pronti, che l'host può proporre all'utente come scorciatoie ("riassumi questo documento", "trova i bug in questo codice").
Sotto il cofano il tutto viaggia su un formato di messaggi collaudato (JSON-RPC), lo stesso stile di richiesta-e-risposta che regge buona parte del web. Non devi conoscerne i dettagli per usare MCP, ma sapere che c'è uno standard maturo sotto ti dice perché funziona.
Cosa cambia rispetto al tool use fatto a mano
Se hai costruito il tuo primo agente con tool use, ti sarai accorto che lì gli strumenti erano cablati nel codice: definivi tu il "biglietto da visita" di ogni tool e la funzione che lo eseguiva, dentro il tuo programma. Funziona benissimo per imparare e per un agente piccolo e tuo.
MCP sposta quella definizione fuori dalla tua applicazione, dentro un server riutilizzabile. Il vantaggio non è tecnico ma organizzativo: chi mantiene il gestionale scrive e aggiorna il server MCP del gestionale; tu, che costruisci l'assistente, ti limiti a collegarti. Quando il gestionale cambia, aggiorni il server in un posto solo e tutti gli assistenti che lo usano ne beneficiano. È la differenza tra saldare un cavo e infilare una spina.
La novità del 2026: lo standard diventa "adulto"
MCP è nato a fine 2024 pensato soprattutto per un caso semplice: un assistente sul tuo computer che parla con un server sulla stessa macchina. Appena le aziende hanno provato a usarlo su larga scala, in cloud, con migliaia di utenti in parallelo, è emerso un limite: il protocollo teneva una sessione aperta tra client e server, cioè una specie di conversazione telefonica da mantenere viva. In cloud questo è un problema, perché costringe ogni richiesta di un utente a tornare sempre sullo stesso server, complicando bilanciamento del carico e affidabilità.
La revisione dello standard pubblicata a fine luglio 2026 ha risolto proprio questo, rendendo il cuore del protocollo stateless: ogni richiesta ora è autosufficiente, si porta dietro tutto ciò che serve e può essere gestita da un server qualsiasi, esattamente come una normale richiesta web. In pratica gli agenti diventano più facili da far scalare, più economici da ospitare (i server possono spegnersi quando nessuno li usa) e più robusti quando qualcosa va storto. Non serve che tu conosca i dettagli: la cosa da portarti a casa è che MCP sta passando da "esperimento promettente" a infrastruttura di produzione, ed è per questo che vale la pena impararlo adesso.
Quando MCP serve (e quando è troppo)
Come per gli agenti, la regola è partire semplici. MCP dà il meglio quando gli stessi strumenti servono a più assistenti, o quando vuoi collegare il tuo agente a servizi esterni che espongono già un server MCP pronto — e ce ne sono ormai molti, dai sistemi di controllo versione ai database ai gestionali. In quei casi risparmi mesi di integrazioni fatte a mano.
Se invece stai scrivendo un piccolo script con un solo strumento tutto tuo, montare un server MCP è un'inutile complicazione: il tool use diretto che hai già imparato è la scelta giusta. Lo standard nasce per risolvere il problema della moltiplicazione N × M; se nel tuo caso N e M valgono entrambi uno, non hai quel problema. MCP è una presa universale: preziosa quando devi collegare tante cose, sovradimensionata quando ne colleghi una sola.
Prova subito
Non serve scrivere codice per capire MCP dal di dentro: probabilmente hai già un host pronto all'uso. In tre mosse:
- Collega un server esistente. Molti assistenti e editor di codice permettono di aggiungere un server MCP con poche righe di configurazione. Parti da uno semplice e ufficiale — per esempio quello che dà accesso a una cartella di file — e collegalo al tuo host preferito.
- Guarda la lista degli strumenti. Una volta connesso, chiedi all'assistente cosa può fare adesso che prima non poteva. Vedrai comparire i tool esposti dal server: è la prova concreta che lo standard funziona, senza che tu abbia scritto una riga di integrazione.
- Aggiungine un secondo. Collega un secondo server, diverso dal primo, e fai una domanda che li usi entrambi. Osserva l'host scegliere lo strumento giusto dal server giusto: è la somma
N + Mche sostituisce la moltiplicazione, davanti ai tuoi occhi.
Quando avrai collegato due server senza scrivere codice di integrazione, avrai capito il senso profondo di MCP: non una tecnologia in più da imparare, ma un accordo che fa sparire il lavoro noioso: quello di far parlare tra loro cose costruite da persone diverse.