MCP 2026-07-28: la spec diventa stateless, cosa si rompe

Il 28 luglio 2026 il Model Context Protocol pubblica la revisione 2026-07-28. I maintainer la definiscono la revisione più grande del protocollo dal lancio, e contiene breaking change.

Se hai un server MCP in produzione, questa non è una release da leggere con calma a settembre. Il cambiamento centrale è che MCP diventa stateless a livello di protocollo: spariscono l'handshake initialize e l'header Mcp-Session-Id. Sono le due cose su cui probabilmente si regge il tuo transport layer oggi.

In questa guida vediamo cosa cambia esattamente, cosa si rompe, cosa è solo deprecato e cosa devi fare sul tuo server. Scrivo da chi gestisce mcp.cosimo.dev in produzione e sta pianificando la stessa migrazione.

Prima cosa: 2026-07-28 è una versione, non una data di pubblicazione

Partiamo da un equivoco che vedo circolare. MCP usa identificatori di versione nel formato YYYY-MM-DD che indicano l'ultima data in cui sono state introdotte modifiche non retrocompatibili. Non è il giorno in cui è uscito un post sul blog.

Lo stato al momento in cui scrivo:

• Versione finalizzata attuale: 2025-11-25. È quella su cui gira il tuo server oggi.
• Release candidate: bloccata il 21 maggio 2026.
• Pubblicazione finale: 28 luglio 2026.

Le dieci settimane tra RC e finale sono una finestra di validazione per i manutentori degli SDK e gli implementatori dei client. Gli SDK ufficiali di primo livello sono attesi con il supporto entro quella finestra.

Tutto quello che segue descrive la release candidate: fino al 28 luglio i dettagli possono ancora cambiare.

Cosa si rompe e cosa no: la tabella che serve davvero

Prima dei dettagli, il quadro operativo. Non tutto quello che cambia ti costringe a riscrivere codice.

Breaking: richiede intervento

• Sessioni e header Mcp-Session-Id — Rimossi dal transport Streamable HTTP. Devi abbandonare gli store di sessione condivisi e passare a handle espliciti.
• Handshake initialize — Rimosso. Versione di protocollo e capability vanno lette da _meta su ogni richiesta, e devi implementare server/discover.
• tasks/result bloccante — Solo se usi Tasks: si passa all'estensione e al polling via tasks/get.
• Codice errore risorsa mancante — Passa dal custom -32002 allo standard JSON-RPC -32602. Se il tuo client fa match sul valore letterale, va aggiornato.

Deprecato: hai almeno dodici mesi

• Roots, Sampling e Logging — Deprecati, non rimossi. Restano nella specifica e continuano a funzionare.
• Transport HTTP+SSE — Riclassificato come deprecato. Si migra a Streamable HTTP dentro la finestra di deprecazione.

Compatibile: campi nuovi, nessuna rottura

• tools/list, resources/list, prompts/list — Continuano a funzionare, ma non variano più per connessione e guadagnano i campi ttlMs e cacheScope per abilitare il caching.

Il cuore della release: il protocollo diventa stateless

Sei Specification Enhancement Proposal lavorano insieme per arrivarci. Due portano quasi tutto il peso.

Prima: la sessione ti incollava a un'istanza

Con 2025-11-25, chiamare un tool su Streamable HTTP significa prima stabilire una sessione. Il server risponde con un Mcp-Session-Id che ogni richiesta successiva deve trasportare, e questo vincola il client all'istanza che l'ha emesso.

Da qui derivano tutti i mal di testa infrastrutturali che conosci: sticky session sul load balancer, uno store di sessione condiviso tra le istanze, ispezione del corpo della richiesta sul gateway per capire cosa sta passando.

Dopo: ogni richiesta è autosufficiente

Con 2026-07-28, la stessa chiamata è una singola richiesta completa che qualunque istanza del server può gestire. Le informazioni che prima si scambiavano una volta sola in fase di connessione — versione del protocollo, identità e capability del client — ora viaggiano in _meta su ogni richiesta.

