Il 28 luglio 2026 entra in vigore la nuova revisione della specifica Model Context Protocol (MCP), lo standard aperto introdotto da Anthropic che permette ai modelli AI di collegarsi in modo sicuro a strumenti e sorgenti dati esterne. Non si tratta di un aggiornamento cosmetico: la revisione 2026-07-28 ridisegna il nucleo del protocollo, passando da un modello con stato a uno completamente stateless, e introduce cambiamenti che toccano direttamente chi progetta, ospita o consuma server MCP in produzione.

Per chi lavora con agenti AI e integrazioni enterprise, questa è una di quelle revisioni che vale la pena capire in dettaglio prima che arrivi la versione finale, perché tocca scalabilità, autenticazione e compatibilità con le versioni precedenti.

Dal protocollo con stato al core stateless

Nelle versioni precedenti di MCP, un client doveva eseguire un handshake initialize prima di poter fare qualsiasi cosa: il server rispondeva con un identificatore di sessione da includere in ogni richiesta successiva. Chi ha provato a mettere in produzione un server MCP dietro un load balancer conosce il problema: il client restava “incollato” a una specifica istanza, e scalare orizzontalmente richiedeva sticky session o uno store di sessione condiviso.

La revisione 2026-07-28 elimina sia l’handshake initialize sia il concetto stesso di sessione a livello di protocollo. Ogni richiesta è ora autosufficiente: versione del protocollo, informazioni sul client e capability dichiarate viaggiano in ogni singola chiamata invece di essere negoziate una volta sola all’apertura della connessione. Un nuovo metodo, server/discover, permette al client di recuperare le capability del server solo quando gli servono davvero.

La conseguenza pratica è che, non esistendo più un identificatore di sessione, qualsiasi richiesta può essere instradata verso qualunque istanza del server. Diventa possibile piazzare un server MCP dietro un banale load balancer round-robin, senza sticky session né store condiviso. Se un’applicazione ha comunque bisogno di mantenere uno stato tra una chiamata e l’altra, la soluzione prevista è restituire un handle esplicito (ad esempio un ID di un “carrello” o di una sessione applicativa) da uno strumento, e far sì che il client lo passi indietro come un normale argomento nelle chiamate successive. È lo stesso pattern usato da anni nelle API REST stateless: lo stato non sparisce, si sposta semplicemente dal trasporto al payload applicativo.

Multi Round-Trip Requests: confermare senza tenere aperta una connessione

Un protocollo stateless ha comunque bisogno di un modo per gestire i casi in cui un server deve chiedere qualcosa al client a metà di una chiamata, per esempio una conferma dell’utente prima di eseguire un’operazione sensibile. Nelle versioni precedenti questo richiedeva tenere aperto uno stream Server-Sent Events per tutta la durata dell’interazione. La nuova revisione sostituisce questo meccanismo con le Multi Round-Trip Requests (MRTR).

Quando un server ha bisogno di input dall’utente durante l’esecuzione di uno strumento, restituisce un oggetto InputRequiredResult contenente le domande da porre e un blob requestState. Il client raccoglie le risposte e riemette la chiamata originale includendo sia le risposte sia lo stato “echoed” ricevuto in precedenza. Poiché tutto ciò che serve al server è contenuto nel payload, qualunque istanza del server può gestire il retry, anche se è diversa da quella che ha generato la richiesta iniziale. È un dettaglio che semplifica enormemente il deployment di server MCP dietro infrastrutture di bilanciamento del carico stateless.

Header instradabili e caching esplicito

Due modifiche più contenute a livello di trasporto rendono il traffico MCP molto più facile da osservare e instradare in produzione. Il trasporto Streamable HTTP richiede ora un header Mcp-Method su ogni richiesta, mentre l’header Mcp-Name è obbligatorio solo per tipi di richiesta specifici, come tools/call, resources/read e prompts/get. Un gateway o un load balancer può leggere questi header per instradare il traffico senza dover analizzare il corpo della richiesta, un vantaggio non trascurabile per chi gestisce infrastrutture MCP a scala aziendale. I server rifiutano le richieste in cui header e corpo non sono coerenti tra loro.

In secondo luogo, i risultati di liste e letture di risorse ora includono i campi ttlMs e cacheScope, modellati sul comportamento dell’header HTTP Cache-Control. I client sanno esattamente per quanto tempo una risposta a tools/list resta valida e se può essere condivisa tra utenti diversi. Non è più necessario mantenere uno stream a lungo termine solo per scoprire che una lista è cambiata: un pattern di polling con cache esplicita è sufficiente.

Autenticazione più rigorosa, allineata a OAuth 2.0

La revisione stringe le regole di autorizzazione per allinearle più da vicino a OAuth 2.0 e OpenID Connect. I client devono ora validare il parametro iss nelle risposte di autorizzazione secondo la RFC 9207, una mitigazione contro i “mix-up attack”, una classe di attacchi più rilevante nel pattern tipico di MCP in cui un singolo client dialoga con molti server diversi.

