Cos'è MCP? Come gli agenti IA si connettono ai tuoi dati (Aggiornamento specifiche 2026)
MCP, il Model Context Protocol, è uno standard aperto che consente a un agente AI di accedere a strumenti e fonti di dati attraverso un'unica interfaccia comune. Invece di un'integrazione personalizzata per ogni app, un client comunica tramite un unico protocollo e qualsiasi server conforme può rispondere. Le specifiche sono state riscritte il 28 luglio 2026 e il cambiamento è significativo.
Questa guida illustra le funzioni del protocollo e le novità introdotte con il rilascio del 2026-07-28. Copre inoltre ciò che è stato deprecato, in cosa differisce da una semplice integrazione API e quando non è necessario. Le informazioni qui riportate sono aggiornate al 5 agosto 2026.
Cos'è MCP?
Pensatelo come una presa di corrente standard. Prima che esistesse uno standard, collegare un assistente al database, al sistema di ticket e ai file richiedeva tre integrazioni su misura. Ognuna aveva la propria autenticazione, la propria gestione degli errori e il proprio carico di manutenzione.
MCP definisce questa connessione una volta per tutte. Un client rappresenta il lato dell'agente. Un server racchiude una fonte di dati o uno strumento ed espone ciò che può fare. Il client chiede al server cosa sia disponibile e poi lo richiama.
I server in genere espongono tre tipi di elementi. Gli strumenti sono azioni che l'agente può invocare. Le risorse sono contenuti leggibili. I prompt sono modelli riutilizzabili. Il client rileva tutti e tre a runtime, anziché averli codificati nel codice sorgente.
Il nome viene spesso usato in modo approssimativo, quindi è utile fare chiarezza. Il protocollo non è un modello, non è un agente e non è un prodotto. È il formato di comunicazione tra di essi.
Due parole spiegano la maggior parte della confusione al riguardo. Discovery significa che il client apprende ciò che un server offre a runtime. Riuso significa che lo stesso server risponde a qualsiasi client conforme.
L'adozione non è più teorica. I manutentori del protocollo segnalano quasi mezzo miliardo di download al mese per gli SDK di Tier 1. Gli SDK TypeScript e Python hanno superato ciascuno un miliardo di download totali.
Cosa è cambiato nelle specifiche del 2026-07-28
Questa versione rappresenta la revisione più importante che il protocollo abbia mai ricevuto. La novità principale è che il nucleo è ora stateless.
| Cambiamento | Cosa significa |
|---|---|
| Core stateless | Sessioni e handshake sono scomparsi. Ogni richiesta porta con sé la propria versione del protocollo e l'identità del client |
| Richieste multi-round-trip | Sostituiscono le richieste avviate dal server che richiedevano un flusso aperto. Uno strumento può chiedere l'input dell'utente a metà chiamata |
| Routing basato su header | I nomi dei metodi e degli strumenti viaggiano negli header Mcp-Method e Mcp-Name, consentendo ai gateway di instradare e autorizzare in base agli header |
| Risultati dell'elenco memorizzabili in cache | Gli elenchi di strumenti, prompt e risorse ora contengono ttlMs e cacheScope |
| Rafforzamento dell'autorizzazione | Validazione dell'issuer RFC 9207, passaggio dalla Dynamic Client Registration ai Client ID Metadata Documents e credenziali vincolate all'issuer |
| Framework delle estensioni | I task passano dal core sperimentale a un'estensione formale, insieme ad Apps ed Enterprise Managed Authorization |
Leggete questo elenco come un'unica decisione ripetuta sei volte. Ogni modifica rimuove un presupposto che rendeva complicata la gestione dei server remoti. Nulla di tutto ciò cambia ciò che uno strumento può fare.
Il post ufficiale sulle specifiche del 2026-07-28 contiene l'elenco completo delle modifiche. Gli SDK per TypeScript, Python, Go e C# lo supportano già, con Rust in versione beta.
Perche l'approccio stateless è importante se gestisci un server
Il vecchio design presupponeva una connessione persistente e bidirezionale. Questa singola ipotesi era la causa della maggior parte delle difficoltà operative.
In precedenza, un server remoto necessitava di sessioni permanenti affinché un client finisse sempre sulla stessa istanza. Richiedeva uno storage di sessione condiviso affinché lo stato sopravvivesse a un riavvio. Spesso i gateway dovevano ispezionare i payload per capire cosa stesse facendo una richiesta.
Niente di tutto questo è più necessario. Un server può trovarsi dietro un semplice load balancer round-robin. L'instradamento avviene su un header. I client memorizzano in cache l'elenco degli strumenti per tutto il tempo consentito dalla finestra temporale indicata dal server. Il protocollo è passato da qualcosa da distribuire con estrema cautela a qualcosa che si distribuisce normalmente.
C'è un costo di migrazione associato. I server sviluppati sulla base del vecchio core richiedono interventi di adeguamento, e le librerie client devono evolversi di conseguenza.
Questo cambiamento riduce anche il costo per provarne uno. Configurare un server un tempo era una decisione infrastrutturale. Ora è molto più simile alla distribuzione di un qualsiasi piccolo servizio web.
Per chiunque stia valutando il server MCP di un fornitore, la domanda pratica da porsi è questa: a quale versione delle specifiche si rivolge e quando avverrà la migrazione.
Cosa è deprecato e quanto tempo rimane
Tre funzionalità sono in via di eliminazione: Roots, Sampling e Logging. Anche il trasporto legacy HTTP+SSE è deprecato.
I manutentori si sono impegnati a garantire una finestra minima di dodici mesi prima della rimozione. È un periodo generoso, ma rappresenta anche una scadenza. Se avete sviluppato su una di queste quattro tecnologie, inserite la migrazione in una roadmap anziché lasciarla nel backlog.
Controllate anche il vostro client, non solo il server. Un client vincolato al vecchio trasporto continuerà a funzionare durante questo periodo di transizione, per poi smettere di funzionare.
La Dynamic Client Registration è formalmente deprecata a favore dei Client ID Metadata Documents. Le credenziali vincolate all'issuer ora impediscono che un token emesso per un server venga riutilizzato contro un altro.
MCP a confronto con una semplice integrazione API
| Integrazione API personalizzata | Server MCP | |
|---|---|---|
| Lavoro per singola fonte | Nuova autenticazione, schema e gestione degli errori ogni volta | Un unico protocollo, riutilizzato |
| Discovery | Si codifica rigidamente ciò che esiste | Il client lo richiede a runtime |
| Chi può usarlo | L'app in cui è stato integrato | Qualsiasi client conforme |
| Manutenzione | Si interrompe quando l'API del fornitore cambia | Il server assorbe il cambiamento |
| Ideale per | Un unico percorso profondo e ad alto volume | Molteplici fonti raggiunte da un agente |
Un'ulteriore considerazione riguarda chi si occupa della manutenzione del connettore. Un server pubblicato dal fornitore si evolve insieme al prodotto del fornitore stesso, sollevandovi da questo carico di lavoro.
Ad essere onesti, MCP non è più veloce o economico per una singola integrazione. Diventa vincente quando il numero di fonti cresce, o quando si desidera che più di un agente acceda alla stessa fonte senza dover ricostruire tutto.
Cosa si può produrre una volta collegata una fonte di dati
La connessione rappresenta l'infrastruttura di base. Il motivo per cui ci si impegna è il risultato finale che si ottiene.
Con una fonte di dati collegata, un agente può estrarre i numeri aggiornati ed eseguire l'analisi. Ciò che si ottiene è un prodotto finito: un grafico, un riepilogo scritto, un set di slide. Il valore deriva dall'eliminazione della fase di esportazione, non dal protocollo in sé. Il risultato finale è anche ciò che rende questa configurazione degna di essere sostenuta internamente. Una connessione che nessuno trasforma in un report viene disattivata senza troppi complimenti.
Powerdrill Bloom distribuisce un server basato su questo modello. In base alla sua documentazione, si autentica con il vostro User ID e la Project API Key. Un client può quindi sfogliare i dataset nel vostro account, estrarre dettagli su ciascuno di essi ed eseguire attività ponendo domande in linguaggio naturale. Funziona con Claude Desktop e altri client conformi. L'annuncio del server MCP illustra la configurazione, mentre la pagina dei connettori dati elenca gli altri tipi di fonti.
Quando non avete affatto bisogno di MCP
Questa parte viene spesso tralasciata nella maggior parte delle guide esplicative, quindi vale la pena esprimerla chiaramente.
Se i vostri dati arrivano sotto forma di file, non avete bisogno di un protocollo. Vi basta un caricamento. Un'esportazione trimestrale, un CSV inviato via email, un estratto conto in PDF: nessuno di questi elementi giustifica la configurazione di un server. Trascinate il file all'interno e ponete la vostra domanda.
Ponetevi una domanda prima di procedere allo sviluppo. Questa stessa esportazione sarà necessaria anche il mese prossimo, e a qualcun altro oltre a voi?
MCP si rivela davvero utile quando la fonte è attiva e ricorrente. Un database che cambia ogni ora, una coda di ticket, una tabella di data warehouse che alimenta un report settimanale. La prova del nove consiste nel chiedersi se, in alternativa, dovreste esportare nuovamente la stessa cosa la settimana successiva.
C'è anche una dimensione legata alla sicurezza. Una fonte connessa rappresenta un'autorizzazione permanente, non una condivisione una tantum. Le modifiche all'autorizzazione del 2026-07-28 esistono proprio perché questa distinzione è fondamentale.
In sintesi
MCP è una spina standard tra agenti e fonti di dati. La versione del 2026-07-28 ha reso il core stateless, ha spostato il routing negli header, ha reso memorizzabili in cache i risultati degli elenchi e ha rafforzato l'autorizzazione. Roots, Sampling, Logging e il vecchio trasporto HTTP+SSE sono deprecati con una finestra di transizione di dodici mesi.
Per un file una tantum, saltate tutto questo. Provate Powerdrill Bloom gratuitamente — caricate il file, ponete la vostra domanda in linguaggio naturale ed esportate il grafico o la presentazione. Se state confrontando le opzioni di server, consultate le migliori piattaforme MCP.
Domande frequenti
Cosa significa la sigla MCP?
Model Context Protocol. Si tratta di uno standard aperto per collegare i client AI a strumenti e fonti di dati attraverso un'unica interfaccia. In questo modo, ogni nuova fonte evita un'integrazione su misura.
Cosa è cambiato nelle specifiche MCP del 2026-07-28?
Il core è diventato stateless, eliminando sessioni e handshake. Le richieste multi-round-trip hanno sostituito le richieste avviate dal server su flussi aperti, e il routing è stato spostato negli header Mcp-Method e Mcp-Name. I risultati degli elenchi sono diventati memorizzabili in cache e l'autorizzazione è stata rafforzata con la validazione dell'issuer e credenziali vincolate all'issuer.
MCP è la stessa cosa di un'API?
No. Un'API è l'interfaccia di un singolo fornitore verso un singolo sistema. Il protocollo è un wrapper comune che molti sistemi possono implementare, consentendo a qualsiasi client conforme di rilevarli e richiamarli senza codice personalizzato per ogni fonte.
Cosa è deprecato nelle nuove specifiche MCP?
Roots, Sampling e Logging sono deprecati, così come il trasporto legacy HTTP+SSE. La Dynamic Client Registration cede il passo ai Client ID Metadata Documents. I manutentori hanno indicato una finestra minima di dodici mesi prima della rimozione.
Ho bisogno di MCP per analizzare un foglio di calcolo con l'AI?
No. Per un file di cui si è già in possesso, il caricamento è più semplice e veloce. Vale la pena configurare il protocollo quando la fonte è attiva e, in caso contrario, si dovrebbe riesportare periodicamente gli stessi dati.