Il Model Context Protocol, lo standard che permette agli agenti AI di collegarsi a calendari, database e strumenti aziendali, sta per cambiare in un punto che sembra invisibile e invece pesa parecchio. La nuova versione della specifica, attesa per il 28 luglio, elimina il sistema di sessioni con cui i server MCP tengono traccia delle conversazioni. È la rimozione di un collo di bottiglia che ha frenato le aziende dal portare MCP oltre la fase dimostrativa, non un aggiornamento cosmetico. Il cambiamento è stato descritto nel dettaglio in questi giorni.
MCP nasce da Anthropic nel novembre 2024, ma oggi vive come specifica aperta, con contributi di più fornitori e un processo di sviluppo che assomiglia a quello di altri standard di internet. È la base tecnica che permette a un assistente come Claude di leggere un foglio di calcolo aziendale, aggiornare un record CRM o interrogare un database interno, senza che ogni azienda debba costruire un'integrazione su misura per ogni singolo strumento. Ne avevamo già spiegato il funzionamento qualche mese fa: è il framework che trasforma un modello linguistico da generatore di testo a strumento operativo.
Il problema era il load balancer, non l'intelligenza artificiale
Il meccanismo attuale funziona così: quando un client come Claude si collega a un server MCP, manda un messaggio di apertura (il protocollo lo chiama "initialize"), il server risponde con le proprie capacità e assegna un codice di sessione. Da quel momento, il client deve includere quel codice in ogni richiesta successiva, così il server sa che sta parlando con la stessa conversazione di prima.
Su un singolo computer questo schema non crea alcun problema: il codice resta in memoria e basta. Cambia tutto quando il server serve milioni di utenti attraverso decine di macchine dietro un load balancer, il sistema che smista ogni richiesta verso la macchina disponibile, spesso in un'altra area geografica. A quel punto ogni macchina della flotta dovrebbe conoscere i codici di sessione assegnati dalle altre. Nate Barbettini di Arcade.dev, che ha pubblicato l'analisi tecnica più dettagliata sul cambiamento, la descrive con chiarezza: il meccanismo attuale si scontra con il load balancer invece di lavorare insieme a lui.
Il web ha già attraversato lo stesso problema. Anni fa i siti usavano le sessioni "sticky", che agganciavano un browser sempre allo stesso server per tutta la durata della visita. Con la crescita del traffico, il web ha preferito applicazioni stateless, dove il server non deve ricordare nulla del visitatore tra una richiesta e l'altra. MCP sta facendo lo stesso passaggio, con qualche anno di ritardo.
Cosa significa davvero "stateless"
La parola si presta a un equivoco: stateless non vuol dire che scompare ogni forma di stato, né che il protocollo si riduce a richieste banali. Significa che il server non deve più ricordare nulla tra una richiesta e l'altra, perché il client porta con sé tutte le informazioni necessarie a ogni chiamata. L'handshake iniziale sparisce: il client non saluta più una volta sola all'inizio, si presenta a ogni richiesta, più o meno come un browser che manda lo user-agent a ogni pagina che visita.
Il cambiamento è una rottura di compatibilità in senso tecnico stretto. Un client costruito per la versione attuale della specifica (quella datata 2025-11-25) non riesce a parlare nativamente con un server aggiornato alla versione 2026-07-28, e vale anche il contrario. Il protocollo prevede un meccanismo di negoziazione della versione che evita il collasso dell'ecosistema, ma nel periodo di transizione chi gestisce server e gateway dovrà sostenere il doppio binario.
Perché finora le grandi aziende si sono fermate alla demo
Il punto che rende la notizia rilevante per chi decide budget IT, più che per chi scrive codice, è un altro: il problema delle sessioni è una delle ragioni per cui le integrazioni MCP di prima parte, quelle ufficiali offerte direttamente dai grandi fornitori software, sono arrivate così lentamente. Costruire un server MCP dimostrativo sul proprio laptop è ormai un esercizio semplice. Farlo funzionare per diecimila dipendenti, con la resilienza che un'infrastruttura aziendale richiede, è tutta un'altra storia, e la gestione delle sessioni stateful era uno degli scogli più concreti.
Rimuovere quello scoglio non significa che le integrazioni proprietarie arrivino automaticamente. Significa che la barriera tecnica più citata dagli ingegneri che dovevano portare MCP in produzione perde peso. Le aziende che hanno rimandato un progetto di server MCP proprietario proprio per questa complessità ora hanno un motivo tecnico in meno per continuare a rimandarlo.
Ma la scalabilità tecnica non è governance. Lo dimostrano i numeri che arrivano da altre analisi: il 94% delle aziende vede già agenti proliferare fuori controllo, spesso senza sapere quanti ne stiano girando nei propri sistemi né chi li abbia autorizzati. Rendere più facile costruire un server MCP di scala aumenta anche la superficie di un problema che l'azienda non ha ancora imparato a gestire.
L'elenco che ogni IT manager dovrebbe compilare adesso
La conseguenza operativa per chi valuta MCP in azienda non riguarda il protocollo in sé, riguarda cosa il protocollo non risolve. Prima di affidare un'integrazione proprietaria al nuovo standard stateless, ha senso censire quali sistemi interni sono candidati a diventare server MCP, e verificare quattro punti che restano fuori dalla specifica tecnica: come viene gestita l'autenticazione dei client che si collegano, come si garantisce l'isolamento tra i dati di tenant diversi quando il server serve più clienti o più reparti, quali autorizzazioni granulari servono per limitare cosa un agente può leggere o modificare, e come si comporta il tutto quando il traffico viene distribuito da un load balancer su più regioni.
Su questo fronte gli agenti vanno trattati come utenti ad alto rischio, con identità proprie, credenziali dedicate e limiti di accesso definiti in anticipo, non ereditati per comodità da un account umano. È un punto su cui la governance degli accessi resta scoperta nella maggior parte delle organizzazioni che pure accelerano sull'adozione.
C'è chi propone di mettere un livello intermedio tra client e server, un gateway che parli entrambe le versioni del protocollo durante la transizione e che tenga fuori dal protocollo stesso autorizzazione e policy di sicurezza, gestendole invece a runtime. È un'architettura che ha senso proprio perché il protocollo non deve portare il peso di ogni controllo di sicurezza: lasciarlo leggero è quello che lo rende più facile da mantenere su vasta scala.
Il traguardo resta la produzione, non la demo
La notizia non cambia nulla per chi usa un chatbot aziendale attraverso l'interfaccia già pronta. Conta per chi deve decidere se costruire, nei prossimi mesi, un server MCP proprietario da esporre a milioni di richieste. Chi ha già un prototipo che non regge oltre poche centinaia di utenti trova nel nuovo protocollo un motivo tecnico reale per riprovare, ma il gap tra chi ha le competenze per farlo in sicurezza e chi si ferma alla demo interna resta ampio. L'AI enterprise sta uscendo dalla fase delle demo su più fronti insieme, e questo aggiornamento è un tassello tecnico di quel passaggio, non la soluzione ai problemi di governance che lo accompagnano.
Chi ha un progetto in stallo per motivi di scalabilità farebbe bene a rivalutarlo entro l'autunno, quando l'ecosistema si sarà in gran parte allineato alla nuova versione. Chi deve ancora partire può aspettare che il doppio binario si esaurisca e costruire direttamente sul protocollo stateless, senza portarsi dietro il codice delle sessioni che sta per diventare superfluo.
.png)