MCP spiegato: cosa collega, cosa non fa e dove si colloca

Il Model Context Protocol (MCP) è un protocollo aperto per collegare applicazioni di intelligenza artificiale a capacità e informazioni esterne tramite contratti client-server standardizzati. Un server MCP può esporre strumenti, risorse e prompt; un host o client compatibile con MCP scopre e utilizza tali capacità per conto di un'applicazione di intelligenza artificiale. MCP non richiede che il server esegua un proprio modello linguistico e non sostituisce il runtime dell'agente, l'autorizzazione aziendale, l'isolamento dei tenant, le API applicative o l'architettura di dominio sottostante alle capacità esposte.

Cosa standardizza realmente MCP

Prima di MCP, ogni applicazione di intelligenza artificiale poteva integrare sistemi esterni tramite il proprio schema di strumenti, formato di plugin, convenzione di autenticazione e codice di connessione. Lo stesso servizio poteva richiedere adattatori diversi per un client AI desktop, un agente IDE e un'applicazione personalizzata.

MCP crea un confine di protocollo riutilizzabile. Il sistema esterno espone capacità tramite un server MCP, mentre gli host AI compatibili implementano un client MCP. Ciò riduce l'accoppiamento di integrazione tra l'applicazione di intelligenza artificiale e il fornitore di strumenti o dati sottostante.

Il protocollo non standardizza l'intera applicazione. Standardizza il modo in cui le capacità vengono descritte, scoperte e invocate attraverso quel confine.

L'esempio più semplice

Supponiamo che un'applicazione di programmazione AI necessiti di accedere a una directory di progetto locale. Senza MCP, l'applicazione potrebbe implementare direttamente la propria integrazione con il filesystem.

Con MCP, un server per il filesystem può esporre capacità come elencare directory, leggere file approvati o scrivere all'interno di uno spazio di lavoro consentito. L'host AI si connette tramite un client MCP e presenta tali capacità al modello o al runtime dell'agente.

Il server non ha bisogno di comprendere la richiesta in linguaggio naturale dell'utente. L'host/modello decide quale capacità è utile; il server MCP esegue la richiesta strutturata secondo le proprie regole di sicurezza.

Dove si ferma l'esempio semplice

MCP non definisce come l'host sceglie uno strumento, come un agente pianifica, come viene modellato un flusso di lavoro aziendale o come dovrebbe comportarsi un oggetto di dominio come una fattura o un deployment.

Un protocollo può rendere l'integrazione interoperabile mentre l'applicazione sottostante rimane errata, insicura o mal progettata. Una richiesta MCP perfettamente valida può comunque chiamare la capacità aziendale sbagliata.

Il confine centrale è: MCP standardizza la semantica dell'integrazione, non la verità dell'applicazione o la correttezza aziendale.

L'architettura MCP: host, client e server

Un host può connettersi a più server MCP, e un server MCP può interfacciarsi con uno o più sistemi sottostanti. L'host rimane responsabile dell'integrazione dei risultati MCP nell'applicazione AI più ampia.

Il server può essere locale all'host, essere eseguito come processo separato o essere remoto tramite un trasporto di rete. La topologia di hosting e la posizione del modello sono decisioni indipendenti.

Le tre primitive principali del server

Strumenti: capacità richiamabili

Gli strumenti sono operazioni strutturate che un server MCP rende disponibili all'host. Uno strumento ha un nome, una descrizione e uno schema di input; le implementazioni moderne possono anche fornire output strutturato.

Gli esempi includono la ricerca in un repository, la lettura di un record cliente, la creazione di un ticket, l'esecuzione di una build o l'invio di un messaggio. Gli strumenti possono essere di sola lettura o avere effetti collaterali.

Una buona superficie di strumenti MCP dovrebbe rappresentare obiettivi coerenti dell'utente o dell'agente piuttosto che rispecchiare meccanicamente ogni endpoint API interno. Le operazioni con permessi diversi, requisiti di conferma o raggio d'azione dovrebbero di solito essere strumenti separati.

Risorse: contesto e dati leggibili

