Architettura MCP: analisi tecnica completa con diagrammi

L'architettura MCP è l'insieme fondamentale di componenti e regole di comunicazione che rendono possibile MCP (Model Context Protocol). MCP è uno standard open source e l'architettura MCP è l'infrastruttura sottostante su cui si basa.

Qualsiasi architettura MCP contiene tre componenti principali, attorno ai quali è costruita: un host, un client e un server. Il framework di comunicazione di MCP viene spesso descritto come composto da un livello dati e un livello di trasporto. Il livello dati è l'insieme di regole che definisce il formato dei messaggi (le richieste MCP vengono inviate in JSON-RPC 2.0). Il livello di trasporto veicola questi messaggi, utilizzando Streaming HTTP per le connessioni esterne.

L'architettura MCP è un framework server che implementa il Model Context Protocol, uno standard aperto per connettere i modelli di IA agli strumenti, a risorse come i database e a prompt che ampliano il contesto di input. Questi elementi sono chiamati collettivamente “primitive”. In definitiva, l'architettura MCP consente agli LLM di scoprire quali strumenti sono disponibili ed eseguire flussi di lavoro, il tutto senza richiedere aggiornamenti regolari lato client.

Diagramma dell'architettura MCP: un'applicazione di IA scambia richieste con un server MCP, che fornisce strumenti, risorse e prompt.

Da quando è stata introdotta da Anthropic, l'architettura MCP è diventata ampiamente utilizzata nei flussi di lavoro di IA. Ciò è dovuto in gran parte al fatto che sostituisce sistemi che richiedono più manutenzione, come quelli basati su più connessioni API, senza sacrificare le prestazioni. Poiché tutte le funzionalità disponibili si trovano dietro il server MCP, è necessaria una sola connessione, e aggiornamenti e aggiunte sono immediatamente disponibili per l'applicazione client.

MCP offre agli LLM un modo per scoprire e richiamare gli strumenti, i prompt e le risorse a loro disposizione, sul sistema locale dell'applicazione host o da un provider esterno.

