Model Context Protocol diventa stateless: cosa cambia con la specifica MCP 2026-07-28

Il Model Context Protocol, lo standard aperto che collega i modelli di intelligenza artificiale a strumenti, dati e applicazioni esterne, ha appena ricevuto l’aggiornamento più importante da quando è nato. Il 28 luglio 2026 i manutentori del progetto hanno pubblicato la specifica 2026-07-28, la quinta revisione e, a loro stessa detta, la più profonda dal lancio. La novità che cambia le carte in tavola si riassume in una sola parola, stateless: MCP smette di essere un protocollo bidirezionale costruito sulle sessioni e diventa un protocollo a richiesta e risposta, molto più semplice da scalare. Se lavori con agenti AI, integrazioni o infrastrutture cloud, è una di quelle notizie tecniche che meritano attenzione, perché ridisegna il modo in cui vengono costruiti e messi in produzione i server che alimentano gli assistenti intelligenti.

Per capire la portata del fenomeno basta un dato. Negli ultimi mesi gli SDK ufficiali del protocollo hanno superato il mezzo miliardo di download al mese, e le librerie per TypeScript e Python hanno oltrepassato ciascuna il miliardo di download complessivi. In poco più di un anno e mezzo MCP è diventato l’infrastruttura di fatto su cui si appoggiano gli agenti quando devono leggere dati e usare strumenti.

Cosa significa che il Model Context Protocol diventa stateless

Fino alla versione precedente, ogni connessione MCP iniziava con una stretta di mano. Il client e il server si scambiavano un messaggio di initialize e uno di initialized per concordare la versione del protocollo, le funzioni disponibili e l’identità di chi stava parlando. Da quel momento in poi la conversazione restava legata a un identificativo di sessione, l’header Mcp-Session-Id, che incollava il client a una specifica istanza del server.

Questo schema funzionava bene sul portatile di uno sviluppatore, molto meno in produzione. Un server MCP remoto aveva bisogno di sessioni appiccicose, di un archivio condiviso per ricordare lo stato di ogni conversazione e di un gateway capace di ispezionare il contenuto delle richieste per indirizzarle all’istanza giusta. Tutto questo rendeva difficile scalare in orizzontale e trasformava l’archivio delle sessioni in un potenziale punto singolo di rottura.

La specifica 2026-07-28 rovescia il tavolo. La stretta di mano iniziale sparisce, e con lei l’header di sessione. Ogni richiesta ora viaggia da sola e porta con sé tutto ciò che serve: la versione del protocollo, l’identità e le capacità del client vengono inserite in un campo dedicato chiamato _meta. Chi vuole conoscere in anticipo le funzioni di un server può usare una nuova chiamata facoltativa, server/discover, ma non è più un passaggio obbligato.

Il risultato pratico è enorme. Qualunque richiesta può finire su qualunque istanza del server dietro un semplice bilanciatore di carico a rotazione, senza bisogno di memoria condivisa.

Stateless non vuol dire senza memoria

C’è un equivoco da chiarire subito. Rendere il protocollo stateless non obbliga la tua applicazione a dimenticare tutto tra una chiamata e l’altra. Se un server deve conservare uno stato, per esempio il contenuto di un carrello o l’identificativo di una sessione di navigazione, può generare un riferimento esplicito da uno strumento e fare in modo che il modello lo riporti come argomento nelle chiamate successive. I manutentori sostengono che questo approccio sia perfino migliore dello stato nascosto nel trasporto, perché il modello vede il riferimento, può ragionarci sopra e passarlo da uno strumento all’altro.

Le altre novità della specifica 2026-07-28

Il cuore stateless è la notizia principale, ma il rilascio porta con sé un pacchetto corposo di cambiamenti pensati per la scala e la sicurezza. Il più elegante riguarda le richieste che partono dal server verso il client, come la domanda di una conferma o di un parametro mancante a metà di un’operazione. Prima servivano canali sempre aperti; ora entra in gioco un meccanismo chiamato Multi Round-Trip Requests, che permette al server di rispondere con un segnale di input necessario e al client di riprovare la stessa chiamata allegando le risposte richieste.

Cambia anche il modo di instradare il traffico. Il nome del metodo e quello dello strumento invocato ora viaggiano in due header HTTP dedicati, Mcp-Method e Mcp-Name, così un gateway o un sistema di limitazione può indirizzare e contare le richieste leggendo l’intestazione, senza dover aprire e analizzare il corpo in formato JSON. Le risposte che elencano strumenti e risorse, inoltre, portano indicazioni sulla durata della cache, quindi i client possono conservarle ed evitare di richiederle di continuo.

Il capitolo più sostanzioso resta però quello dell’autenticazione, storicamente il punto dove gli sviluppatori perdevano più tempo.

