MCP spiegato: la porta USB degli agenti

Chi ha provato a collegare un assistente AI ai propri dati conosce la fatica: un pezzo di codice per parlare con Google Drive, un altro per GitHub, un altro ancora per il gestionale aziendale, ciascuno con la sua autenticazione, il suo formato, le sue bizzarrie. E ogni volta che cambiava l’assistente, bisognava riscrivere tutto da capo. Nel novembre 2024 Anthropic ha proposto una via d’uscita: il Model Context Protocol, MCP, un modo standard perché qualunque applicazione AI parli con qualunque fonte di dati. La documentazione stessa lo paragona a una porta USB, e per una volta l’analogia non è pubblicità: coglie con precisione il problema che il protocollo affronta.

Il problema: M per N integrazioni

Un assistente diventa davvero utile quando può toccare le vostre cose: leggere i documenti, interrogare il database, cercare nei ticket di supporto, guardare il calendario. Prima di MCP ogni collegamento era un lavoro artigianale, cucito su misura per quella specifica coppia applicazione-servizio.

Il conto si fa in fretta. Se avete M applicazioni che vogliono parlare con N servizi, servono M×N integrazioni, ognuna da scrivere e mantenere: dieci app e venti servizi fanno duecento connettori. Un protocollo comune trasforma la moltiplicazione in una somma. Ogni applicazione impara a parlare MCP una volta sola; ogni servizio espone un server MCP una volta sola; e tutte le combinazioni funzionano. M+N invece di M×N. È lo stesso motivo per cui oggi non esiste più un caricabatterie diverso per ogni marca di telefono: ci si è accordati su una presa.

Tre ruoli: host, client, server

L’architettura ha tre ruoli, e la terminologia inganna, perché qui «server» non è una macchina in un datacenter.

• L’host è l’applicazione AI che usate: l’app di chat, l’editor di codice, l’agente. Contiene il modello ed è chi comanda.
• Il client vive dentro l’host e gestisce una singola connessione: uno per ogni server collegato. È la presa a muro.
• Il server è un programma — spesso piccolo, spesso in esecuzione sulla vostra stessa macchina — che espone qualcosa: l’accesso a una cartella, a un database, a un servizio web. È la spina del dispositivo.

Fra client e server viaggiano messaggi in un formato fisso, JSON-RPC: nessuna delle due parti deve conoscere i dettagli interni dell’altra, basta che rispettino il protocollo. Come per l’USB, la mouse non sa nulla del computer e viceversa: entrambi sanno parlare lo stesso standard, e tanto basta.

L’host contiene il modello e un client per ogni connessione; ogni server espone tool e resource verso una fonte di dati. Il protocollo nel mezzo è sempre lo stesso.

Cosa espone un server: tool, resource, prompt

Un server MCP dichiara le proprie capacità in tre categorie. I tool sono azioni che il modello può chiedere di eseguire — cerca, scrivi, invia — ed è il modello a decidere quando invocarle. Le resource sono contenuti che l’applicazione può leggere e passare al modello come contesto: file, record, documenti; qui a governare è l’host, non il modello. I prompt sono modelli di richiesta pronti che il server suggerisce all’utente per i casi d’uso frequenti.

La distinzione tra chi comanda cosa non è pedanteria: è una scelta di sicurezza. I tool li scatena il modello, che è la parte imprevedibile del sistema; le resource le controlla il codice dell’applicazione, che è la parte di cui vi fidate. Tenere separate le due cose serve proprio a non lasciare che il pezzo imprevedibile decida da solo cosa leggere e cosa fare.

Un giro completo, dalla domanda all’azione

Seguiamo una richiesta banale: «quanti ordini sono arrivati ieri?». L’host prepara il prompt per il modello includendo l’elenco degli strumenti disponibili, tra cui — poniamo — query_database, esposto da un server MCP collegato al gestionale. Il modello legge la domanda e le descrizioni, capisce che serve quello strumento e produce una richiesta strutturata con la query. Il client la inoltra al server, il server la esegue sul database vero, il risultato torna indietro lungo la stessa catena e finisce nel contesto del modello, che ora può rispondere col numero.

Notate cosa non è accaduto: il modello non ha mai toccato il database, e chi fornisce il modello non ha dovuto sapere nulla del vostro gestionale. Il server fa da dogana — riceve richieste in formato standard, le traduce nel dialetto del sistema che protegge, decide cosa lasciar passare. È chi scrive il server a fissare i confini: uno fatto bene, per un database, espone solo letture, mai cancellazioni.

La porta è aperta in due sensi

Standardizzare l’accesso significa anche standardizzare la superficie d’attacco. Un server MCP installato da una fonte non verificata è codice che gira sulla vostra macchina con i permessi che gli concedete — come qualunque programma, ma con un’aggravante: le descrizioni dei suoi tool entrano nel contesto del modello, e descrizioni scritte ad arte possono provare a manipolarne il comportamento. È il problema noto come prompt injection, e i tool ne sono un veicolo comodo.

La comodità di collegare tutto a tutto è anche il rischio di collegare tutto a tutto: la fiducia che prima si valutava su ogni integrazione ora va valutata su ogni server.

La combinazione più insidiosa è nota: un agente che legge contenuti non fidati (email, pagine web), ha accesso a dati privati e può comunicare verso l’esterno. Con queste tre capacità insieme, un testo malevolo letto dall’agente può tentare di far uscire i dati. Non è un difetto di MCP in particolare — è un rischio strutturale di ogni agente con strumenti — ma MCP, riducendo la fatica di collegare le cose, rende più facile arrivare a quella combinazione senza rendersene conto. Le contromisure sono le solite: server da fonti fidate, permessi minimi, conferma umana sulle azioni che scrivono o inviano.

Perché vi riguarda

MCP è stato adottato in fretta, anche da chi con Anthropic è in concorrenza diretta: nel corso del 2025 il supporto è comparso nelle piattaforme dei principali fornitori di modelli e in molti strumenti di sviluppo. Quando un protocollo viene abbracciato dai rivali, di solito vuol dire che il problema lo sentivano tutti. Per chi sviluppa, la conseguenza è pratica: esporre i propri dati a un assistente non richiede più di aspettare che qualcuno scriva l’integrazione giusta — si scrive un server MCP, spesso poche centinaia di righe, e funziona con tutti gli host compatibili. Per chi questi strumenti li usa e basta, la conseguenza è di consapevolezza: quando la vostra app AI vi propone di «collegare» il calendario o i documenti, adesso sapete cosa c’è sotto — un client, un server, un elenco di tool — e quali domande porre: chi ha scritto questo server? cosa può fare, oltre a ciò che promette? La porta USB degli agenti è comoda esattamente come quella vera. E come quella vera, conviene guardare cosa ci si infila dentro.