I modelli linguistici di grandi dimensioni, chiamati anche LLM (Large Language Models), sono sistemi capaci di comprendere e generare testo. Possono rispondere a domande, riassumere documenti, scrivere codice, analizzare dati e aiutare l’utente in molte attività.

Tuttavia, un modello LLM da solo ha un limite importante: non può accedere automaticamente al computer, ai file, ai software, ai database o ai servizi online dell’utente.

Un modello, preso isolatamente, non “vede” il Desktop, non apre Excel, non consulta un gestionale, non legge il database del magazzino e non invia email. Per fare queste cose ha bisogno di un collegamento controllato con il mondo esterno.

È qui che entra in gioco MCP, cioè Model Context Protocol.

Che cos’è MCP

MCP, Model Context Protocol, è uno standard aperto che permette alle applicazioni basate su modelli LLM di collegarsi a dati, software e strumenti esterni in modo uniforme.

In parole semplici, MCP è una specie di presa universale che consente a un assistente AI di usare strumenti esterni in modo strutturato e controllato.

Senza MCP, ogni applicazione AI dovrebbe essere collegata manualmente a ogni singolo programma: un’integrazione per GitHub, una per il filesystem, una per il database, una per Gmail, una per il gestionale, una per Slack, una per il CRM e così via.

Con MCP, invece, si crea un linguaggio comune. Il modello AI non deve conoscere tutti i dettagli tecnici di ogni programma. Gli basta sapere che esiste uno strumento disponibile, descritto secondo uno schema standard, e che può chiedere di usarlo.

Il problema che MCP risolve

Immaginiamo un assistente AI dentro un programma di lavoro. L’utente scrive:

Analizza il file vendite.csv che ho sul Desktop e dimmi quali prodotti hanno venduto di più.

Il modello LLM capisce la richiesta, ma ha un problema: non può aprire da solo il file sul Desktop.

Per farlo servono vari passaggi: sapere dove si trova il file, avere il permesso di leggerlo, aprirlo correttamente, estrarne il contenuto, passare il contenuto al modello e permettere al modello di analizzarlo.

MCP serve proprio a organizzare questo dialogo tra modello AI, applicazione AI, strumento esterno e sistema reale.

Modello AI
↓
Applicazione AI
↓
Strumento esterno
↓
File, software, database o servizio reale

L’analogia del cameriere

Per capire MCP, immaginiamo un ristorante.

Il cliente si siede al tavolo e dice:

Vorrei una pizza margherita.

Il cliente non entra in cucina. Non accende il forno. Non prende gli ingredienti. Non prepara la pizza.

Il cliente parla con il cameriere. Il cameriere capisce l’ordine, lo passa alla cucina, la cucina prepara il piatto e il cameriere lo porta al tavolo.

Nel mondo MCP funziona in modo simile:

Utente = cliente al tavolo
Modello LLM = cameriere intelligente
Client MCP = sistema che trasmette l’ordine
Server MCP = cucina specializzata
Software, file o database = ingredienti e strumenti della cucina

Quando l’utente chiede:

Leggi questo file e riassumilo.

il modello non legge direttamente il file. Il modello chiede al sistema collegato tramite MCP di leggerlo. Il server MCP autorizzato apre il file, estrae il contenuto e lo restituisce al modello. A quel punto il modello può fare il riassunto.

Il modello è bravo a capire e spiegare. Il server MCP è bravo ad accedere allo strumento reale.

Client MCP e server MCP

Per capire bene MCP bisogna distinguere due concetti fondamentali:

• client MCP
• server MCP

Che cos’è il client MCP

Il client MCP è la parte dell’applicazione AI che fa le richieste.

Può trovarsi dentro una chat AI, un IDE per programmatori, un assistente desktop, un’applicazione aziendale, un sistema di automazione o un’interfaccia collegata a un modello LLM.

Il client MCP è come il cameriere che porta l’ordine alla cucina. Non esegue necessariamente il lavoro finale, ma sa come parlare con il server MCP.

Che cos’è il server MCP

Il server MCP è il programma che espone strumenti, dati o funzioni al modello AI.

