Il 28 luglio 2026 il Model Context Protocol è arrivato alla quinta versione ufficiale della sua specifica. Fino a una settimana prima circolava solo l’annuncio anticipato della svolta stateless, con i dettagli tecnici ancora da confermare. Chi ha seguito da vicino il rilascio lo descrive come il momento in cui MCP smette di essere un progetto sperimentale e prova a diventare infrastruttura di scala, sulle basi del protocollo già spiegate in un pezzo precedente.
La versione definitiva blinda i dettagli che erano solo ipotesi
Il problema del load balancer legato alle sessioni “sticky” lo avevamo raccontato una settimana prima del rilascio. La specifica definitiva conferma però dettagli tecnici che allora restavano ipotesi.
Le MRTR (Multi Round-Trip Requests) sostituiscono le vecchie richieste server-to-client con uno scambio a più round. Il routing passa da header obbligatori su ogni richiesta HTTP, Mcp-Method e Mcp-Name. Arriva anche una cache sui risultati delle liste di strumenti, con parametri di durata e ambito configurabili.
Nasce una struttura ufficiale di estensioni, che comprende MCP Apps, Tasks ed Enterprise Managed Authorization. Le funzioni superate (Roots, Sampling, Logging, il vecchio trasporto HTTP+SSE, la Dynamic Client Registration) restano attive per almeno 12 mesi prima della rimozione definitiva. È una finestra di transizione pensata apposta per chi ha già costruito integrazioni sulla versione precedente, datata novembre 2025.
Lo stato non scompare, cambia responsabile
Il blog ufficiale del progetto conferma senza equivoci: eliminare la sessione a livello di protocollo non rende automaticamente stateless l’applicazione che ci gira sopra. Se un server deve ricordare qualcosa tra una chiamata e l’altra, deve coniare un handle esplicito dentro un tool e far sì che sia il modello a riportarlo indietro come argomento alla chiamata successiva.
Tradotto per chi scrive le integrazioni: la complessità si sposta dall’infrastruttura di rete al design dei tool. Prima viveva nel problema del load balancer che smarriva la sessione; ora vive nella capacità del modello di trasportare correttamente un pezzo di informazione tra una chiamata e l’altra.
Il protocollo perde la memoria delle sessioni, il conto lo pagano gli sviluppatori.
Nasce così una superficie di rischio nuova, assente quando lo stato viveva nella sessione. Se il modello smarrisce l’handle, lo corrompe o lo passa al tool sbagliato, l’errore diventa un problema di affidabilità dell’agente, e ricade su chi ha progettato quel tool più che su chi gestisce l’infrastruttura.
Come funzionano le conferme senza una sessione aperta
MRTR procede per tentativi ripetuti: il server risponde con resultType: "input_required", il client richiama lo stesso metodo passando le risposte dentro inputResponses. È il pattern che sostituisce l’elicitation e la sampling, entrambe deprecate insieme alla connessione bidirezionale sempre aperta che richiedevano.
Il comunicato non enfatizza un dettaglio decisivo: una conferma umana prima di un’azione distruttiva, come la cancellazione di un set di dati, prima viveva dentro una sessione continuativa. Ora vive dentro un pattern di retry, che un client mal implementato può anche saltare senza che nulla nel protocollo lo impedisca davvero.
L’autenticazione enterprise arriva, ma dentro il prodotto del vendor
La domanda rimasta aperta una settimana prima del rilascio, come si gestisce l’autenticazione dei client su scala aziendale, trova ora una risposta soltanto parziale. Si chiama Enterprise Managed Authorization, ed è una delle tre estensioni ufficiali della nuova specifica.
Claude la implementa come provisioning dei connettori attraverso l’identity provider aziendale, Entra o Okta, senza intervento manuale dell’utente finale. Microsoft Foundry dà invece a ogni agente un’identità di prima classe dentro Entra ID: un principio che avevamo già raccontato parlando degli agenti come utenti ad alto rischio. Il punto critico è che si tratta di un’estensione, non del protocollo di base: ogni fornitore la implementa a modo suo, dentro il proprio prodotto.
La scalabilità reale passa dai cloud dei soliti nomi
L’elenco di chi ha aderito al giorno zero somiglia a un censimento degli hyperscaler e delle piattaforme di hosting agentico: AWS Bedrock AgentCore, Microsoft Foundry, Google Cloud, Cloudflare Workers, più Figma, Netlify, Zoom, Xero, Intuit, Honeycomb e Manufact. La stessa Claude conta oltre 950 server MCP nella propria directory di connettori, come annunciato, e ha aggiunto una funzione di tunnel per collegare server interni senza esporli su internet pubblico.
Honeycomb segnala che quasi il 20% delle proprie query mensili interattive è già generato da agenti, non da persone. Manufact riporta che la nuova versione degli SDK riduce le dimensioni del pacchetto di circa l’83% e lo rende un quarto più veloce.
L’apertura dello standard finisce spesso dentro il cloud di qualcun altro.
Chi ha già un contratto enterprise con uno di questi fornitori eredita gateway, gestione delle identità e osservabilità già pronti all’uso. Chi non ce l’ha deve costruire da solo lo stesso livello di infrastruttura che i grandi cloud offrono di serie ai propri clienti: la stessa dinamica per cui il fornitore diventa infrastruttura.
Più versatilità per gli agenti, più dipendenza dal fornitore
Il motivo per cui questa specifica viene festeggiata come un passo avanti sta altrove. Uno stato delegabile a un servizio gestito rende gli agenti più versatili: possono riprendere un lavoro interrotto giorni dopo, coordinare più sessioni parallele, ricordare il contesto di una conversazione senza tenere aperta una connessione costosa. È un guadagno reale, non solo marketing.
Quel guadagno però ha un prezzo strutturale, e non è solo tecnico. Delegare la persistenza dello stato significa aggiungere un fornitore cloud in più nella catena che fa funzionare l’agente: oltre al modello e al protocollo, ora contano anche chi conserva l’handle, chi lo rende disponibile quando serve, chi fattura quel servizio. Più un’azienda costruisce agenti che dipendono da memoria persistente gestita da terzi, più diventa difficile tornare indietro senza riscrivere l’architettura.
Meno stato nel protocollo, più responsabilità nel codice che scrive i tool.
E i prezzi dei servizi cloud, per esperienza già vissuta con lo storage e con il calcolo, tendono a salire quando l’uso diventa strutturale e la sostituzione diventa costosa. Oggi le tariffe per la gestione dello stato agentico sono ancora aggressive, pensate per catturare quota di mercato in una fase iniziale. Restano tali solo finché il mercato è ancora da conquistare: una volta che migliaia di aziende avranno costruito i propri flussi di lavoro su quell’infrastruttura, la leva negoziale cambia di mano.
Chi paga, chi decide, chi resta fuori
Paga chi ha già un server MCP proprietario costruito sulla versione stateful di novembre 2025: affronta 12 mesi di doppio binario e la riscrittura dei tool secondo il nuovo pattern degli handle espliciti. È un costo concreto per chi ha investito mesi di sviluppo su un’architettura che ora va rifatta in parte.
Decide chi scrive la specifica, e chi la rende immediatamente utilizzabile in azienda sono in buona parte lo stesso soggetto. I due lead maintainer del protocollo lavorano entrambi in Anthropic, che è anche il fornitore che ha spedito più in fretta il prodotto commerciale capace di sfruttare quell’estensione. Insieme ai due o tre hyperscaler arrivati pronti al giorno zero, sono loro a stabilire nella pratica cosa significhi essere conformi allo standard a livello enterprise.
Scrive la specifica chi vende anche il prodotto che la rende usabile.
Resta fuori chi non ha già un contratto enterprise con uno di quei fornitori, e deve costruire in autonomia gateway, isolamento dei tenant e identità degli agenti. È lo stesso vuoto di governance che avevamo segnalato a proposito degli accessi agentici: questa versione della specifica lo chiude solo per chi può permettersi la piattaforma giusta.
Un protocollo pensato per essere indipendente dal singolo fornitore arriva pronto per l’azienda quasi soltanto dentro l’infrastruttura gestita di quattro o cinque nomi, sempre gli stessi. È semplice economia di scala: chi ha già i data center, i sistemi di identità e i team di sicurezza pronti li mette a disposizione più in fretta di chiunque altro. Più memoria distribuita nel cloud significa agenti più capaci, e significa anche un fornitore in più a cui rispondere, con un conto che oggi sembra ragionevole e domani potrebbe non esserlo più.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Tom’s Hardware
Source link