Nel caso degli strumenti, che forniscono accesso a funzionalità esterne, la scoperta prevede che l'host effettui una chiamata tools/list al server MCP per individuare quali strumenti sono disponibili. L'LLM (o in alcuni casi l'host) può quindi leggere le descrizioni degli strumenti disponibili e richiederli secondo necessità. Prompt e risorse seguono un processo simile.

Diagramma dei componenti dell'architettura MCP: un host contenente un LLM, un orchestratore e un client si connette a un server MCP in due fasi, prima la scoperta e poi le richieste, e il server MCP espone strumenti, risorse e prompt.

Ciò si contrappone all'architettura basata su API personalizzate, che è stata la norma nello sviluppo software, in cui le funzionalità esterne all'app dovevano essere richiamate tramite connessioni dedicate con richieste formattate in modo preciso.

L'applicazione host è la piattaforma centrale di orchestrazione e si connette a un LLM. Strumenti noti come Perplexity e Claude Desktop possono fungere da host all'interno di un sistema MCP.

In un flusso di lavoro semplice, l'utente pone una domanda tramite l'interfaccia di chat. Il componente orchestratore dell'host aggiunge quindi contesto alla domanda, indicando all'LLM quali primitive MCP sono disponibili insieme a una descrizione delle loro capacità.

Il client è un componente software dell'applicazione di IA. MCP fornisce un'interfaccia standard che consente al client di comunicare con server MCP interni ed esterni in base alle istruzioni dell'host o dell'LLM. Il suo compito è stabilire una connessione, formattare i messaggi JSON-RPC, inviare richieste e ricevere risposte.

I termini “host MCP” e “client MCP” vengono talvolta usati in modo intercambiabile. Si tratta tuttavia di una distinzione utile, perché un host come Perplexity potrebbe orchestrare più client MCP contemporaneamente. Un flusso di lavoro di IA complesso potrebbe richiedere l'accesso a decine o persino centinaia di server MCP distinti, ciascuno dei quali utilizzerà una connessione separata.

Diagramma di un host MCP, come Perplexity, che orchestra tre client MCP, ciascuno connesso al proprio server MCP, ad esempio un database, dei file o un'API esterna.

Il server espone tutti gli strumenti che lo strumento basato sull'IA può utilizzare. Dal punto di vista architetturale, il server MCP interpreta la richiesta in arrivo e, quando necessario, si connette alle primitive richieste.

I server MCP possono fornire accesso a tre categorie di primitive:

Strumenti: si tratta essenzialmente di funzionalità software esterne. In un approccio tradizionale basato su API, un'applicazione di analisi web potrebbe recuperare i dati tramite una richiesta formattata inviata a un server esterno. Nell'architettura MCP, tutte le funzionalità di terze parti di un provider sono disponibili tramite un'unica connessione e le richieste vengono create secondo regole di formattazione standard.
Risorse: le risorse sono fonti di dati che forniscono contesto in sola lettura. Gli schemi di database ne sono un buon esempio. Il server MCP espone le varie fonti di informazioni disponibili per l'host. Se l'host interroga il database, ad esempio con una ricerca SQL generata da un LLM, si tratta di una richiesta a uno strumento.
Prompt: sono modelli di prompt riutilizzabili che aiutano gli LLM a svolgere attività specifiche. Un utente o un host richiama un prompt anziché uno strumento perché servono istruzioni già pronte per completare un'attività. Spesso le attività predefinite in un'applicazione host, come l'opzione “revisiona il codice” o “analizza i dati”, sono memorizzate come prompt che l'utente può selezionare.

Vale anche la pena notare che MCP e API non sono tecnologie che si escludono a vicenda. Il server MCP può esporre chiamate API disponibili in risposta a una richiesta di scoperta. L'aspetto fondamentale è che spetta al provider MCP, non al client, mantenerle.

Il livello dati nell'architettura MCP è l'insieme di regole che definiscono il formato di richieste, risposte e notifiche. Il linguaggio standard per i messaggi è JSON-RPC.

Ogni architettura MCP segue un processo di base composto da (1) inizializzazione e scoperta da parte dell'host, (2) risposta da parte del server MCP e (3) chiamata da parte dell'host (a volte decisa dall'LLM), dove ogni fase corrisponde a un messaggio JSON distinto.

Diagramma del livello dati MCP: un utente invia un prompt all'applicazione host, dove l'LLM lavora con il client MCP; il client invia una richiesta al server MCP (strumenti, risorse, prompt) e riceve un risultato, e l'host restituisce una risposta all'utente.

Vediamo come funziona la scoperta degli strumenti attraverso due esempi (che potrebbero valere anche per risorse o prompt):

Scoprire gli strumenti prima della generazione dell'LLM: l'host avvia il client MCP, che invia una richiesta tools/list (l'elenco degli strumenti disponibili sul server MCP). L'LLM lo esamina durante il processo di generazione e stabilisce se è necessario un particolare strumento, risorsa o prompt.
Offrire all'LLM la possibilità di eseguire una ricerca: in un sistema agentico, l'host aggiunge un'opzione di scoperta, come search-tools, all'input di contesto e l'LLM può richiedere una ricerca se necessario.

Gli strumenti, che sono per lo più funzionalità di applicazioni esterne, vengono in genere selezionati dall'LLM o dall'host. Risorse e prompt vengono solitamente richiesti su iniziativa dell'utente o dall'host.

Ecco come appare una richiesta tools/list a un server MCP da parte di un'applicazione di note immaginaria:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

In questo esempio, “id”:101 identifica la richiesta tramite un ID, in modo che il client possa abbinare le risposte, e il campo “params” contiene informazioni aggiuntive sul client, come il nome del client (notes-app-client) e le sue capacità.

In risposta, il server MCP restituirà le definizioni degli strumenti, che includono i nomi degli strumenti disponibili e i relativi dettagli. Ad esempio, l'elenco potrebbe includere uno strumento add-task che consente all'applicazione di note di creare attività in un'applicazione di gestione delle attività o di calendario collegata, assegnando a ciascuna attività un titolo e una priorità.

Ecco come potrebbe apparire una richiesta:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Il campo “method” indica al server MCP che si tratta di una chiamata a uno strumento, “name” specifica quale strumento chiamare e “arguments” fornisce gli input richiesti.

Se il livello dati rappresenta il cosa della connessione tra un client e un server MCP, il livello di trasporto ne rappresenta il come. Definisce il modo in cui i messaggi viaggiano: il canale specifico e le regole che governano la consegna di richieste e risposte.

MCP prevede due percorsi di trasporto:

Standard input/output: viene utilizzato quando il server MCP viene eseguito nello stesso ambiente locale dell'app host. Il client scrive la richiesta JSON nello standard input del server. Il server la legge, esegue l'operazione richiesta e scrive la risposta nello standard output.
Streamable HTTP: quando il server MCP viene eseguito esternamente all'applicazione host, il client MCP invia le richieste al server tramite HTTP POST. Il server risponde con un singolo messaggio JSON oppure con uno stream Server-Sent Events (SSE), un canale di “ascolto” persistente che gli consente di restituire più messaggi nel tempo.

L'architettura multi-tenant MCP è un tipo di implementazione in grado di servire più utenti (tenant) contemporaneamente.

In questo caso, un tenant può essere una persona, un gruppo di persone o un'organizzazione. L'implementazione può prevedere l'esecuzione di un server MCP separato per ogni tenant, l'accesso a un unico server condiviso oppure il posizionamento di un insieme di server dietro un gateway centrale. Quando si utilizza un gateway, questo instrada le richieste verso gli endpoint corretti in base all'identità dell'utente o alla natura della richiesta.

Funziona secondo lo stesso principio di base dell’architettura MCP standard, ma le richieste dei singoli utenti operano ciascuna nel proprio spazio di lavoro (anche se ciò comporta risorse condivise) e vengono autenticate separatamente. È un approccio comune negli scenari aziendali, dove spesso si preferiscono le risorse condivise perché eseguire più server MCP sarebbe inutilmente costoso.

Come si presenta in pratica una richiesta MCP end-to-end? Ci sono otto fasi principali, ciascuna delle quali coinvolge un componente distinto dell'architettura.

Diagramma di flusso di una richiesta MCP end-to-end in otto passaggi: scoperta degli strumenti, input dell'utente, elaborazione del modello, selezione dello strumento, richiesta, esecuzione dello strumento, risultato e generazione della risposta.

Ecco come si presenta in pratica una chiamata a uno strumento MCP, riprendendo l'esempio precedente di un'applicazione di note collegata a un servizio di gestione delle attività:

Scoperta degli strumenti: l'applicazione di note (host) utilizza il proprio client MCP per richiedere gli strumenti disponibili sul server tramite una richiesta tools/list. Il server ne restituisce nomi, descrizioni e input previsti, compresi quelli dello strumento add-task. Ciò può avvenire prima che tu invii un prompt.
Input dell'utente: invii una richiesta all'applicazione di note basata su LLM tramite il chatbot integrato nell'app, ad esempio: “Crea un'attività nel mio calendario per rivedere la mia nuova bozza con priorità media.”
Elaborazione del modello: l'host invia all'LLM la tua richiesta e le definizioni degli strumenti pertinenti.
Selezione dello strumento: l'LLM genera una richiesta strutturata per lo strumento, specificando lo strumento e i relativi input: add-task con title: Review the draft e priority: Medium. L'host verifica se l'azione è consentita e passa la richiesta al client MCP, che invia un messaggio JSON-RPC.
Richiesta: il client MCP invia una richiesta tools/call al proprio server MCP.
Esecuzione dello strumento: il server MCP chiama l'API dell'applicazione di gestione delle attività per creare una nuova attività con il titolo e la priorità specificati.
Restituzione del risultato: il server invia il risultato al client MCP, che lo passa all'host. L'host lo aggiunge alle informazioni fornite all'LLM.
Generazione della risposta: l'LLM utilizza il risultato per generare una risposta per l'utente, ad esempio “Ho creato un'attività per rivedere la bozza con priorità media.”

MCP e l'architettura API tradizionale vengono spesso confusi, ma sono tecnologie complementari. MCP è stato progettato specificamente per le applicazioni basate sull'IA. Supera l'elevato onere di manutenzione legato all'implementazione e alla gestione di più connessioni API hardcoded.

Fornendo all'applicazione host un'unica connessione per ciascun provider di funzionalità o risorsa interna, MCP aiuta a risolvere il problema di un input di contesto sovraccarico (che elenca tutte le API) o di script applicativi basati su API limitati.

I server MCP, invece, possono esporre le API (o meglio, le funzionalità che chiamano le API) come parte del loro elenco di strumenti. Ogni volta che un provider aggiorna la propria app e c'è una nuova API, o se la documentazione cambia, basta aggiornare il server MCP. Non sono necessarie modifiche al codice lato app host.

La sicurezza di MCP è stata oggetto di ampio dibattito sin dalla sua introduzione. Sebbene sia generalmente considerata una tecnologia sicura, presenta diversi rischi per la sicurezza, molti dei quali sono più evidenti nelle implementazioni di architetture complesse.

L'architettura MCP presenta i seguenti potenziali punti deboli:

Prompt injection: un utente inserisce un prompt dannoso in dati esterni che il modello di IA interpreta erroneamente come un'istruzione.
Accesso con privilegi eccessivi: i server MCP possono potenzialmente esporre un gran numero di strumenti a un modello di IA, il che può aumentare la possibilità di problemi di sicurezza (il cosiddetto “raggio d'impatto”).
Fughe di dati accidentali: implementazioni configurate in modo inadeguato possono far sì che informazioni sensibili, come chiavi API o credenziali di database, vengano passate a un LLM.
Manipolazione del sistema locale: i server MCP locali sono vulnerabili ai problemi del sistema locale, come gli script dannosi, tanto quanto qualsiasi altra applicazione, con l'ulteriore problema che possono avere effetti dannosi a valle sui sistemi di IA agentica.

Nessuno di questi problemi è insormontabile. Spesso bastano misure consolidate per garantire la sicurezza del sistema. Misure come mantenere una persona nel ciclo decisionale (human in the loop), applicare controlli rigorosi sui dati sensibili e proteggersi dagli attacchi ai server sono tutte pratiche comuni.

MCP si è dimostrato uno standard aperto utile e popolare tra gli sviluppatori. Supera molti dei problemi delle API hardcoded nelle applicazioni basate su LLM e riduce in modo sostanziale l'onere di programmazione per gli sviluppatori.

In futuro, l'architettura host e server alla base di MCP rimarrà quasi certamente la stessa. Le innovazioni future si concentreranno su capacità agentiche avanzate nei flussi di lavoro in più fasi.

Inoltre, man mano che i sistemi di IA diventeranno più estesi e complessi, serviranno misure di sicurezza più solide per l'implementazione di queste funzionalità agentiche, oltre a un'architettura scalabile, soprattutto nel livello di trasporto.

Che cos'è l'architettura MCP?

Componenti dell'architettura MCP: host, client e server

Host

Client

Server

Che cos'è il livello dati nell'architettura MCP?

Che cos'è il livello di trasporto nell'architettura MCP?

Che cos'è l'architettura multi-tenant MCP?

Diagramma dell'architettura MCP: guida passo passo

In che cosa l'architettura MCP differisce dalla tradizionale architettura API?

L’architettura MCP è sicura?

Quale futuro per l'architettura MCP?