Al posto dell'handshake arriva un nuovo metodo server/discover, che i server devono implementare: espone versioni supportate, capability e identità. I client possono chiamarlo per selezionare la versione in anticipo.

Il guadagno operativo è immediato: un server MCP remoto che prima aveva bisogno di sticky session, store condiviso e deep packet inspection ora gira dietro un normale load balancer round-robin.

Protocollo stateless non significa applicazione stateless

Questo è il punto che genera più confusione, e vale la pena chiarirlo bene.

Togliere la sessione dal protocollo non ti obbliga a rendere stateless la tua applicazione. I server che devono mantenere stato tra le chiamate fanno quello che le API HTTP hanno sempre fatto: emettono un handle esplicito — un basket_id, un browser_id — da un tool, e il modello lo ripassa come normale argomento nelle chiamate successive.

Nella pratica questo pattern è spesso migliore della sessione: il modello può comporre gli handle tra tool diversi, ragionarci sopra e passarli tra i passaggi di un flusso. Lo stato diventa visibile al modello invece di restare nascosto nei metadati del transport.

Header, routing e caching: le tre modifiche operative

Tre cambiamenti minori rendono il traffico molto più gestibile in produzione.

Header obbligatori per il routing

Il transport Streamable HTTP ora richiede gli header Mcp-Method e Mcp-Name sulle richieste POST. Load balancer, gateway e rate limiter possono così instradare sull'operazione senza ispezionare il corpo. I server rifiutano le richieste dove header e body non concordano.

Se hai un gateway davanti al server, è qui che devi intervenire: si passa dal routing per affinità di sessione al routing per header.

Caching delle liste

I risultati di tools/list, prompts/list, resources/list e le letture di risorse ora portano due campi modellati su Cache-Control di HTTP:

• ttlMs — Per quanti millisecondi la risposta è considerata fresca.
• cacheScope — public o private: dice se intermediari condivisi possono mettere in cache la risposta.

In un protocollo dove le liste non variano più per connessione, il caching è il modo con cui i client evitano di riscaricare lo stesso catalogo di tool a ogni chiamata. Non sostituisce le notifiche listChanged: le affianca.

Tracciamento distribuito

La propagazione del W3C Trace Context in _meta è ora documentata, con i nomi delle chiavi traceparent, tracestate e baggage fissati nella specifica. Una traccia che parte dall'applicazione host può seguire la chiamata attraverso client SDK, server MCP e servizi a valle, e apparire come un unico albero di span in un backend compatibile con OpenTelemetry.

Elicitation e sampling: il pattern Multi Round-Trip

Un protocollo stateless ha comunque bisogno di un modo per chiedere qualcosa all'utente a metà di un'operazione. Qui la ristrutturazione è profonda.

Prima regola nuova: le richieste iniziate dal server possono essere emesse solo mentre il server sta elaborando una richiesta del client. Nelle versioni precedenti era una raccomandazione, ora è un obbligo. L'utente non riceve mai un prompt dal nulla, e ogni elicitation è tracciabile a qualcosa che lui o il suo agente hanno avviato.

Cambia poi il meccanismo di consegna. Invece di tenere aperto uno stream SSE, il server restituisce un InputRequiredResult:

• Una chiamata a tools/call, prompts/get o resources/read può terminare con un risultato di tipo input_required invece di completarsi.
• Quel risultato porta inputRequests, una mappa delle richieste che il client deve soddisfare, più uno requestState opaco da rimandare indietro immutato.
• Il client raccoglie le risposte e riemette la chiamata originale con inputResponses e lo requestState restituito.

Poiché tutto lo stato viaggia nel payload, qualunque istanza può riprendere il lavoro. Un singolo InputRequiredResult può anche raggruppare una elicitation e una richiesta di sampling in un solo giro.

Le estensioni diventano cittadini di prima classe

