Cos'è il MCP (Model Context Protocol) e come funziona

Ogni assistente IA si scontra con lo stesso limite: conosce molte cose sul mondo fino alla data di cutoff dell'addestramento, ma non sa nulla dei tuoi file, del tuo database o dell'API interna della tua azienda. Il Model Context Protocol (MCP) è nato per colmare esattamente questa lacuna. Da quando Anthropic lo ha rilasciato come standard aperto alla fine del 2024, è diventato, di fatto, una sorta di USB-C per connettere modelli linguistici a strumenti e dati esterni.

Cos'è il MCP

Il Model Context Protocol è un protocollo aperto, basato su JSON-RPC 2.0, che definisce un modo standardizzato per un modello linguistico (o l'applicazione che lo ospita) di connettersi a fonti di dati e strumenti esterni. Invece di far reinventare a ogni assistente IA il proprio modo di leggere un file, interrogare un database o attivare un'automazione, il MCP offre un'interfaccia comune che qualsiasi server può implementare e qualsiasi client può utilizzare.

In pratica, significa che chi costruisce un'integrazione, ad esempio un connettore per GitHub o per Google Drive, fa questo lavoro una sola volta, sotto forma di server MCP. Qualsiasi applicazione compatibile, come Claude Desktop, Claude Code, un IDE o un agente personalizzato, può utilizzare questa integrazione senza scrivere codice specifico per essa. Il protocollo organizza la comunicazione in tre blocchi: tools (azioni che il modello può eseguire), resources (dati che il modello può leggere) e prompts (modelli di istruzione riutilizzabili), tutti descritti in un formato che il modello stesso interpreta in fase di esecuzione.

Il problema che il MCP risolve

Prima del MCP, connettere un LLM a un sistema esterno significava generalmente scrivere un'integrazione su misura: un plugin qui, una function calling personalizzata là, un agente circondato da wrapper API specifici. Ogni applicazione di IA aveva il suo modo di esporre strumenti, e ogni strumento doveva essere adattato per ogni applicazione. Se un'azienda manteneva 5 strumenti interni e voleva che funzionassero su 3 diversi assistenti, il risultato erano 15 integrazioni separate da mantenere, ciascuna con il proprio schema di autenticazione e formato di richiesta.

Questo è il classico problema di "M per N": M strumenti moltiplicati per N applicazioni generano M×N ponti di integrazione. Il MCP appiattisce questa equazione a M+N. Ogni strumento diventa un server MCP, costruito una sola volta; ogni applicazione diventa un client MCP compatibile, anch'esso costruito una sola volta; e qualsiasi combinazione tra i due lati funziona senza lavoro extra. È sostanzialmente lo stesso ragionamento alla base del Language Server Protocol, creato anni prima per evitare che gli editor di codice dovessero implementare supporto nativo per ogni linguaggio di programmazione separatamente.

Architettura del protocollo

Il MCP segue un'architettura client-server con tre ruoli ben definiti:

• Host: l'applicazione che l'utente finale usa direttamente, come Claude Desktop, un IDE con IA integrata o un agente personalizzato.
• Client MCP: un componente all'interno dell'host che mantiene una connessione individuale e isolata con un server MCP specifico.
• Server MCP: un processo separato, locale o remoto, che espone tools, resources e prompts su un sistema esterno.

Uno stesso host può mantenere più client MCP contemporaneamente, ciascuno connesso a un server diverso: uno per il file system, un altro per Slack, un altro per un database Postgres. Questa regola di un client per server è voluta, perché garantisce isolamento. Un guasto o un blocco su un server non interrompe la connessione con gli altri.

Il diagramma seguente riassume questo schema:

La comunicazione tra client e server avviene tramite due trasporti principali. Per server locali, lo standard è stdio, l'input e output standard del processo, semplice e veloce perché non richiede rete. Per server remoti, il trasporto è HTTP con Streamable HTTP, l'evoluzione del vecchio trasporto basato su Server-Sent Events, che consente di ospitare un server MCP nel cloud e servire più client contemporaneamente.

Il client MCP

Il client vive all'interno dell'host e si occupa di tre cose: aprire e mantenere la connessione con un server, tradurre le decisioni del modello in messaggi JSON-RPC, e restituire le risposte del server nel contesto della conversazione. In pratica, il client gestisce anche l'handshake iniziale, la fase di initialize in cui client e server si scambiano informazioni sulla versione del protocollo e le capacità supportate, oltre al processo di discovery, in cui chiede al server quali tools, resources e prompts offre.

Un dettaglio poco ovvio è che il client non decide da solo quando usare uno strumento. Questa decisione spetta al modello: il client fornisce all'LLM l'elenco degli strumenti disponibili, formattato come parte del contesto della conversazione, ed è il modello stesso a scegliere, in base a ciò che l'utente ha richiesto, se e quale strumento chiamare. Il client esegue la chiamata tecnica solo dopo che il modello ha deciso.

Il server MCP

Dall'altro lato, il server è colui che sa realmente interagire con il sistema esterno, sia esso un database, un'API di terze parti o il file system locale. Un server MCP ben costruito espone le proprie capacità in modo autodescrittivo: ogni tool ha un nome, una descrizione in linguaggio naturale e uno schema, generalmente JSON Schema, che definisce quali parametri accetta.

Questa autodescrizione è ciò che rende il MCP componibile. Il server non ha bisogno di sapere quale modello lo utilizzerà, e il client non necessita di codice specifico per quel server oltre a parlare il protocollo. Oggi esistono già centinaia di server MCP pubblicati da aziende come GitHub, Stripe, Cloudflare e Sentry, oltre a un vasto ecosistema di server comunitari per database, strumenti di produttività e servizi interni.

Gli strumenti (tools) del MCP

I tools sono il tipo di capacità più utilizzato nel MCP: azioni che il modello può eseguire e che di solito hanno effetti collaterali o restituiscono un risultato calcolato, come consultare le previsioni del tempo, creare una card in Trello o eseguire una query SQL. Il protocollo definisce altri due tipi di capacità che vale la pena conoscere:

• Resources: dati che il server espone in lettura, come il contenuto di un file, una riga di database o il risultato di una query. A differenza dei tools, i resources di solito non hanno effetti collaterali, sono solo contesto che l'host può allegare alla conversazione.
• Prompts: template di istruzione riutilizzabili che il server mette a disposizione, come uno schema pronto per revisionare una pull request o riassumere un ticket di supporto, che l'utente può invocare direttamente.

Ogni tool è descritto da un oggetto con name, description e inputSchema. È questa descrizione, scritta in linguaggio naturale ma strutturata, che permette al modello di capire cosa fa lo strumento senza che nessuno debba programmare regole esplicite su quando usarlo.

Flusso completo di una chiamata MCP

Per capire come tutto ciò si collega nella pratica, vale la pena seguire il ciclo di vita di una chiamata reale, così come viaggia tra client e server tramite JSON-RPC 2.0.

Prima, nella connessione, il client chiede quali strumenti offre il server:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

Il server risponde con l'elenco completo, includendo già lo schema di ogni strumento:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Restituisce le previsioni del tempo attuali per una città",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Questo catalogo viene fornito al modello come parte del contesto disponibile. Quando l'utente fa una richiesta che il modello interpreta come qualcosa che richiede lo strumento get_weather, il client prepara e invia una chiamata tools/call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "San Paolo" }
  }
}

