Model Context Protocol: cos’è e a cosa serve
Cos'è il Model Context Protocol (MCP): lo standard aperto che collega i modelli AI a file, database e API. Guida pratica con esempi e Claude Code.

Un assistente AI, da solo, sa solo conversare. Non legge i tuoi file, non interroga il database aziendale, non apre una issue su GitHub. Per fargli fare queste cose serviva, fino a poco fa, scrivere un’integrazione su misura per ogni strumento. Il Model Context Protocol (MCP) risolve esattamente questo: è uno standard aperto che collega i modelli AI a dati e strumenti esterni con un unico linguaggio comune, invece di mille connettori diversi.
In questa guida spiego cos’è MCP, il problema che affronta, com’è fatto dentro e come lo si usa in pratica con Claude Code e Claude Desktop.
Cos’è il Model Context Protocol
Il Model Context Protocol è uno standard aperto per collegare le applicazioni AI ai sistemi dove vivono i dati: file locali, database, motori di ricerca, strumenti aziendali, flussi di lavoro. La definizione ufficiale è netta: MCP serve a far accedere il modello alle informazioni che gli servono e a fargli compiere azioni nel mondo esterno.
L’analogia che usa la documentazione è la presa USB-C. Prima esisteva un cavo diverso per ogni dispositivo; con uno standard unico, colleghi tutto allo stesso modo. MCP fa lo stesso per l’AI: chi costruisce uno strumento lo espone una volta secondo il protocollo, e qualunque applicazione compatibile può usarlo. Costruisci una volta, integri ovunque.
Il problema che risolve
Prima di MCP, ogni collegamento tra un modello e una fonte dati era un lavoro a sé. Volevi far leggere a Claude le tue issue di Jira? Codice dedicato. Lo stesso per Postgres, per Slack, per il filesystem. Il risultato era una matrice di integrazioni che cresceva in fretta e si rompeva a ogni cambiamento.
Lo standard ribalta l’approccio. C’è un protocollo solo, e due ruoli: chi possiede dati o strumenti li espone tramite un server MCP; chi costruisce l’applicazione AI la rende un client MCP capace di parlare con qualunque server. Da quel momento i due lati si trovano senza accordi su misura: un server scritto per Claude funziona anche con un altro client compatibile, perché parlano la stessa lingua.
L’architettura essenziale: host, client, server
MCP segue un’architettura client-server con tre attori, definiti così nella documentazione ufficiale:
- Host: l’applicazione AI che coordina tutto. Claude Code, Claude Desktop e Visual Studio Code sono host.
- Client: il componente che mantiene la connessione con un server e ne raccoglie il contesto per l’host. L’host crea un client per ogni server a cui si collega, con una connessione dedicata.
- Server: il programma che fornisce contesto e azioni. Può girare in locale sulla tua macchina o da remoto su una piattaforma cloud.
Sotto il cofano ci sono due livelli. Il livello dati definisce il protocollo di scambio, basato su JSON-RPC 2.0, con la gestione del ciclo di vita e le primitive. Il livello di trasporto stabilisce come passano i messaggi: stdio per i server locali (comunicazione diretta tra processi sulla stessa macchina) e Streamable HTTP per i server remoti, con autenticazione via OAuth, token o chiavi API.
Cosa espone un server: le tre primitive
Un server MCP mette a disposizione del client tre tipi di “primitive”. Tenerle distinte aiuta a capire cosa può fare davvero:
- Tools (strumenti): funzioni eseguibili che il modello può invocare per compiere azioni — operazioni su file, chiamate API, query su database.
- Resources (risorse): fonti di dati che forniscono contesto, come il contenuto di un file, righe di una tabella o risposte di un’API.
- Prompts: modelli riutilizzabili che strutturano l’interazione, ad esempio prompt di sistema o esempi few-shot.
Il client scopre cosa offre il server con metodi di tipo tools/list, poi esegue con tools/call. Se i tool cambiano durante la sessione, il server invia una notifica e il client aggiorna l’elenco senza dover ripartire da capo.
Esempi concreti di server MCP
Al lancio Anthropic ha pubblicato server già pronti per sistemi diffusi: Google Drive, Slack, GitHub, Git, Postgres e Puppeteer. Da lì il catalogo è cresciuto. Qualche caso pratico:
- Filesystem: il server di riferimento per leggere e scrivere file locali. Gira in stdio, quindi parte sulla stessa macchina dell’host.
- Database: un server PostgreSQL espone uno strumento per le query e una risorsa con lo schema delle tabelle, così il modello sa com’è fatto il database prima di interrogarlo.
- API e servizi remoti: il server MCP di Sentry, ad esempio, gira sulla piattaforma Sentry come server remoto via HTTP, e permette di chiedere all’AI quali errori sono più frequenti nelle ultime 24 ore.
Lo schema si ripete: un sistema che già esiste viene affacciato dietro un server MCP, e da quel momento è raggiungibile da qualunque assistente compatibile.
Come si usa con Claude Code e Claude Desktop
Qui la teoria diventa pratica. In Claude Code aggiungi un server con un comando. Per un server remoto via HTTP:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
Per un server locale in stdio passi il comando da eseguire dopo il doppio trattino, ad esempio per interrogare un database PostgreSQL:
claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
--dsn "postgresql://readonly:pass@host:5432/analytics"
I comandi di gestione sono altrettanto diretti: claude mcp list elenca i server configurati, claude mcp get <nome> mostra il dettaglio di uno, e /mcp dentro la sessione controlla stato e autenticazione OAuth.
Ogni server può stare a tre livelli di visibilità (scope): local (predefinito, solo per te nel progetto corrente), project (condiviso col team tramite il file .mcp.json nel repository) e user (disponibile in tutti i tuoi progetti). Lo scope project è quello che rende il setup riproducibile: chi clona il progetto trova già gli stessi strumenti.
Claude Desktop funziona allo stesso modo: i server si configurano nel file claude_desktop_config.json, ed esiste un comando per importare in Claude Code i server già impostati nel Desktop. Lo stesso protocollo, due porte d’ingresso.
Perché è uno standard aperto (e perché conta)
MCP nasce open source, ma il punto che gli dà solidità è arrivato dopo. Il 9 dicembre 2025 Anthropic ha donato il protocollo alla Linux Foundation, all’interno della Agentic AI Foundation, una iniziativa co-fondata con Block e OpenAI e sostenuta tra gli altri da Google, Microsoft, AWS, Cloudflare e Bloomberg.
Tradotto: il protocollo non dipende più da una singola azienda. È governato in modo neutrale rispetto ai fornitori, con manutentori che continuano a raccogliere il contributo della comunità. Per chi costruisce strumenti è una garanzia concreta: investire su un server MCP significa appoggiarsi a uno standard condiviso, non a una scommessa su un prodotto. Non a caso lo supportano già assistenti come Claude e ChatGPT e strumenti di sviluppo come Visual Studio Code e Cursor.
Se il tema degli agenti che lavorano con strumenti esterni ti interessa, ho approfondito i meccanismi correlati in altri due articoli: gli agenti AI in parallelo e il fan-out dei subagent e cosa sono le Claude Skills. MCP è il pezzo che collega questi agenti al mondo reale.
In sintesi
Il Model Context Protocol è lo strato che mancava: un modo standard, aperto e governato da una fondazione neutrale per collegare i modelli AI a file, database, API e strumenti. L’architettura è semplice da tenere a mente — un host coordina più client, ognuno parla con un server che espone strumenti, risorse e prompt — e l’uso in Claude Code o Claude Desktop si riduce a un comando di configurazione. Chi sviluppa smette di scrivere integrazioni usa e getta; chi usa l’AI ottiene un assistente che lavora davvero sui propri dati. Costruisci il server una volta, lo colleghi ovunque.

Blogger dal 2001, Nativo Digitale, Developer.
Da 15 anni mi occupo di IT per una grande Azienda.
Lavoro per abbattere il Digital Divide.
Visita i miei altri progetti
sardiniamobility.com
www.cyberness.it