Le risorse espongono dati o contenuti che un client può elencare o leggere. Si adattano naturalmente quando l'operazione semantica è "dammi questo artefatto o informazione" piuttosto che "esegui questa azione".

Un URI di risorsa non è una concessione di autorizzazione. Il server possiede comunque il controllo degli accessi e deve verificare quale principale può leggere l'oggetto sottostante.

La revisione del protocollo 2026-07-28 aggiunge semantiche di cache per le risposte di elenco e lettura delle risorse, inclusi freschezza e ambito della cache, rendendo il comportamento di caching più esplicito.

Prompt: modelli riutilizzabili

I prompt MCP consentono a un server di pubblicare modelli di prompt riutilizzabili ai client compatibili. Questo può mantenere le istruzioni specifiche del dominio vicine al fornitore della capacità.

Un prompt fornito da un server MCP non supera automaticamente le istruzioni di sistema o di sicurezza dell'host. L'host decide come il materiale del prompt entra nella sua gerarchia di contesto.

Il contenuto dei prompt fornito dal protocollo dovrebbe quindi essere trattato come dati di capacità con semantiche di fiducia esplicite, non come autorità di istruzione illimitata.

Strumento o risorsa?

Dove si trova il modello di IA?

MCP non richiede che il modello venga eseguito sul server MCP. Il modello può essere ospitato nel cloud, ospitato localmente, incorporato nell'applicazione desktop o raggiunto tramite un altro fornitore.

L'host normalmente possiede l'interazione con il modello. Il server MCP espone capacità esterne. Un server MCP locale può quindi essere utilizzato da un host il cui modello viene eseguito nel cloud, e un server MCP remoto può essere utilizzato da un host il cui modello viene eseguito localmente.

Se il server MCP stesso chiama internamente un LLM, quel modello fa parte dell'implementazione del server dietro il confine del protocollo; non è richiesto da MCP.

MCP non sostituisce le API

Un server MCP spesso avvolge API o servizi esistenti. REST, GraphQL, SQL, chiamate SDK e contratti di servizio interni possono rimanere esattamente dove sono.

MCP aggiunge uno strato di interoperabilità rivolto all'IA. L'API di dominio sottostante può rimanere il contratto applicativo autorevole per i normali client deterministici.

L'architettura usuale è quindi prima API/servizio, poi capacità selezionate rivolte all'IA — non “sostituire ogni API con MCP”.

MCP vs function calling

OpenAI attualmente espone i server MCP remoti come un tipo di strumento insieme al normale function calling, alla ricerca web, alla shell e ad altri strumenti. Tale implementazione illustra la relazione architetturale: la connettività MCP e l'interfaccia di chiamata agli strumenti del modello possono essere composte.

MCP non crea il ciclo dell'agente

Un agente di IA necessita di un runtime in grado di decidere, invocare strumenti, osservare i risultati, aggiornare lo stato e continuare o fermarsi. MCP può fornire alcuni degli strumenti e dei dati utilizzati da quel ciclo.

Il server MCP non diventa automaticamente il pianificatore, il sistema di memoria o l'orchestratore. Tali responsabilità normalmente rimangono nell'host o nel runtime dell'agente.

Un'applicazione non agentica può anche utilizzare MCP. Una singola chiamata deterministica a uno strumento MCP non richiede un agente autonomo a più passaggi.

MCP vs A2A

MCP collega principalmente un host o agente AI a capacità come strumenti, risorse e dati. A2A è finalizzato alla collaborazione tra sistemi di agenti indipendenti.

Un agente remoto può utilizzare internamente MCP per raggiungere database e strumenti, esponendo al contempo un'interfaccia A2A ad altri agenti. I protocolli possono quindi essere stratificati anziché sostituiti.

L'articolo esistente sullo stack di protocolli possiede il confronto più ampio MCP/A2A/UCP/AP2/A2UI; G02 rimane la definizione canonica di MCP.

L'uso locale e remoto di MCP presenta realtà di trasporto diverse

MCP può connettersi a server locali e remoti. Le integrazioni desktop locali utilizzano comunemente trasporti a livello di processo come stdio; i server remoti utilizzano un trasporto orientato a HTTP.