Attenzione: qui la parola “server” non significa per forza un computer remoto su Internet. In informatica, “server” può voler dire anche semplicemente:

un programma che riceve richieste e restituisce risposte.

Quindi un server MCP può essere un piccolo programma che gira sul tuo PC, un servizio cloud, un processo dentro un container Docker, un programma Node.js o Python, un componente aziendale collegato a un gestionale oppure un servizio remoto accessibile via Internet.

Per esempio:

• un server MCP filesystem sa leggere file e cartelle autorizzate;
• un server MCP GitHub sa parlare con GitHub;
• un server MCP database sa interrogare un database;
• un server MCP gestionale sa comunicare con il gestionale aziendale.

Il server MCP è come la cucina: sa fare concretamente una certa cosa.

Schema generale di funzionamento

Il funzionamento base è questo:

Utente
↓
Applicazione AI
↓
Modello LLM
↓
Client MCP
↓
Server MCP
↓
File, database, API, software o servizio esterno

Poi il risultato torna indietro:

Strumento esterno
↓
Server MCP
↓
Client MCP
↓
Modello LLM
↓
Risposta all’utente

Il modello non tocca direttamente il sistema esterno. Il modello chiede al client di usare uno strumento. Il client comunica con il server MCP. Il server MCP esegue l’operazione reale. Il risultato torna al modello.

Cosa espone un server MCP

Un server MCP può esporre tre tipi principali di capacità:

• tools, cioè strumenti che eseguono azioni;
• resources, cioè dati leggibili dal modello;
• prompts, cioè modelli di istruzioni riutilizzabili.

Tools: gli strumenti che eseguono azioni

I tools sono funzioni che il modello può chiedere di usare.

Esempi di tools sono:

read_file
list_directory
search_orders
check_stock
query_database
create_ticket
send_email
get_customer_history

Un tool è un’azione. Per esempio, un server MCP per il magazzino potrebbe esporre il tool check_stock, cioè “controlla la disponibilità di un prodotto”.

Il modello non deve sapere come funziona il database del magazzino. Gli basta sapere che esiste uno strumento chiamato check_stock, che accetta un codice prodotto e restituisce la disponibilità.

Esempio di descrizione di un tool:

{
  "name": "check_stock",
  "description": "Controlla la disponibilità di un prodotto dato il codice SKU",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sku": {
        "type": "string",
        "description": "Codice prodotto"
      }
    },
    "required": ["sku"]
  }
}

Quando l’utente chiede:

Quante paia della scarpa ABC123 ho disponibili?

il modello può chiamare il tool così:

{
  "name": "check_stock",
  "arguments": {
    "sku": "ABC123"
  }
}

Il server MCP riceve la richiesta, interroga il gestionale o il database e restituisce un risultato:

{
  "sku": "ABC123",
  "available_quantity": 7,
  "reserved_quantity": 2,
  "sellable_quantity": 5
}

Il modello poi risponde in linguaggio naturale:

Risultano 7 paia in magazzino, di cui 2 già riservate. Quindi ne puoi vendere 5.

Resources: dati leggibili dal modello

Le resources sono dati che il server MCP può mettere a disposizione come contesto.

Esempi:

file://policy-resi
db://schema-clienti
catalog://prodotti
manuale://procedura-cassa

Una resource non è necessariamente un’azione. È più spesso un contenuto leggibile.

Esempio:

{
  "uri": "file://policy-resi",
  "name": "Policy resi",
  "description": "Regole aziendali per resi e rimborsi",
  "mimeType": "text/plain"
}

Se il modello deve rispondere a un cliente che chiede un rimborso, può usare questa resource per leggere la policy aziendale sui resi.

Prompts: modelli di istruzioni riutilizzabili

I prompts sono template predefiniti che un server MCP può offrire al client.

Per esempio:

prepara_risposta_cliente
analizza_reclamo
genera_report_vendite
spiega_errore_tecnico

Un prompt MCP può contenere istruzioni già strutturate.

{
  "name": "prepara_risposta_cliente",
  "description": "Crea una risposta cortese a un cliente",
  "arguments": [
    {
      "name": "problema",
      "description": "Il problema segnalato dal cliente",
      "required": true
    }
  ]
}