Le estensioni esistevano già in 2025-11-25, ma senza un processo formale dietro. Ora ce l'hanno: sono identificate da ID in formato reverse-DNS, negoziate attraverso una mappa extensions nelle capability di client e server, vivono in repository dedicati con manutentori delegati e versionano indipendentemente dalla specifica.

MCP Apps: interfacce HTML renderizzate dal server

MCP Apps permette ai server di distribuire interfacce HTML interattive che gli host renderizzano in un iframe in sandbox. I tool dichiarano in anticipo i propri template UI, così gli host possono precaricarli, metterli in cache e sottoporli a revisione di sicurezza prima che qualcosa venga eseguito.

Il dettaglio che conta per la sicurezza: la UI comunica con l'host sullo stesso protocollo JSON-RPC usato ovunque in MCP, quindi ogni azione avviata dall'interfaccia passa dallo stesso percorso di audit e consenso di una normale chiamata a tool. Ne ho parlato più diffusamente nella guida su MCP Apps e Claude come workspace.

Tasks diventa estensione

Tasks era arrivato come funzionalità core sperimentale in 2025-11-25. L'uso in produzione ha fatto emergere abbastanza problemi da spostarlo fuori dal protocollo, in un'estensione ufficiale. Il ridisegno:

• Sostituisce il metodo bloccante tasks/result con il polling via tasks/get.
• Aggiunge tasks/update per l'input dal client al server.
• Rimuove tasks/list, perché senza sessioni non può essere delimitato in modo sicuro.
• Rende la creazione dei task diretta dal server: il client dichiara l'estensione, il server decide quando una chiamata deve girare come task.

Chi ha sviluppato sulla API Tasks sperimentale dovrà migrare al nuovo ciclo di vita. È l'unica migrazione davvero invasiva della release, ma riguarda una minoranza di implementazioni.

Autorizzazione: sei SEP per allinearsi a OAuth reale

La specifica di autorizzazione viene irrigidita per avvicinarsi a come OAuth 2.0 e OpenID Connect vengono realmente distribuiti.

Il cambiamento più concreto: i client devono ora validare il parametro iss nelle risposte di autorizzazione secondo RFC 9207. È una mitigazione a basso costo per una classe di attacchi mix-up più probabile proprio nello schema di MCP, dove un singolo client parla con molti server. In una versione futura i client dovranno rifiutare le risposte che omettono iss: se gestisci un authorization server, conviene iniziare a fornirlo da subito.

Altre modifiche utili se hai sbattuto la testa su questi problemi: i client dichiarano il proprio application_type OpenID Connect durante la Dynamic Client Registration, evitando il caso classico in cui l'authorization server assume "web" per un client desktop o CLI e ne rifiuta il redirect URI su localhost.

La policy di deprecazione: finalmente c'è

Per la prima volta MCP adotta un ciclo di vita formale delle funzionalità, con tre stati: Active, Deprecated, Removed.

La garanzia che conta: una funzionalità deve restare Deprecated per almeno dodici mesi, misurati dal rilascio della revisione che la marca come tale, prima di poter essere rimossa. C'è una sola eccezione, per rimozioni accelerate dovute a un avviso di sicurezza pubblicato o a sfruttamento attivo senza mitigazione: anche in quel caso servono almeno novanta giorni.

Perché è importante per chi costruisce per i clienti: significa che puoi promettere una finestra di manutenzione prevedibile. Fino a ieri non era possibile.

Schema dei tool: JSON Schema 2020-12 completo

Gli schemi inputSchema e outputSchema dei tool salgono a JSON Schema 2020-12 completo. Gli schemi di input mantengono il vincolo di radice type: "object", ma ora ammettono composizione (oneOf, anyOf, allOf), condizionali e riferimenti ($ref, $defs). Gli schemi di output non hanno restrizioni.

Due avvertenze dalla specifica: le implementazioni non devono dereferenziare automaticamente $ref esterni, e dovrebbero limitare profondità e tempo di validazione degli schemi. Sono entrambe superfici di attacco.