Il server esegue la logica reale dietro lo strumento, in questo caso probabilmente una chiamata a una vera API meteorologica, e restituisce il risultato nello stesso formato JSON-RPC:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "23°C, cielo sereno a San Paolo" }
    ]
  }
}

Il client inietta questo risultato nella conversazione, e il modello utilizza l'informazione per formulare la risposta finale all'utente. Dal punto di vista di chi sta conversando con l'assistente, tutto ciò avviene in modo trasparente: si vede solo la domanda e la risposta, senza sapere che dietro le quinte c'è stata un'intera negoziazione di protocollo.

MCP vs API tradizionale

Spesso sorge il dubbio: se ogni strumento esterno ha già un'API REST, perché non usare direttamente quella? La risposta sta nella differenza tra integrare un sistema per uno sviluppatore umano che legge la documentazione e integrarlo per un modello che lo scopre e lo utilizza autonomamente, in tempo reale.

Aspetto	API REST tradizionale	MCP
Scoperta delle capacità	Documentazione esterna (Swagger/OpenAPI), letta da un umano	Il client chiede al server in tempo reale quali tools esistono (tools/list)
Integrazione per sistema	Un connettore dedicato per ogni API	Un unico protocollo standard per qualsiasi server MCP
Formato di comunicazione	HTTP + JSON, schema varia per fornitore	JSON-RPC 2.0 standardizzato
Contesto per il modello	Lo sviluppatore decide manualmente cosa esporre all'LLM	Il server descrive i tools in modo che il modello stesso decida cosa usare
Trasporto	Quasi sempre HTTP	stdio (locale) o HTTP con Streamable HTTP (remoto)
Riutilizzo tra app di IA	Basso, ogni app reimplementa l'integrazione	Alto, qualsiasi host compatibile usa lo stesso server

In pratica, il MCP non sostituisce l'API REST dietro il server, ma è un livello di standardizzazione sopra di essa. Un server MCP per GitHub, ad esempio, probabilmente chiama l'API REST di GitHub internamente. La differenza è che il modello non ha mai bisogno di saperlo: vede solo tools con nomi e schemi coerenti, indipendentemente dall'API sottostante.

Esempio pratico: un server MCP semplice

Per passare dalla teoria alla pratica, un server MCP minimo in Python, utilizzando l'SDK ufficiale con la classe FastMCP, si scrive in poche righe:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("clima-server")
@mcp.tool()
def get_weather(city: str) -> str:
    """Restituisce le previsioni del tempo attuali per una città."""
    # qui andrebbe la chiamata reale a un'API meteorologica
    return f"23°C, cielo sereno a {city}"
