Il protocollo degli agenti AI diventa stateless: la revisione MCP del 28 luglio apre la fase enterprise

Il 28 luglio 2026 la Agentic AI Foundation, il fondo della Linux Foundation che ospita il Model Context Protocol insieme a goose e AGENTS.md, ha pubblicato la revisione 2026-07-28 della specifica. I manutentori la descrivono come la revisione più ampia dal lancio del protocollo, e il motivo sta in una sola riga del changelog: il livello di protocollo diventa stateless.

La sessione era il pezzo di infrastruttura che teneva insieme gli agenti e gli strumenti aziendali: da oggi quel peso torna al livello applicativo, e un server MCP scala come un servizio web qualunque.

Cosa cambia davvero

Fino a ieri ogni deployment MCP in produzione portava con sé un corredo di infrastruttura dedicato: routing sticky sul load balancer, store di sessione condiviso su Redis, ispezione del corpo delle richieste al gateway per estrarre l'identificativo di sessione. Tutto questo serviva a tenere in vita un oggetto, la sessione MCP, che il protocollo dava per necessario.

La revisione 2026-07-28 lo elimina. Insieme alla sessione sparisce l'handshake initialize, il giro di negoziazione che apriva ogni conversazione fra client e server. Il risultato pratico è diretto: un server MCP oggi scala su un load balancer round-robin qualunque, come un normale servizio HTTP.

Attorno a questa scelta ruotano le altre novità. I risultati delle liste e delle letture di risorse trasportano ora ttlMs e cacheScope, modellati sul Cache-Control di HTTP: le risposte diventano cacheabili, il carico sui server cala. I Multi Round-Trip Requests aprono uno spazio nuovo alle interazioni dal server verso il client. Il routing passa dagli header, il posto dove i gateway aziendali sanno già leggere.

Le funzionalità che escono di scena

Tre feature del nucleo storico entrano in deprecazione: Roots, Sampling e Logging. La Dynamic Client Registration cede il passo a CIMD, pur restando operativa per retrocompatibilità. La specifica introduce insieme una Feature Lifecycle and Deprecation Policy che garantisce almeno dodici mesi fra l'annuncio di deprecazione e la rimozione effettiva. È la promessa di stabilità che le piattaforme aziendali chiedevano da mesi, e vale quanto le novità tecniche.

Sul fronte autorizzazione, la SEP 2468 impone l'inclusione e la verifica del parametro iss nelle risposte di autorizzazione, difesa diretta contro gli OAuth Mixup Attack. L'allineamento complessivo va verso le pratiche enterprise consolidate di OAuth 2.0 e OpenID Connect.

Il prezzo di questa maturazione è la compatibilità. Un server sulla revisione 2026-07-28 può risultare incompatibile con client più vecchi, e viceversa: le due parti devono condividere un'era di protocollo supportata, oppure una delle due deve implementare un fallback deliberato o un livello di traduzione.

Perché conta per chi guida la trasformazione in Italia

Il calendario aiuta a misurare la portata. MCP nasce a fine 2024 come formato per collegare un modello agli strumenti sulla macchina di uno sviluppatore. Diciotto mesi dopo è passato sotto la governance di una fondazione, ha un ciclo di vita delle feature scritto nero su bianco e un modello di autorizzazione che parla la lingua degli identity provider aziendali. Gartner stima che entro la fine del 2026 il 40 % delle applicazioni enterprise includerà agenti task-specific e che il 75 % dei vendor di API gateway offrirà funzionalità MCP: la specifica pubblicata ieri è il testo su cui quei prodotti verranno costruiti.

I fornitori si sono mossi in anticipo. AWS ha annunciato che per i clienti di AgentCore Gateway adottare la revisione 2026-07-28 è una modifica di configurazione: basta aggiungerla alla lista supportedVersions con una singola chiamata UpdateGateway, il gateway serve più versioni di protocollo in parallelo. Cloudflare dichiara supporto dal giorno zero nel proprio Agents SDK, con i server MCP eseguiti direttamente nei Workers.

Per un CIO italiano che ha portato agenti in esercizio negli ultimi dodici mesi, la conseguenza operativa è concreta. La finestra di doppia versione offerta dal gateway diventa il fattore che rende la migrazione graduale invece che a strappo. E l'infrastruttura costruita per sostenere le sessioni, sticky routing e store condivisi, torna disponibile per altro appena la migrazione è chiusa.

Le mosse sul tavolo

Cinque azioni valide a prescindere dal fornitore scelto.

Inventario del parco MCP. Elencare server e client in esercizio annotando per ciascuno la revisione di protocollo dichiarata. È il documento su cui si costruisce tutto il resto.
Mappa delle dipendenze deprecate. Individuare cosa poggia su Roots, Sampling o Logging. I dodici mesi garantiti dalla nuova policy sono tempo di lavoro, e conviene spenderlo subito.
Domanda al fornitore del gateway. Chiedere per iscritto quale finestra di doppia versione viene garantita e per quanto. La risposta determina il calendario di migrazione interno.
Revisione della configurazione OAuth. Allineare i client alla SEP 2468 con verifica del parametro iss, insieme al resto delle pratiche OAuth 2.0 e OpenID Connect già in casa.
Ricalcolo dell'infrastruttura. Quantificare quanto costa oggi il corredo sessioni, per liberarlo a migrazione completata e riportare quel budget dove serve.

Resta una domanda aperta sul mercato. Un protocollo che diventa stateless e passa sotto governance di fondazione somiglia molto al percorso che HTTP ha fatto trent'anni fa. La differenza è la velocità: qui la stabilizzazione arriva mentre l'adozione è già di massa, con agenti in produzione che dovranno migrare in corsa. Il modo in cui i vendor gestiranno questa finestra dirà molto sulla maturità reale del settore.

Autore

Pablo Liuzzi

Founder, Synthos Logic