La revisione del 2026-07-28 rende il nucleo del protocollo stateless. Le richieste trasportano le informazioni necessarie per la gestione del protocollo invece di dipendere dal precedente modello di sessione a livello di protocollo.

La revisione attuale colloca anche i nomi dei metodi e delle capacità negli header HTTP, in modo che gateway, WAF, rate limiter e load balancer possano instradare e misurare il traffico MCP in modo più naturale.

Perché la consapevolezza della versione di MCP è importante

Anche la versione dell'SDK e la versione del protocollo sono cose diverse. L'attuale SDK TypeScript v2 è la linea stabile per la revisione 2026-07-28, mentre il precedente v1.x rimane una linea di manutenzione per il comportamento dell'era 2025.

La documentazione architetturale dovrebbe registrare sia la versione dell'SDK/libreria sia la revisione del protocollo laddove il comportamento di interoperabilità dipende da esse.

Cosa è cambiato in MCP 2026-07-28

Roots, sampling e logging non sono più la direzione per le nuove implementazioni

La release 2026-07-28 contrassegna roots, sampling e logging come capacità di protocollo deprecate con una finestra di compatibilità definita.

I tutorial più vecchi potrebbero ancora mostrare queste funzionalità come primitive centrali. Il nuovo lavoro di implementazione dovrebbe seguire la specifica corrente invece di copiare ciecamente i vecchi diagrammi del ciclo di vita.

La deprecazione non significa rimozione immediata. Significa che i nuovi sistemi dovrebbero evitare nuove dipendenze non necessarie da capacità da cui il protocollo si sta allontanando.

Il lavoro a lunga esecuzione non è la stessa cosa della normale invocazione di uno strumento MCP

Le operazioni a lunga esecuzione necessitano di semantiche del ciclo di vita che vadano oltre un semplice risultato immediato di uno strumento. Nell'ecosistema attuale, i Tasks sono stati spostati in un'estensione MCP dedicata.

Questo rafforza un utile principio di progettazione: il protocollo di base non ha bisogno di assorbire ogni preoccupazione relativa al runtime dell'agente.

Un'applicazione può anche mantenere interamente la proprietà del flusso di lavoro a lunga esecuzione nel proprio runtime e usare i normali strumenti MCP come operazioni sottostanti.

Le MCP Apps estendono le capacità dell'interfaccia utente senza ridefinire il protocollo principale

Le MCP Apps associano esperienze di interfaccia utente interattive più ricche agli strumenti MCP attraverso il modello di estensione.

L'host controlla ancora come quell'interfaccia utente viene incorporata, isolata e protetta.

Lo scambio di capacità principali e il rendering dell'interfaccia utente dovrebbero quindi rimanere responsabilità architetturali separate.

L'autorizzazione MCP non è il tuo modello di autorizzazione completo

MCP remoto necessita di meccanismi di autenticazione e autorizzazione a livello di protocollo affinché client e server possano stabilire un accesso affidabile. La specifica corrente continua a rafforzare il comportamento relativo a OAuth/OIDC.

Quel livello risponde alla domanda se un client è autorizzato a connettersi o a richiedere gli scope del protocollo. Non risponde automaticamente alla domanda se Alice può rimborsare l'ordine 123, se un agente può scrivere la configurazione di produzione o se il Tenant A può leggere i dati del Tenant B.

Quelle decisioni di dominio appartengono al modello di autorizzazione del server/applicazione e devono essere applicate prima di invocare l'operazione sottostante.

L'identità può attraversare diversi confini

Una richiesta MCP può coinvolgere l'applicazione client MCP, la persona che ha effettuato l'accesso, un'identità di agente/sessione e un account di servizio a valle.

Il server necessita di una policy esplicita su per conto di quale principale viene eseguita l'operazione. Altrimenti una potente credenziale di servizio può diventare un percorso di confused deputy.

Per l'uso aziendale, la correlazione tra identità utente, identità agente, connessione MCP e autorizzazione a valle è importante quanto la compatibilità del protocollo.