if name == "main":
    mcp.run(transport="stdio")

Questo server espone un unico tool chiamato get_weather. Il decoratore @mcp.tool() si occupa già di generare lo schema JSON a partire dalla firma della funzione e dal docstring, quindi non è necessario scrivere lo JSON Schema a mano. Eseguendo questo script, rimane in ascolto tramite stdio, pronto per qualsiasi client MCP, come Claude Desktop configurato localmente, per connettersi e scoprire automaticamente lo strumento.

Questo esempio è volutamente semplice, ma lo stesso schema vale per server più complessi: la logica di business (interrogare un database, chiamare un'API a pagamento, attivare un'automazione) va nel corpo della funzione, e l'SDK gestisce tutta la parte di protocollo, handshake e serializzazione.

Sicurezza nel MCP

Dare a un modello linguistico accesso diretto a strumenti che leggono file, scrivono su database o chiamano API di terze parti solleva una domanda ovvia: chi garantisce che tutto rimanga sotto controllo? Il protocollo definisce alcune salvaguardie, ma la responsabilità finale è condivisa tra server, client e chi configura il sistema.

A livello di server, la buona pratica è applicare il principio del minimo privilegio: un server MCP per il file system, ad esempio, dovrebbe limitare l'accesso a directory specifiche, mai all'intero disco. I server remoti che utilizzano il trasporto HTTP richiedono solitamente autenticazione tramite OAuth 2.1, e la specifica del protocollo lo tratta con grande dettaglio, proprio perché i server mal configurati sono il vettore di attacco più ovvio.

A livello di client e host, il livello di sicurezza più visibile per l'utente finale è il consenso umano: host come Claude Desktop chiedono conferma prima di eseguire strumenti sensibili, come scrivere un file o inviare un messaggio, specialmente la prima volta che uno strumento viene utilizzato. Esiste anche il rischio di prompt injection tramite resources, quando un contenuto malevolo incorporato in un documento letto dal modello tenta di manipolare il modello stesso per eseguire un'azione impropria. I server che espongono contenuti da fonti non affidabili, come pagine web o email ricevute, meritano un'attenzione particolare sia da parte di chi costruisce il server sia di chi decide di collegarlo a un agente con ampi permessi.

Limitazioni del MCP

Il MCP risolve il problema della standardizzazione, ma non è una soluzione magica per tutto. Vale la pena conoscere i limiti reali prima di decidere di costruire sopra di esso.

Innanzitutto, il protocollo è ancora relativamente nuovo, rilasciato alla fine del 2024, e l'ecosistema, sebbene cresca rapidamente, presenta ancora lacune: non tutti gli strumenti popolari hanno già un server MCP maturo e mantenuto ufficialmente. In secondo luogo, più strumenti disponibili contemporaneamente significano più token spesi per descrivere questi strumenti nel contesto della conversazione, il che può aumentare i costi delle chiamate e, in casi estremi, competere per lo spazio di contesto con il resto della conversazione. In terzo luogo, il protocollo non risolve da solo il problema dell'affidabilità del modello: può ancora scegliere lo strumento sbagliato, costruire argomenti errati o interpretare male un risultato restituito dal server, quindi l'orchestrazione attenta rimane compito di chi costruisce l'agente.

Infine, l'autenticazione e la governance degli accessi in ambienti aziendali, ovvero chi può connettere quale server, con quali permessi, e come viene auditato, è ancora uno spazio in maturazione, con molto lavoro in corso nella comunità e nelle aziende che adottano il protocollo in produzione.

FAQ

Il MCP è esclusivo di Anthropic e Claude?

No. Il MCP è un protocollo aperto, con specifica pubblica, e altre aziende di IA e framework per agenti hanno già annunciato supporto, sebbene sia nato all'interno di Anthropic.

Devo saper programmare per usare un server MCP?

Per utilizzare un server già pronto, come quello per l'accesso ai file o a Google Drive, all'interno di un'app come Claude Desktop, no. La programmazione è necessaria solo per chi vuole costruire un nuovo server da zero.

Il MCP sostituisce il function calling?

Non esattamente. Il function calling è la capacità del modello di scegliere e formattare una chiamata a uno strumento. Il MCP utilizza questa capacità internamente, ma aggiunge il livello di discovery, standardizzazione e trasporto tra client e server che il function calling da solo non definisce.

Un server MCP può essere eseguito nel cloud?

Sì. I server remoti utilizzano il trasporto HTTP e possono essere ospitati normalmente, servendo più client contemporaneamente, con autenticazione tramite OAuth.

Il vero vantaggio del MCP non è tecnico nel senso di "un'altra API", ma organizzativo: trasforma un problema che cresceva in modo moltiplicativo, ogni strumento per ogni applicazione, in un problema che cresce in modo additivo. Per chi costruisce agenti di IA oggi, comprendere questo protocollo ha smesso di essere facoltativo. È già il pezzo di infrastruttura più vicino a uno standard de facto per connettere i modelli a tutto ciò che esiste al di fuori del modello stesso.