Che cos’è il Model Context Protocol (MCP)? Lo standard che collega l’IA agli strumenti e ai dati

Il Model Context Protocol (MCP) è uno standard aperto che consente alle applicazioni IA di connettersi a strumenti esterni, dati, prompt e altre funzionalità tramite un’interfaccia coerente. Invece di creare un’integrazione personalizzata per ogni combinazione modello‑sistema, gli sviluppatori possono implementare un protocollo condiviso tra un host IA e un server MCP.

Il MCP è spesso descritto come un connettore universale per l’IA, ma l’analogia è incompleta. Il protocollo non si limita a spostare dati. Definisce come i partecipanti stabiliscono capacità, espongono risorse e azioni, scambiano messaggi strutturati e mantengono i confini di sicurezza. Ciò lo rende una parte importante dell’infrastruttura emergente per assistenti e agenti IA.

Perché esiste il MCP

Un modello da solo non può vedere i documenti privati di un’azienda, ispezionare un repository locale, interrogare un database in tempo reale o chiamare un servizio interno. Storicamente gli sviluppatori collegavano tali capacità tramite plugin puntuali e API specifiche per l’applicazione.

Questo approccio genera un problema di integrazione. Se dieci applicazioni IA devono ciascuna connettersi a dieci sistemi, i team potrebbero finire per mantenere decine di adattatori su misura. Ogni adattatore può rappresentare strumenti, contesto, autenticazione, errori e aggiornamenti in modo diverso.

MCP crea un contratto comune. Un’applicazione compatibile con MCP può comunicare con i server MCP che espongono capacità in un formato noto. La specifica del Model Context Protocol definisce il protocollo, mentre gli host e i server individuali decidono quali funzionalità e politiche di sicurezza supportano.

L’architettura MCP

MCP separa la conversazione e la logica del modello dell’applicazione IA dalla logica di integrazione richiesta da ciascuna fonte di dati o servizio. L’host può mantenere più connessioni client contemporaneamente — una per un server di file system, una per un server di database e un’altra per un’applicazione aziendale — presentando le loro capacità al modello tramite un’interfaccia coerente.

Il server non è necessariamente un servizio internet remoto. Può essere eseguito localmente accanto a un’applicazione desktop, all’interno di una rete aziendale o come servizio remoto. Questa scelta di distribuzione modifica il trasporto e il confine di fiducia, ma non la relazione centrale: un client scopre le capacità da un server e scambia messaggi strutturati con esso.

MCP utilizza un’architettura host‑client‑server.

• Host: l’applicazione IA con cui l’utente interagisce, come un assistente, un ambiente di programmazione o una piattaforma di agenti.
• Client: un componente del protocollo creato dall’host per mantenere una connessione con un particolare server MCP.
• Server: un programma che espone strumenti, risorse o prompt selezionati ai client MCP.

Un host può connettersi a più server contemporaneamente. Un server potrebbe fornire accesso a un repository di file, un altro a un sistema di gestione progetti e un terzo a un database interno. L’host rimane responsabile dell’esperienza utente, dell’orchestrazione del modello, del consenso e delle informazioni inserite nel contesto del modello.

I messaggi sono strutturati secondo le convenzioni JSON‑RPC. Durante l’inizializzazione, i partecipanti negoziano versioni del protocollo e capacità. Tale negoziazione è importante perché client e server non devono implementare ogni funzionalità opzionale.

Strumenti, risorse e prompt

MCP organizza le capacità fornite dal server in diversi primitivi. I tre più familiari sono strumenti, risorse e prompt.

Strumenti

Uno strumento è una funzione eseguibile che l’applicazione AI può invocare. Esempi includono la ricerca in un database clienti, la creazione di un ticket, l’esecuzione di una query o il recupero dell’inventario corrente. Una definizione di strumento comprende un nome, una descrizione e uno schema di input affinché il modello e il runtime sappiano quali argomenti sono attesi.

L’uso di uno strumento può modificare sistemi esterni, quindi gli host dovrebbero mostrare descrizioni significative, convalidare gli input, applicare permessi e richiedere conferma per azioni con conseguenze.

Risorse

Una risorsa è un contesto che un’applicazione può leggere, come un file, un record di database, una pagina di documentazione o un report generato. Le risorse usano identificatori e possono esporre metadati come nome e tipo di media. Forniscono agli host un modo standardizzato per scoprire e recuperare informazioni senza far finta che ogni operazione di lettura sia un’azione.

Prompt

I prompt sono modelli riutilizzabili o flussi di lavoro che un server mette a disposizione dell’host. Possono aiutare gli utenti a invocare correttamente una capacità, fornire argomenti strutturati o combinare istruzioni specifiche del dominio con il contesto rilevante.

MCP supporta anche capacità nella direzione opposta. A seconda di quanto negoziato, un server può chiedere all’host di ottenere completamenti del modello o input dell’utente. Il principio di progettazione importante è la negoziazione esplicita delle capacità, anziché presumere che ogni partecipante possa eseguire ogni operazione.

Cosa accade durante una chiamata a uno strumento MCP?

Consideriamo un assistente di codifica AI collegato a un server di analisi del repository.

1. L’host si connette al server MCP e negozia le capacità supportate.
2. Il client richiede l’elenco degli strumenti disponibili.
3. Il server restituisce definizioni strutturate degli strumenti, inclusi i loro schemi di input.
4. L’host rende disponibili le descrizioni degli strumenti selezionati al modello.
5. Il modello propone una chiamata a uno strumento, ad esempio la ricerca di riferimenti a una funzione.
6. L’host verifica la policy e, quando necessario, chiede all’utente l’approvazione.
7. Il client invia la richiesta convalidata al server.
8. Il server esegue l’operazione e restituisce contenuto strutturato o un errore.
9. L’host decide quale parte del risultato fornire al modello per il passo successivo.

