La versione 2 di MCP entrerà in vigore il 28 luglio 2026. Eliminerà ogni handshake, l'header Mcp-Session-Id e i tre sottosistemi legacy che legavano il Model Context Protocol (MCP) ai server con sessioni persistenti (sticky-session). Il protocollo diventerà completamente stateless, consentendo a qualsiasi istanza autoscaled o serverless di gestire qualsiasi richiesta senza dover preservare lo stato del client.

Perché questo cambiamento è importante

MCP v1 obbligava il client ad avviare una sessione con un handshake initialize; il server assegnava quindi un Mcp-Session-Id. Ogni chiamata successiva doveva includere quell'header, vincolando l'utente a un singolo nodo backend. I load balancer dovevano imporre l'affinità di sessione, aggiungendo latenza e attrito operativo.

L'approccio stateless elimina tale attrito. Tutto il contesto risiede ora in campi meta dedicati che accompagnano ogni chiamata HTTP. Una richiesta può atterrare su qualsiasi istanza, essere elaborata, e l'istanza può essere scartata non appena la risposta viene inviata. I team che utilizzano piattaforme serverless, cluster orchestrati tramite container o qualsiasi ambiente che avvii e interrompa pod su richiesta possono ora allineare il protocollo alla propria infrastruttura.

Cosa viene rimosso

Tre sottosistemi che dipendevano da connessioni persistenti sono ufficialmente deprecati:

  • Sampling – In v1, un server poteva chiedere al client di generare testo, un pattern che richiedeva una sessione aperta. La v2 prevede che il server chiami direttamente il provider del modello linguistico di grandi dimensioni (LLM) o utilizzi il pattern InputRequiredResult, in cui il client fornisce l'input mancante in una richiesta successiva.
  • Roots – In precedenza, i client inviavano URI che limitavano la visione delle risorse esterne da parte del server. Il nuovo approccio passa tali URI come parametri degli strumenti (tool) o li incorpora nei campi delle risorse della richiesta, eliminando la fase separata di negoziazione dei "roots".
  • Logging – Gli header di logging a livello di protocollo scompaiono. Scrivi su stderr per il debugging locale o adotta OpenTelemetry per l'osservabilità in produzione.

Il periodo di deprecazione dura un anno. Le funzionalità deprecate continueranno a funzionare per tale periodo, dando ai team il tempo di effettuare il refactoring prima che il protocollo le rifiuti.

Novità oltre lo statelessness

MCP v2 aggiunge due estensioni ufficiali:

  • MCP Apps – Un modo leggero per descrivere interfacce utente renderizzate dal server che il protocollo può invocare.
  • Tasks – Un pattern per gestire operazioni a lunga esecuzione che possono estendersi su più cicli di richiesta-risposta.

Entrambe le estensioni presuppongono il modello di richiesta stateless ed evitano stati di sessione nascosti.

Rischi e controargomentazioni

Il cambiamento non è un aggiornamento "plug-and-play". Gli SDK v2 sono ancora in beta e le loro API pubbliche potrebbero cambiare prima del rilascio di una versione stabile. Per i carichi di lavoro in produzione che non possono tollerare breaking changes, rimanere sull'SDK v1 stabile finché l'SDK v2 non uscirà dalla fase beta.

Gli sviluppatori devono inoltre sottoporre a audit il codice esistente per verificare la presenza di uno dei tre sottosistemi deprecati.

Una roadmap di migrazione pragmatica

  1. Audit oggi – Scansiona i tuoi servizi per individuare l'uso dell'handshake, di Mcp-Session-Id, delle chiamate di sampling, degli URI roots e del logging a livello di protocollo. Identifica il codice che si interromperebbe con un modello stateless.
  2. Test su un nodo non critico – Quando verrà rilasciato un SDK v2 stabile, avvia un server sandbox, puntalo a un client di test e verifica che tutti i campi meta richiesti siano presenti e interpretati correttamente.
  3. Migrazione completa prima della scadenza – Completa la transizione su tutti i nodi di produzione prima della fine del periodo di grazia di un anno per evitare rifiuti durante l'esecuzione (runtime).

Cosa monitorare in seguito

  • Rilascio dell'SDK stabile – Gli SDK beta verranno congelati e verrà pubblicato un pacchetto stabile versionato. Quella versione sarà il target sicuro per qualsiasi deployment critico.

La transizione richiederà modifiche al codice e un breve periodo di sperimentazione con gli SDK beta, ma il vantaggio sarà un punto di integrazione più pulito e scalabile per qualsiasi applicazione basata su LLM.

In sintesi: Se il tuo stack dipende ancora dagli handshake MCP o dai tre sottosistemi deprecati, inizia subito l'audit; un anno di grazia è generoso, ma il costo reale è lo sforzo di refactoring, non la scadenza.