MCP stateless (spec 2026-07-28)
La trasformazione del Model Context Protocol da protocollo stateful a protocollo request/response stateless introdotta dalla spec del 28 luglio 2026.
MCP stateless (spec 2026-07-28) indica la versione del Model Context Protocol in cui ogni richiesta contiene le informazioni necessarie per essere elaborata. Il server non deve più ricordare una sessione aperta in precedenza. La release, chiamata informalmente «MCP 2.0», punta soprattutto a rendere i server remoti più semplici da distribuire e scalare.1
Il prima e il dopo
Nelle versioni precedenti, il client inviava prima initialize per aprire una sessione. Riceveva un identificatore, Mcp-Session-Id, da allegare alle chiamate successive. Se il servizio girava su più macchine, tutte le richieste di quella sessione dovevano tornare alla stessa macchina. Questo vincolo è chiamato sticky session e richiede al sistema di ricordare dove instradare ogni client.2
Dal 28 luglio 2026 la chiamata può viaggiare da sola. Versione del protocollo, metodo e identità del client sono inclusi negli header e nel campo _meta del messaggio. initialize e Mcp-Session-Id vengono eliminati.1
Di conseguenza, un bilanciatore può inviare ogni richiesta a qualsiasi istanza disponibile. Le macchine non devono condividere lo stato delle sessioni e possono essere aggiunte o rimosse più facilmente. Simon Willison attribuisce a questa semplificazione la possibilità di costruire tre client e server in una settimana.3
Come si mantiene lo stato
Stateless non significa «senza memoria» in senso assoluto. Un’applicazione può ancora conservare conversazioni, risultati e stato in un database. Semplicemente, queste informazioni non restano nascoste nella sessione del protocollo.
Quando un tool deve proseguire un lavoro in più passaggi, può restituire un identificatore esplicito. Il client lo invia nella chiamata successiva, come farebbe con il numero di una pratica. In questo modo lo stato resta visibile e può essere conservato dall’applicazione.1
L’assenza di Mcp-Session-Id elimina inoltre gli attacchi basati sul riuso di quell’identificatore tra backend diversi. Non risolve però gli altri rischi dei gateway, come traduzioni errate o controlli incompleti sul contenuto delle richieste.4 Questi casi sono descritti in Sicurezza di MCP.
Discovery e caching
Il metodo opzionale server/discover permette a un client di chiedere in anticipo quali funzioni supporta il server. Non è obbligatorio, perché ogni richiesta dichiara comunque versione e capacità.
Gli elenchi di tool, prompt e resource possono essere conservati temporaneamente nella cache. Il server indica per quanto tempo sono validi e a quale ambito si applicano. Il client evita così di richiedere lo stesso catalogo a ogni chiamata.1
MRTR ed elicitation
Un tool può aver bisogno di informazioni aggiuntive prima di terminare: per esempio una conferma dell’utente o un parametro mancante. La nuova specifica gestisce il caso con le Multi Round-Trip Requests (MRTR).
Il server interrompe la risposta con lo stato input_required e indica cosa manca. Il client raccoglie l’informazione e ripete la chiamata includendo la risposta. Non serve mantenere aperta una connessione continua.1
Lo stesso schema permette di completare un’autorizzazione nel browser. Il server fornisce un URL, l’utente esegue il flusso OAuth e il client non riceve direttamente le credenziali.2
Voci correlate
- Model Context Protocol — il protocollo trasformato da questa spec
- Sicurezza di MCP — l’auth hardening della stessa release e i contratti dei gateway
- Ecosistema MCP — gli SDK aggiornati alla versione stateless
- Portale: MCP
Bibliografia e sitografia
- MCP Blog, The 2026-07-28 Specification, 28 luglio 2026. blog.modelcontextprotocol.io
- MCP Blog, One Year of MCP — November 2025 Spec Release, 25 novembre 2025. blog.modelcontextprotocol.io
- Simon Willison, Stateless MCP has recaptured my interest, 31 luglio 2026. simonwillison.net
- Aonan Guan, Enterprise MCP Gateway Security in Practice with Agentgateway, Agentic AI Foundation, 20 agosto 2026. aaif.io