La nuova specifica allinea MCP agli standard OAuth 2.1 e OpenID Connect e rende i server MCP dei veri e propri resource server. Arrivano verifiche più rigorose, come la validazione dell’emittente del token secondo la norma RFC 9207, che chiude una vulnerabilità nota di scambio tra server di autorizzazione. La vecchia registrazione dinamica dei client viene deprecata a favore dei Client ID Metadata Documents, un metodo più solido e conforme alle regole di OAuth. Per un’azienda che espone i propri server dietro un provider di identità come Okta o Microsoft Entra, il percorso da server non autenticato a server messo in sicurezza è finalmente definito a livello di protocollo, e non lasciato all’improvvisazione.

Non manca una pulizia delle funzioni più datate. Tre componenti storici, Roots, Sampling e Logging, vengono deprecati, insieme al vecchio trasporto basato su HTTP e SSE. Continueranno a funzionare, ma il progetto introduce per la prima volta una politica di deprecazione formale con una finestra minima di dodici mesi, così puoi pianificare gli aggiornamenti invece di rincorrerli.

Estensioni ufficiali: MCP Apps e Tasks

Una delle scelte più lungimiranti di questa versione è la formalizzazione di un quadro per le estensioni. Invece di gonfiare il cuore del protocollo, le funzioni avanzate diventano moduli con un proprio ciclo di vita, che client e server negoziano quando serve. Due estensioni arrivano già insieme al rilascio.

La prima si chiama MCP Apps e permette a un server di mostrare interfacce interattive in HTML direttamente dentro il client. È un passaggio potenzialmente decisivo, perché trasforma MCP da semplice strato di integrazione per sviluppatori a possibile ecosistema rivolto anche agli utenti finali. Ogni azione avviata dall’interfaccia passa comunque per lo stesso percorso di consenso delle normali chiamate agli strumenti, quindi la sicurezza non viene sacrificata.

La seconda estensione, Tasks, porta il supporto nativo ai lavori lunghi e asincroni, quelli che un agente può eseguire per minuti o addirittura ore. Curiosamente è stata contribuita da AWS, segno di quanto lo standard sia ormai un terreno condiviso tra i grandi attori. Un server può rispondere a una chiamata con un riferimento al compito, e il client ne segue l’avanzamento interrogandolo a intervalli regolari.

Un ecosistema che ha già adottato lo standard

La forza di MCP non sta nella tecnologia in sé, ma nel fatto che quasi tutti i grandi nomi lo stanno già usando. Nato in casa Anthropic, l’azienda che sviluppa Claude, il protocollo è oggi un progetto aperto ospitato dalla Linux Foundation, e questo spiega l’ampiezza dell’adesione al nuovo rilascio.

Amazon ha reso disponibile il cuore stateless dentro Bedrock AgentCore; Cloudflare supporta la specifica fin dal primo giorno con il suo Agents SDK, permettendo a clienti come Sentry e Linear di adottarla subito; Google Cloud e Microsoft parlano apertamente di un salto in avanti per la scalabilità degli agenti aziendali. Anche l’ecosistema di Microsoft con il suo framework per gli agenti e piattaforme come Figma, Netlify e Supabase hanno annunciato il supporto. Un dato colpisce più di altri: la società di osservabilità Honeycomb racconta che ormai quasi il venti per cento delle sue interrogazioni mensili interattive arriva da agenti e non da persone.

È lo stesso movimento che spinge le aziende a costruire agenti per il lavoro enterprise, e che ora trova nello standard una base più affidabile su cui poggiare.

Perché questo aggiornamento conta davvero

Dietro un elenco di sigle tecniche si nasconde un messaggio semplice: MCP sta crescendo e sta diventando infrastruttura di produzione, non più un esperimento per soli appassionati. Le modifiche più importanti sono anche quelle che rompono la compatibilità, e la comunità ha scelto di fare il lavoro difficile invece di rattoppare le lacune. Per chi sviluppa significa server più semplici da scalare e da mettere in sicurezza; per le aziende significa poter contare su un protocollo che parla la lingua del web moderno, fatto di richieste indipendenti, cache e instradamento per intestazione.

C’è anche una lezione più ampia. Quando uno standard nato dentro una singola azienda passa a una fondazione neutrale e viene adottato in blocco dai concorrenti, vuol dire che il mercato ha deciso di non voler frammentare il modo in cui gli agenti parlano con il mondo. E per te che segui l’AI, capire questi tubi invisibili è spesso più utile che inseguire l’ultimo modello annunciato.

Se stai costruendo o integrando assistenti intelligenti, questo è il momento giusto per mettere le mani sulla nuova specifica e capire come funziona lo standard che li tiene insieme. Puoi partire dai fondamentali con la nostra guida che spiega cosa sono e come funzionano gli agenti AI, e poi seguire l’evoluzione del Model Context Protocol nei prossimi mesi: è qui che si gioca buona parte del futuro dell’AI applicata al lavoro.