Se l’utente chiede:

Prepara una risposta per un cliente il cui pacco è in ritardo.

il client può recuperare il prompt prepara_risposta_cliente, passargli il problema e ottenere una traccia pronta da far usare al modello.

Com’è fatto il linguaggio comune MCP

MCP non è un linguaggio di programmazione come Python o JavaScript. È un protocollo di comunicazione.

Tecnicamente, MCP usa messaggi basati su JSON-RPC. Un messaggio MCP può assomigliare a questo:

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

Questo messaggio significa:

Dammi la lista degli strumenti disponibili.

Il server può rispondere così:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "read_file",
        "description": "Legge il contenuto di un file autorizzato",
        "inputSchema": {
          "type": "object",
          "properties": {
            "path": {
              "type": "string"
            }
          },
          "required": ["path"]
        }
      }
    ]
  }
}

Il server sta dicendo:

Io offro un tool chiamato read_file. Per usarlo devi passarmi un parametro path, cioè il percorso del file.

Quando il modello vuole leggere un file, il client può inviare:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": {
      "path": "/Users/mario/Desktop/contratto.txt"
    }
  }
}

Il server legge il file, se è autorizzato, e restituisce il contenuto:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Contratto di fornitura tra..."
      }
    ]
  }
}

Il modello riceve quel testo e può finalmente analizzarlo.

Esempio pratico: lettura di un file locale

Supponiamo che l’utente chieda:

Analizza il file vendite.csv che ho sul Desktop.

Il server MCP filesystem è stato configurato per accedere solo al Desktop.

Utente:
"Analizza vendite.csv"

Modello LLM:
"Mi serve leggere il file"

Client MCP:
chiama il tool read_file

Server MCP filesystem:
controlla se il file è in una cartella autorizzata

Filesystem locale:
restituisce il contenuto del file

Server MCP:
manda il contenuto al client

Modello LLM:
analizza i dati

Risposta:
"Il prodotto più venduto è..."

Esempio di contenuto del file:

prodotto,quantita,prezzo
Scarpa A,10,79.90
Scarpa B,4,99.00
Scarpa C,15,59.90

Il modello potrebbe rispondere:

Il prodotto più venduto è Scarpa C con 15 unità, seguito da Scarpa A con 10 unità e Scarpa B con 4 unità.

Qui bisogna notare una distinzione fondamentale:

Il server MCP legge il file.
Il modello LLM interpreta il contenuto.

Il modello può leggere tutto il computer?

No, almeno non dovrebbe.

Un server MCP ben configurato lavora con permessi limitati. Per esempio, si può autorizzare solo questa cartella:

/Users/mario/Desktop/documenti-da-analizzare

In questo caso, se il modello prova a leggere:

/Users/mario/password.txt

il server dovrebbe rifiutare la richiesta.

Questo è un punto molto importante: MCP non significa “l’AI ha accesso libero a tutto”. Significa invece che l’AI può usare strumenti esterni attraverso server controllati e autorizzati.

Un buon server MCP dovrebbe:

• limitare le cartelle accessibili;
• controllare i permessi;
• impedire accessi non autorizzati;
• evitare operazioni pericolose senza conferma;
• registrare le operazioni importanti;
• distinguere tra strumenti di sola lettura e strumenti che modificano dati.

Esempio pratico: interrogare un gestionale

Immaginiamo un negozio con un gestionale che contiene prodotti, ordini e disponibilità.

L’utente chiede:

Controlla se l’ordine 12345 è stato spedito.

Il modello LLM non conosce direttamente il gestionale. Però esiste un server MCP aziendale che espone un tool:

get_order_status

Il tool è descritto così:

{
  "name": "get_order_status",
  "description": "Restituisce lo stato di un ordine",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string"
      }
    },
    "required": ["order_id"]
  }
}

Il modello chiama:

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "12345"
  }
}

Il server MCP interroga il gestionale e restituisce:

{
  "order_id": "12345",
  "status": "spedito",
  "tracking": "1Z999AA10123456784",
  "carrier": "UPS"
}

