Sommario
- Cosa vuol dire stateless, in concreto
- MRTR, quando è il server ad aver bisogno di qualcosa
- Roots, Sampling e Logging deprecate
- Tre strette sull’autorizzazione
- Quello che si perde per strada
- Una politica di deprecazione, non solo una release
- Cosa cambia per chi ha un server in produzione
- Cosa ne pensiamo
- Fonti
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Il 28 luglio il Model Context Protocol ha pubblicato la revisione 2026-07-28, la prima dopo la 2025-11-25 e la prima da quando il progetto sta sotto la Agentic AI Foundation della Linux Foundation. Il cambiamento che dà il titolo alla release è uno: il protocollo diventa stateless.
Per chi ha un server MCP in produzione non è un aggiornamento di versione, è una migrazione.
Cosa vuol dire stateless, in concreto
Spariscono due cose che c’erano da sempre. L’handshake initialize con la notifica notifications/initialized, e l’header Mcp-Session-Id dello Streamable HTTP.
Al loro posto ogni richiesta porta con sé quello che serve, dentro _meta: la versione del protocollo, le capacità del client e l’identità di chi chiama. I server dichiarano la propria identità nel _meta di ogni risposta, e una versione incompatibile torna come UnsupportedProtocolVersionError. È il SEP-2575, affiancato dal SEP-2567 che toglie le sessioni dal trasporto.
I server che hanno bisogno di ricordare qualcosa fra una chiamata e l’altra ora lo fanno con handle emessi dal server e passati come normali argomenti dei tool. Lo stato non sparisce, cambia posto: da implicito nel trasporto a esplicito nella firma della funzione.
La conseguenza operativa è quella che il progetto indica come la richiesta più frequente arrivata dagli sviluppatori: qualsiasi richiesta può atterrare su qualsiasi istanza, quindi un server MCP sta dietro un load balancer round robin come un servizio HTTP qualunque, senza sticky session e senza affinità.
Arriva server/discover, che i server devono implementare per dichiarare versioni supportate, capacità e identità. Un client può chiamarlo prima di tutto per scegliere la versione, oppure usarlo come sonda di compatibilità su stdio.
Le POST dello Streamable HTTP devono portare gli header Mcp-Method e Mcp-Name (SEP-2243). Servono ai gateway per instradare e contare senza aprire il corpo JSON, che è la differenza fra un proxy che legge un header e uno che deserializza ogni chiamata.
I risultati di tools/list, prompts/list, resources/list, resources/read e resources/templates/list devono portare ttlMs e cacheScope (SEP-2549). Il primo dice per quanto il dato resta fresco, il secondo se un intermediario condiviso può tenerlo in cache. Nella stessa direzione va la raccomandazione di restituire i tool in ordine deterministico, che serve a far funzionare le cache dei prompt lato modello.
Cambia anche il codice di errore per risorsa non trovata, che passa da -32002 a -32602, il valore che JSON-RPC usa per i parametri non validi.
MRTR, quando è il server ad aver bisogno di qualcosa
Finora, quando un server doveva chiedere qualcosa al client (le directory con roots/list, un’inferenza con sampling/createMessage, un dato all’utente con elicitation/create) apriva una richiesta in direzione opposta, e per farlo serviva uno stream persistente.
Il pattern nuovo si chiama Multi Round-Trip Requests (SEP-2322) e rovescia il verso. Il server restituisce un InputRequiredResult con resultType: "input_required", e nel campo inputRequests mette quello che gli manca. Il client rifà la stessa richiesta allegando inputResponses. Niente canale aperto, solo una domanda che torna indietro dentro una risposta.
Da qui la conseguenza che tocca tutti i risultati: ognuno ora porta un campo resultType obbligatorio, "complete" oppure "input_required". I client devono trattare come completi i risultati dei server su versioni precedenti che quel campo non lo mandano, che è il modo in cui la revisione resta compatibile all’indietro.
Roots, Sampling e Logging deprecate
Tre funzionalità passano allo stato deprecato con il SEP-2577. Restano funzionanti per tutta la finestra, ma le nuove implementazioni non dovrebbero adottarle. Le migrazioni suggerite dal progetto:
| Deprecata | Al suo posto |
|---|---|
| Roots | directory e file passati come parametri dei tool, URI di risorsa o configurazione del server |
| Sampling | integrazione diretta con le API del provider LLM |
| Logging | scrittura su stderr in stdio, oppure OpenTelemetry |
La riga che pesa di più è Sampling, ed è la meno visibile nel changelog. Era la primitiva con cui il server chiedeva al client di far girare un’inferenza con il modello che il client aveva già configurato: un server MCP poteva usare l’LLM senza avere una chiave, senza un contratto con un provider e senza pagare i token. Toglierla sposta quella responsabilità, e quel costo, su chi il server lo costruisce.
Deprecata anche la Dynamic Client Registration di RFC 7591 come meccanismo di registrazione, a favore dei Client ID Metadata Documents. Resta disponibile per compatibilità con gli authorization server che i CIMD non li supportano.
Tre strette sull’autorizzazione
Sono modifiche minori nella classificazione del changelog, meno minori per chi espone un server MCP su internet.
L’authorization server dovrebbe includere il parametro iss nelle risposte di autorizzazione, secondo RFC 9207, e il client deve validarlo contro l’issuer registrato prima di riscattare il codice (SEP-2468).
Il client deve dichiarare un application_type appropriato durante la registrazione dinamica, per evitare i conflitti sui redirect URI di OpenID Connect (SEP-837).
Le credenziali sono legate all’authorization server che le ha emesse: vanno indicizzate per identificativo dell’issuer, non vanno riusate con un altro authorization server, e quando l’authorization server cambia bisogna registrarsi di nuovo (SEP-2352).
Quello che si perde per strada
La resumability degli stream sparisce: via l’header Last-Event-ID e gli id degli eventi SSE. Uno stream che si rompe perde la richiesta in volo, e il client deve rifarla da capo con un id nuovo. Su chiamate lunghe, e su reti mobili, si paga in lavoro ripetuto.
L’endpoint HTTP GET e la coppia resources/subscribe e resources/unsubscribe lasciano il posto a subscriptions/listen, un unico stream su risposta POST a cui il client si iscrive dichiarando quali notifiche vuole.
Escono ping, logging/setLevel e notifications/roots/list_changed. Il livello di log si imposta per singola richiesta con io.modelcontextprotocol/logLevel dentro _meta, e i server non devono emettere notifications/message per le richieste che quel campo non lo portano.
I task escono dal core e diventano l’estensione ufficiale io.modelcontextprotocol/tasks (SEP-2663). Il tasks/result bloccante lascia il posto al polling con tasks/get, arriva tasks/update per mandare dati dal client al server, e tasks/list viene rimosso.
Il trasporto HTTP+SSE, deprecato già dalla 2025-03-26, viene riclassificato come deprecato sotto la nuova politica.
Una politica di deprecazione, non solo una release
Insieme alla revisione il progetto ha adottato una politica di ciclo di vita delle funzionalità (SEP-2596): tre stati dichiarati (Active, Deprecated, Removed), una finestra minima di dodici mesi prima che una funzionalità deprecata possa essere rimossa e un registro pubblico che tiene traccia di tutto ciò che è in stato deprecato. In parallelo il processo delle SEP diventa file markdown nella cartella seps/, con numerazione derivata dalla pull request e responsabilità esplicite per gli sponsor (SEP-1850).
Per chi deve mettere MCP dentro un piano a due anni questa è la parte con gli effetti più lunghi. Sapere che una funzionalità deprecata resta in piedi almeno dodici mesi, e che l’elenco di cosa è deprecato sta in un registro pubblico invece che in un thread, cambia il tipo di decisione che si può prendere.
Sull’adozione, il post di annuncio dichiara che i quattro SDK di primo livello (TypeScript, Python, Go, C#) supportano già la revisione, che quello Rust la supporta in beta, e che gli SDK di primo livello messi insieme sfiorano il mezzo miliardo di download al mese, con TypeScript e Python che superano ciascuno il miliardo di download complessivi. Sono numeri del progetto, senza verifiche di terzi.
Cosa cambia per chi ha un server in produzione
Se un gateway instrada o conta sulla base di Mcp-Session-Id, quella logica va riscritta sugli header Mcp-Method e Mcp-Name. Se il server si aspetta initialize come primo messaggio, i client aggiornati non lo mandano più. Se lo stato viveva nella sessione, va spostato in handle espliciti passati come argomenti. Se il server usa Sampling, serve un piano per l’integrazione diretta con un provider, con la chiave e il costo che ne conseguono. Se qualcosa dipendeva dalla ripresa degli stream interrotti, va gestito con il ritentativo.
La revisione precedente non si spegne, e il changelog prevede esplicitamente il caso dei server su versioni più vecchie: server/discover funziona anche come sonda di compatibilità e i risultati senza resultType si leggono come completi.
Cosa ne pensiamo
MCP nasce a fine novembre 2024 come protocollo bidirezionale con stato, pensato per un agent che parla con un server sulla stessa macchina. La revisione 2026-07-28 lo trasforma in un protocollo richiesta e risposta che sta dietro un bilanciatore, con header di instradamento, cache dichiarate e credenziali legate all’issuer. È il percorso che fa un pezzo di software quando smette di girare su un portatile e comincia a stare in produzione per conto di qualcun altro.
Il prezzo è dichiarato ed è pagabile: una migrazione vera, la resumability persa e tre primitive del disegno originale che escono di scena. La finestra di dodici mesi è quello che rende la deprecazione di Sampling una cosa da mettere in un backlog invece che un’emergenza.
Resta il punto che vale per tutti i protocolli aperti in questa fase, A2A compreso: la parte difficile non è la specifica, è quello che le sta attorno. Governance dichiarata, finestre di deprecazione, registri pubblici. È la stessa questione che si pone per la governance degli agenti, e su cui si misura se un progetto è adottabile da un’azienda che deve rispondere di quello che manda in produzione.