L'isolamento dei tenant rimane al di fuori della scoperta delle capacità MCP

Un server MCP multi-tenant deve applicare l'ambito del tenant quando legge o modifica risorse di proprietà del tenant. Restituire uno strumento chiamato search_documents non definisce a quale tenant appartengono i documenti idonei.

L'ambito del tenant dovrebbe essere derivato da un'identità o appartenenza attendibile e trasportato in database, cache, ricerca vettoriale, archiviazione di oggetti e API a valle.

Recuperare contenuti cross-tenant e chiedere al modello di non utilizzarli è già un fallimento dell'isolamento.

MCP non definisce la Fonte di Verità

Un server MCP può esporre un database, un repository di documenti, un servizio di ricerca web o un riepilogo generato dall'IA. Il protocollo non dichiara quale fonte sia autorevole per un'affermazione.

Le regole della Fonte di Verità appartengono all'architettura dell'applicazione/dominio. L'host o il server possono codificare l'autorità attraverso il design degli strumenti, i metadati, la politica di accesso o la validazione, ma MCP stesso non rende una capacità "vera".

Uno strumento può quindi essere perfettamente richiamabile tramite MCP e comunque restituire informazioni obsolete, secondarie o non autorevoli.

MCP e ingegneria del contesto

MCP può aumentare le capacità e le informazioni disponibili a un'applicazione di IA, ma l'ingegneria del contesto determina comunque ciò che raggiunge il modello.

I cataloghi di strumenti consumano contesto visibile al modello in molti host. I risultati degli strumenti possono essere grandi. Le risorse possono essere numerose. Un host necessita di selezione, filtraggio, caricamento dinamico e compattazione invece di esporre tutto ad ogni turno.

La disponibilità delle capacità e il contesto visibile al modello dovrebbero quindi essere trattati come livelli separati.

Progettare gli strumenti MCP attorno a risultati e confini di rischio

Le approvazioni appartengono all'architettura di esecuzione

Un host può richiedere l'approvazione dell'utente prima di invocare strumenti MCP selezionati. L'attuale integrazione MCP di OpenAI supporta modelli di esecuzione automatici o con approvazione esplicita.

L'approvazione dell'host è utile ma non dovrebbe essere l'unica protezione del server, perché un altro client MCP compatibile potrebbe utilizzare un modello di approvazione diverso.

Per azioni distruttive o con conseguenze finanziarie, usa la difesa in profondità: contratto dello strumento chiaro, approvazione a runtime dove appropriato, autorizzazione lato server, validazione di business e audit.

L'osservabilità MCP dovrebbe collegare le chiamate di protocollo alle azioni di dominio

Una traccia MCP è più utile quando può essere correlata alla chiamata applicativa sottostante, alla modifica del database o alla transazione di business.

Lo standard dell'ecosistema 2026-07-28 uniforma le convenzioni di propagazione del W3C Trace Context, rendendo più facile seguire una richiesta attraverso host, client, server e servizi a valle.

I soli log di protocollo non sono sufficienti per operazioni con conseguenze. Le prove di audit dovrebbero anche registrare il principal, il tenant, la risorsa target, l'approvazione e la conseguente modifica di stato rilevanti.

Cosa MCP non può risolvere

Prova di implementazione originale: Aaasaasa AI Client

L'applicazione può eseguire un endpoint MCP Streamable HTTP autenticato su loopback. L'endpoint espone solo le directory selezionate tramite il broker centrale dei permessi del workspace.

L'endpoint locale e la rotta remota sono questioni separate: il connettore locale può associarsi solo al loopback, mentre un Secure MCP Tunnel può rendere il servizio MCP approvato raggiungibile da un client AI esterno autorizzato senza esporre l'intera macchina locale.

Il modello centrale dei permessi distingue profili solo chat, sola lettura, scrittura progetto e directory personalizzate. Direct Chat non ha accesso al filesystem o alla shell; i runtime degli agenti con capacità di strumenti usano il profilo di permessi selezionato.

Questa è un'implementazione diretta del confine G02: MCP fornisce la connessione standardizzata alle capacità, mentre il broker dei permessi di proprietà dell'applicazione decide quali directory il server può esporre.