Il modello risponde:

L’ordine 12345 risulta spedito con UPS. Il codice tracking è 1Z999AA10123456784.

Il punto chiave è che il modello non deve sapere come si interroga il gestionale. Lo sa il server MCP.

MCP come driver degli strumenti

Un’altra analogia utile è quella del driver della stampante.

Quando stampiamo un documento, il programma non deve conoscere tutti i dettagli tecnici della stampante. Non deve sapere esattamente come muovere il carrello, scaldare il toner o alimentare la carta.

Il programma manda una richiesta standard. Il driver traduce quella richiesta nel linguaggio specifico della stampante.

Con MCP succede qualcosa di simile:

Modello LLM = programma che vuole fare qualcosa
MCP = standard di comunicazione
Server MCP = driver o adattatore
Software esterno = dispositivo o sistema reale

Se il modello vuole leggere un file, il server filesystem sa come farlo. Se il modello vuole interrogare GitHub, il server GitHub sa come chiamare le API di GitHub. Se il modello vuole controllare un ordine, il server del gestionale sa come interrogare il database o l’API del gestionale.

MCP non sostituisce le API

MCP non elimina le API tradizionali. Spesso un server MCP usa proprio le API dietro le quinte.

Modello LLM
↓ MCP
Server MCP GitHub
↓ API GitHub
GitHub

Oppure:

Modello LLM
↓ MCP
Server MCP gestionale
↓ API del gestionale
Gestionale

Oppure:

Modello LLM
↓ MCP
Server MCP database
↓ SQL
Database

MCP standardizza il dialogo tra l’app AI e il server MCP. Poi il server MCP può parlare con il mondo esterno usando API, SQL, filesystem, comandi locali o altri protocolli.

MCP e function calling: qual è la differenza?

Molti modelli moderni supportano il cosiddetto function calling, cioè la possibilità di chiamare funzioni definite dallo sviluppatore.

MCP è collegato a questa idea, ma è più ampio.

Con il function calling tradizionale, spesso lo sviluppatore definisce funzioni dentro una specifica applicazione.

Con MCP, invece, uno o più server esterni possono dichiarare dinamicamente quali strumenti offrono.

Function calling:
il modello chiama funzioni definite nell’app.

MCP:
il modello può scoprire e usare strumenti esposti da server MCP standardizzati.

MCP rende più facile riutilizzare lo stesso server con più client o applicazioni AI compatibili.

Come si attiva MCP?

Non esiste un pulsante universale chiamato “attiva MCP”.

MCP si usa configurando un client compatibile e collegandolo a uno o più server MCP.

A seconda dell’ambiente, può avvenire in modi diversi:

• tramite un file di configurazione;
• tramite impostazioni dell’app;
• tramite estensioni;
• tramite API;
• tramite un server remoto;
• tramite un server locale avviato sul computer.

Esempio concettuale di configurazione di un server filesystem:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/mario/Desktop/documenti-da-analizzare"
      ]
    }
  }
}

Questa configurazione significa:

Avvia un server MCP filesystem e permettigli di accedere solo alla cartella indicata.

Se invece si lavora con un server remoto, la configurazione può indicare un URL:

{
  "type": "mcp",
  "server_label": "catalogo-prodotti",
  "server_url": "https://azienda.it/mcp"
}

Cosa succede all’avvio

Quando un client MCP si collega a un server MCP, avviene una fase iniziale chiamata inizializzazione.

In questa fase il client e il server si presentano:

Client:
"Ciao, parlo questa versione del protocollo MCP. Tu cosa sai fare?"

Server:
"Ciao, io offro questi tools, queste resources e questi prompts."

Dopo questa fase, il modello può vedere quali strumenti sono disponibili e decidere quando usarli.

Un esempio completo: dal linguaggio naturale all’azione

Vediamo il flusso completo.

L’utente scrive:

Cerca nel file clienti.csv i clienti che hanno speso più di 500 euro.

Il modello capisce che deve leggere un file. Il client MCP chiama il server filesystem:

{
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": {
      "path": "/Users/mario/Desktop/clienti.csv"
    }
  }
}

Il server controlla:

• il file è dentro una cartella autorizzata?
• il file esiste?
• il file è leggibile?
• la dimensione è gestibile?

Se tutto va bene, legge il file e restituisce:

nome,email,totale_speso
Mario Rossi,mario@example.com,720
Luigi Verdi,luigi@example.com,320
Anna Bianchi,anna@example.com,580

Il modello analizza il contenuto e risponde:

I clienti che hanno speso più di 500 euro sono Mario Rossi, con 720 euro, e Anna Bianchi, con 580 euro.

In questo esempio, ogni componente ha fatto il suo lavoro:

Utente:
ha espresso una richiesta in linguaggio naturale.

Modello LLM:
ha capito cosa serviva fare.

Client MCP:
ha mandato la richiesta al server giusto.

Server MCP:
ha letto il file autorizzato.

Modello LLM:
ha analizzato i dati e formulato la risposta.

Perché MCP è importante per gli agenti AI

Gli agenti AI non sono utili solo perché “parlano bene”. Diventano davvero potenti quando possono usare strumenti.

Un agente AI collegato tramite MCP può, per esempio:

• leggere documenti;
• cercare file;
• interrogare database;
• consultare un catalogo prodotti;
• controllare ordini;
• aprire ticket;
• leggere issue su GitHub;
• recuperare informazioni da un CRM;
• lanciare workflow;
• usare strumenti di sviluppo;
• connettersi a servizi aziendali.

Questo permette di passare da una semplice chat a un assistente operativo.

Non solo:

Spiegami come fare questa cosa.

ma anche:

Controlla i dati, usa gli strumenti corretti e prepara il risultato.

I limiti e i rischi

MCP è potente, ma proprio per questo richiede attenzione.

Se un assistente AI può leggere file, interrogare database o inviare comandi, bisogna progettare bene i permessi.

Alcune buone regole sono:

• concedere accesso solo alle cartelle necessarie;
• usare server MCP affidabili;
• evitare accesso completo al disco;
• distinguere strumenti di lettura da strumenti di scrittura;
• richiedere conferma per azioni delicate;
• non dare token o password senza controllo;
• registrare le operazioni importanti;
• isolare strumenti rischiosi;
• controllare quali tool sono disponibili al modello.

Per esempio, un tool che legge un file è meno pericoloso di un tool che cancella file. Un tool che consulta ordini è meno rischioso di un tool che rimborsa automaticamente clienti.

Un buon sistema MCP deve quindi rispettare il principio del minimo privilegio: dare al modello solo ciò che serve, niente di più.

MCP in una frase

MCP è uno standard che permette ai modelli LLM di comunicare con software, file, database e strumenti esterni attraverso un sistema client-server controllato.

Ancora più semplice:

MCP è il ponte tra l’intelligenza linguistica del modello e le azioni concrete che devono essere svolte su computer, software e servizi reali.

Il modello capisce la richiesta. Il client MCP la trasmette. Il server MCP esegue o recupera dati. Il modello usa il risultato per rispondere.

Conclusione

I modelli LLM sono molto bravi a comprendere il linguaggio, ragionare su testi, spiegare concetti e generare risposte. Tuttavia, per lavorare davvero con il mondo reale hanno bisogno di collegamenti sicuri e standardizzati a strumenti esterni.

Il Model Context Protocol nasce per questo: fornire un modo comune per collegare applicazioni AI a file, software, database, API e sistemi aziendali.

La cosa fondamentale da ricordare è questa:

Il modello non usa direttamente il computer.
Il modello chiede al client MCP.
Il client parla con il server MCP.
Il server MCP accede allo strumento reale.
Il risultato torna al modello.

Come nel ristorante:

Il cliente non entra in cucina.
Il cameriere prende l’ordine.
La cucina prepara.
Il cameriere porta il risultato.

Allo stesso modo, con MCP:

L’utente chiede.
Il modello capisce.
Il client trasmette.
Il server esegue.
Il modello spiega.

È questo meccanismo a rendere possibile una nuova generazione di assistenti AI capaci non solo di conversare, ma anche di interagire con strumenti reali in modo strutturato, riutilizzabile e controllato.