Cosa fare sul tuo server: la checklist

Se mantieni un server MCP, ecco l'ordine in cui affronterei il lavoro.

• 1. Leggi il changelog della draft — Prima di toccare codice, guarda l'elenco completo delle modifiche rispetto a 2025-11-25.
• 2. Censisci le dipendenze dalla sessione — Cerca ogni punto dove il server si appoggia a Mcp-Session-Id o a stato costruito durante initialize. Sono i punti da riprogettare con handle espliciti.
• 3. Implementa server/discover — È obbligatorio nella nuova revisione.
• 4. Sposta la lettura di versione e capability su _meta — Su ogni richiesta, non più una volta sola.
• 5. Aggiungi ttlMs e cacheScope ai risultati di list e read. È il modo per non farti martellare di richieste identiche.
• 6. Aggiorna il gateway — Routing su Mcp-Method e Mcp-Name invece che su affinità di sessione.
• 7. Se usi Tasks — Migra all'estensione e passa dal blocking al polling.
• 8. Cerca -32002 nel codice client — Va sostituito con -32602.

Una nota di realismo: non è urgente questa settimana. La versione finalizzata resta 2025-11-25 fino al 28 luglio, la policy di deprecazione compra almeno dodici mesi per tutto ciò che viene messo in pensione, e gli SDK stanno ancora validando. La mossa giusta oggi è leggere il changelog, seguire il lavoro sugli SDK ed evitare di costruire nuove dipendenze forti su ciò che la RC deprecha.

Cosa significa per chi integra AI nelle aziende

Se sviluppi integrazioni AI per clienti, questa release ha due implicazioni commerciali concrete.

La prima è positiva: il costo infrastrutturale di un server MCP remoto scende. Senza sticky session e store condiviso, ospitare un server multi-tenant diventa molto più semplice ed economico. Per chi propone sviluppo di web app e integrazioni AI a PMI, è un abbassamento reale della barriera d'ingresso.

La seconda richiede attenzione: se hai consegnato integrazioni MCP a clienti negli ultimi mesi, quelle integrazioni avranno bisogno di manutenzione. Vale la pena avvisarli adesso, con un piano, invece di scoprirlo quando qualcosa smette di funzionare. È anche un'occasione per un contratto di manutenzione, se non ce l'hai già.

Vale la pena ricordare, per inciso, che dal 2 agosto scattano gli obblighi di trasparenza dell'AI Act: se stai comunque mettendo mano ai tuoi sistemi AI in queste settimane, conviene chiudere i due cantieri insieme.

Leggi anche

• Model Context Protocol (MCP): Guida Completa 2026
• MCP Apps: Claude Diventa un Workspace Completo
• Agenti AI per Aziende: Guida Completa e Pratica
• Claude Code Cheatsheet 2026: Guida Completa per Sviluppatori
• AI Act dal 2 agosto 2026: cosa cambia davvero per le PMI

Conclusione: una rottura pulita, per non doverne fare altre

I maintainer sono espliciti sul fatto che i breaking change non sono destinati a diventare la norma. Il lavoro sullo stateless è il tipo di modifica fondazionale che richiedeva una rottura netta; con quella fatta, e con finestre di deprecazione ed estensioni come strumenti standard d'ora in poi, l'aspettativa è che chi punta a 2026-07-28 possa adottare le revisioni future senza riscrivere il transport o il codice del ciclo di vita.

Tradotto per chi lavora: la migrazione che farai in questi mesi dovrebbe essere l'ultima di questo tipo per parecchio tempo. È un buon motivo per farla bene invece che in fretta.

Hai un server MCP in produzione o stai valutando di esporre i tuoi sistemi aziendali via MCP e vuoi capire cosa comporta questa migrazione nel tuo caso specifico? Scrivimi: ci ragioniamo sopra partendo dalla tua architettura reale.