Quando MCP è adatto

Quando non hai bisogno di MCP

Non aggiungere MCP solo perché l'applicazione utilizza l'IA. Se il tuo backend chiama già una singola API interna e nessun client MCP indipendente necessita di quella capacità, una normale chiamata a funzione o a servizio può essere più chiara.

MCP aggiunge valore a un confine di interoperabilità. Senza quel confine, il protocollo può diventare uno strato adattatore non necessario.

La domanda architetturale non è "Questo progetto ha l'IA?" ma "Host IA e fornitori di capacità che evolvono in modo indipendente traggono beneficio da un contratto standard?"

Checklist di sicurezza MCP

Idee sbagliate comuni

Una sequenza pratica di progettazione MCP

Checklist di architettura MCP

Casi limite e limitazioni

Un server MCP stdio locale può avere una scarsa esposizione di rete pur essendo pericoloso se il processo stesso ha permessi eccessivi sul filesystem o sulla shell.

Un server MCP remoto può esporre solo documentazione pubblica o azioni aziendali altamente sensibili. "MCP remoto" dice poco sul rischio senza il contesto di capacità e autorizzazione.

Alcuni server possono usare solo strumenti e ignorare risorse/prompt. La compatibilità MCP non richiede che ogni primitiva opzionale sia ugualmente importante.

Un host può tradurre tra il proprio modello interno di strumenti e MCP. Gli utenti potrebbero non vedere mai direttamente il confine del protocollo, il che è accettabile se sicurezza e attribuzione rimangono chiare.

MCP continua a evolversi rapidamente. Estensioni, pattern di autorizzazione, API degli SDK e convenzioni dell'ecosistema possono cambiare più velocemente della distinzione architetturale principale.

Cosa cambierebbe questa risposta?

Le future revisioni di MCP possono modificare ciclo di vita, trasporti, autorizzazione e meccanismi di estensione. La revisione di luglio 2026 dimostra già perché le affermazioni specifiche di un'implementazione devono essere datate.

Il confine canonico cambierebbe solo se MCP si espandesse da protocollo di interoperabilità a standard di architettura end-to-end per applicazioni/agenti. Non è ciò che definisce il protocollo attuale.

Per il lavoro di implementazione, verificare sempre la specifica corrente e la linea SDK esatta invece di copiare esempi sensibili alla versione da tutorial più vecchi.

Conoscenza canonica correlata

MCP si colloca a valle dell'Agentic AI: prima comprendere il confine agente/runtime/strumento, poi usare MCP quando le capacità esterne necessitano di un contratto di protocollo portabile.

MCP dipende anche da RBAC e isolamento dei tenant perché l'esposizione delle capacità a livello di protocollo non determina l'autorizzazione dell'applicazione.

L'articolo più ampio sullo stack di protocolli spiega dove si colloca MCP accanto ad A2A, UCP, AP2 e A2UI. G02 rimane la fonte canonica per MCP stesso.

Domande frequenti

Glossario

Conclusione

MCP è più facile da comprendere quando il suo confine rimane ristretto: collega applicazioni AI a capacità esterne tramite un protocollo standard.

Il modello non deve risiedere sul server MCP. Il server non diventa il runtime dell'agente. Uno strumento elencato non diventa un'azione aziendale autorizzata. E MCP non sostituisce l'API sottostante, la fonte di verità, l'isolamento dei tenant o l'architettura di dominio.

Questa ristrettezza è la forza del protocollo. MCP può standardizzare il modo in cui i sistemi AI raggiungono strumenti e dati, lasciando la proprietà dell'applicazione, la sicurezza, la semantica di business e la scelta del modello ai livelli che ne sono effettivamente responsabili.

Fonti primarie e documentazione corrente

MCP si evolve rapidamente, quindi le affermazioni sensibili alla versione in questo articolo sono legate allo stato dell'8 ottobre 2026. La sezione Aaasaasa AI Client è una prova di implementazione originale ed è esplicitamente limitata all'ambito verificato del connettore MCP e del broker di permessi.