MCP standardizza lo scambio, ma non decide se il modello debba essere considerato affidabile per chiamare uno strumento. Tale decisione spetta all’host e al suo livello di policy.

MCP non sostituisce le API

Un server MCP spesso avvolge API esistenti, kit di sviluppo software, strumenti da riga di comando o driver di database. Quelle interfacce sottostanti continuano a svolgere il lavoro reale. MCP aggiunge uno strato di scoperta e interazione orientato all’AI sopra di esse.

Questa distinzione spiega perché MCP è complementare a REST, GraphQL e altre interfacce applicative. Un servizio di pagamento può mantenere la sua API maturo mentre un server MCP espone un sottoinsieme attentamente limitato di operazioni con descrizioni e schemi adatti al modello.

MCP vs. Chiamata di Funzione

La chiamata di funzione o di strumento è una capacità del modello: il modello può restituire una richiesta strutturata per invocare una funzione. MCP è un protocollo per scoprire e comunicare con i fornitori di strumenti e contesto.

I due spesso lavorano insieme. Un server MCP indica all’host quali strumenti esistono. L’host presenta le definizioni selezionate a un modello. Il modello emette una chiamata a uno strumento. L’host utilizza quindi MCP per inviare quella richiesta al server appropriato.

MCP vs. Agent2Agent

MCP collega un’applicazione AI a capacità e contesto. Agent2Agent, o A2A, si concentra sulla comunicazione tra agenti autonomi che possono appartenere a sistemi o organizzazioni diversi.

Un sistema pratico può usare entrambi. Un agente potrebbe usare MCP per accedere ai propri strumenti e dati, poi usare A2A per delegare un compito più ampio a un altro agente. MCP risponde a “Come può questa applicazione usare quella capacità?” A2A risponde a “Come possono questi agenti coordinare il lavoro?”

Rischi di Sicurezza e Controlli

Un host sicuro mantiene una lista di autorizzazione esplicita di server e strumenti, mostra un consenso significativo quando l’accesso è concesso e associa ogni chiamata all’utente o all’identità del carico di lavoro che l’ha autorizzata. Gli schemi degli strumenti dovrebbero essere sufficientemente ristretti da rifiutare argomenti inattesi, mentre i log di audit dovrebbero registrare il server, la capacità, gli input, lo stato del risultato e il percorso di approvazione.

Le risorse restituite e i risultati degli strumenti sono anche una superficie di iniezione di prompt. Un documento letto tramite MCP può contenere testo che chiede al modello di ignorare le sue istruzioni o di esfiltrare dati. L’host deve mantenere la distinzione tra contenuti non attendibili e politica di sistema, e dovrebbe impedire che l’output di un server espanda silenziosamente i permessi di un altro server.

La standardizzazione migliora l’interoperabilità, ma non rende un server affidabile. Un server MCP può esporre dati sensibili, descrizioni fuorvianti degli strumenti, azioni non sicure o dipendenze compromesse. I contenuti non attendibili recuperati tramite una risorsa possono anche contenere istruzioni di iniezione di prompt volte a manipolare il modello.

I controlli importanti includono:

• Principio del minimo privilegio: fornire a ciascun server solo le credenziali e l’ambito necessari per il suo scopo.
• Fiducia nel server: verificare la provenienza, il codice, la proprietà e il percorso di aggiornamento dei server prima di collegarli.
• Visibilità per l’utente: rendere chiaro quale server riceverà i dati e quale azione eseguirà.
• Validazione dell’input: applicare schemi e regole di business al di fuori del modello.
• Confini di approvazione: confermare azioni sensibili, esterne, finanziarie o distruttive.
• Minimizzazione dei dati: evitare di inviare interi documenti o conversazioni quando è necessaria solo una piccola parte.
• Registrazione e revoca: registrare le chiamate, monitorare le anomalie e rendere le credenziali e le connessioni facili da disabilitare.

Il progetto MCP continua a perfezionare la sua architettura e le linee guida di sicurezza. L’aggiornamento della specifica 2026 del progetto illustra come lo standard si stia evolvendo verso un’infrastruttura più semplice, autorizzazione e distribuzione in produzione.

Quando gli sviluppatori dovrebbero usare MCP?

MCP è una soluzione adatta quando più client AI hanno bisogno di una connessione coerente alla stessa capacità, quando gli strumenti devono essere scoperti a runtime, o quando un team desidera separare l’orchestrazione AI dal codice di integrazione specifico del sistema.

Una chiamata di funzione diretta può rimanere più semplice per una piccola applicazione con un backend strettamente controllato. L’adozione del protocollo comporta un proprio lavoro operativo: gestione del ciclo di vita del server, test di compatibilità, autenticazione, osservabilità e governance.

Cosa ricordare sul Model Context Protocol (MCP)

MCP è un linguaggio comune tra le applicazioni AI e gli strumenti e il contesto che le circondano. Il suo valore deriva dalla sostituzione di convenzioni di integrazione isolate con un protocollo scoperto, strutturato ed estensibile.

Lo standard non elimina la necessità di un’ingegneria accurata. Gli host devono comunque decidere quali server fidarsi, quali capacità esporre, quali dati condividere e quando una persona deve approvare un’azione. MCP rende le connessioni portabili; la governance le rende sicure e utili.