I client devono inoltre dichiarare il proprio application_type durante la Dynamic Client Registration, così gli authorization server non assumono più di default che i client desktop o CLI siano applicazioni “web”, evitando il rifiuto ingiustificato dei redirect URI su localhost. Le credenziali vengono vincolate all’authorization server che le ha emesse, e la specifica chiarisce come richiedere i refresh token durante l’autenticazione step-up.

Funzionalità deprecate: cosa cambia per chi ha già integrato MCP

Tre funzionalità core vengono formalmente deprecate: Roots, Sampling e Logging. Roots permetteva a un client di dichiarare i confini del filesystem a un server; Sampling permetteva a un server di chiedere al modello del client di generare testo per suo conto; Logging forniva notifiche a livello di protocollo dal server al client.

La deprecazione non significa rimozione immediata: questi metodi, tipi e capability flag continuano a funzionare in questa release e in ogni versione della specifica pubblicata entro un anno da essa. Da qui in poi, però, sono su un orologio di rimozione. Le alternative consigliate sono parametri degli strumenti o URI di risorse al posto di Roots, integrazione diretta con le API dei provider LLM al posto di Sampling, e OpenTelemetry per l’osservabilità strutturata al posto del Logging di protocollo. Chi mantiene librerie o server MCP dovrebbe iniziare a pianificare la migrazione già da ora.

Schema degli strumenti, codici di errore ed estensioni

Gli schema di input e output degli strumenti utilizzano ora JSON Schema 2020-12 completo. Gli schema di input mantengono il vincolo della radice type: "object" ma ora permettono composizione con oneOf, anyOf e allOf, oltre a condizionali e riferimenti. Gli schema di output non hanno più restrizioni, e structuredContent può essere qualsiasi valore JSON, non solo un oggetto.

Il codice di errore per una risorsa mancante cambia dal valore custom MCP -32002 allo standard JSON-RPC -32602 (Invalid Params). Chi ha client che fanno pattern matching sul valore letterale -32002 deve aggiornare quel codice prima del 28 luglio.

Le estensioni, già presenti nella release precedente ma senza un processo formale, ricevono ora una struttura definita: sono identificate da ID reverse-DNS, negoziate tramite una mappa extensions, e vivono in repository indipendenti con maintainer dedicati, versionando separatamente dalla specifica principale. Due estensioni ufficiali arrivano con questa release: MCP Apps, che permette ai server di fornire interfacce HTML interattive renderizzate dagli host in un iframe sandboxed, e Tasks, promossa da funzionalità sperimentale a estensione ufficiale, che fornisce un modello stateless per lavori a lunga esecuzione: un server può rispondere a tools/call con un task handle, e il client lo gestisce con tasks/get, tasks/update e tasks/cancel.

SDK beta disponibili da subito

Sono già disponibili release beta degli SDK Python, TypeScript, Go e C#. Python v2 rinomina FastMCP in MCPServer ma mantiene l’API a decoratori. TypeScript v2 divide l’SDK monolitico in pacchetti focalizzati come @modelcontextprotocol/server e @modelcontextprotocol/client, ed è ora ESM-only. Go integra il supporto alla revisione 2026-07-28 in v1.7.0-pre.1 sullo stesso module path. C# rilascia la versione 2.0.0-preview.1 dei pacchetti ModelContextProtocol.

Per chi ha già server e client in produzione, la buona notizia è che nulla si rompe automaticamente il giorno del rilascio: i nuovi client che parlano la revisione 2026-07-28 tornano automaticamente all’handshake initialize quando raggiungono un server che implementa una versione precedente o uguale al 2025-11-25. Chi però pubblica librerie che dipendono dal pacchetto Python mcp dovrebbe aggiungere un limite superiore esplicito, per esempio mcp>=1.27,<2, in modo che il passaggio alla v2 stabile non colga di sorpresa gli utenti del proprio pacchetto.

Conclusione

La revisione 2026-07-28 di MCP è un cambiamento strutturale, non un semplice aggiornamento incrementale. Il core stateless elimina la necessità di session affinity e semplifica scaling orizzontale e load balancing di server MCP in produzione. I nuovi pattern come le MRTR e gli header instradabili rendono il protocollo più facile da operare su larga scala. L’irrigidimento delle regole di autorizzazione allinea MCP alle pratiche standard di OAuth e OpenID Connect, riducendo la superficie di attacco tipica delle integrazioni multi-server. Le funzionalità deprecate restano funzionanti per ora, ma vanno sostituite secondo un piano preciso prima che scada la finestra di un anno.

Chi sviluppa o ospita server MCP dovrebbe testare gli SDK beta contro i propri carichi di lavoro prima della data finale del 28 luglio, verificando in particolare la gestione dei codici di errore, la compatibilità dei client con l’handshake legacy e l’impatto delle nuove regole di autorizzazione sulle integrazioni desktop e CLI esistenti.

Fonte: 4sysops.com