--- type: Blog Post title: "MCP v2 beta: la migrazione stateless è iniziata" description: "MCP v2 beta porta un'architettura stateless. Cosa si rompe, quali pacchetti SDK fissare e come migrare prima della specifica del 2026-07-28." resource: "https://www.contextstudios.ai/it/blog/mcp-v2-beta-migrazione-stateless" tags: [MCP, migrazione, SDK, architettura, agenti IA] language: it timestamp: "2026-07-02T07:33:59.854Z" --- # MCP v2 beta: la migrazione stateless è iniziata
Le prime release beta del Model Context Protocol v2 sono arrivate a fine giugno 2026 e portano con sé il cambiamento architetturale più profondo mai introdotto nel protocollo: MCP passa da un modello a sessioni persistenti e con stato a un modello stateless di tipo richiesta/risposta. Ogni server esistente dovrà migrare prima che la specifica del 2026-07-28 diventi definitiva.
Se oggi fai girare qualcosa sopra il protocollo, questo è il cambiamento da pianificare adesso, non dopo che la specifica sarà finale. L'SDK Python ha raggiunto la beta come mcp 2.0.0b1, mentre l'SDK TypeScript è in beta sotto nomi di pacchetto completamente nuovi (repo dell'SDK Python, repo dell'SDK TypeScript). Gestiamo in produzione un server dall'ampia superficie di strumenti, quindi questa migrazione è già sulla nostra roadmap. Ecco che cosa cambia davvero, che cosa si rompe e come organizzare il lavoro prima della scadenza. Che cosa significa davvero « stateless » per MCP v2
Il cambiamento centrale della v2 è che il protocollo diventa stateless a livello di trasporto: ogni richiesta è autonoma, così qualsiasi istanza del server può rispondere a qualsiasi richiesta senza una sessione condivisa.
Nella v1 il client apriva una sessione bidirezionale e di lunga durata, spesso un canale SSE, e il server generava un identificativo di sessione che le richieste successive dovevano riutilizzare. Quel disegno presupponeva che un client restasse legato a un singolo processo server per tutta la durata della conversazione. La v2 abbandona quel presupposto. MCP è stato introdotto da Anthropic come protocollo con stato, orientato alle sessioni, e questa forma funzionava bene per i client desktop a processo unico. Invecchia male nel momento in cui serve una scalabilità orizzontale. La release candidate della specifica ufficiale descrive la riscrittura stateless come « il tipo di cambiamento fondamentale che richiedeva una rottura netta » (blog MCP). Sessioni, routing persistente e archivi di sessione condivisi smettono di essere portanti (guida alla preparazione degli aggiornamenti). In parole povere: una richiesta porta con sé tutto ciò che serve al server, e il server non conserva nulla tra una chiamata e l'altra. È tutta qui la sostanza, e ogni decisione a valle discende da questo. È il proseguimento del percorso che avevamo aperto all'uscita dell'alpha, da rileggere nella nostra prima analisi del cambio di protocollo del 28 luglio. Con la beta la pianificazione diventa lavoro messo a calendario. Le versioni verso cui stai davvero migrando
La beta della v2 comporta pacchetti precisi: l'SDK Python è pubblicato come mcp 2.0.0b1 su PyPI, mentre l'SDK TypeScript esce sotto due nuovi nomi di pacchetto in versione 2.0.0-beta.1, distinti dal pacchetto v1 che resta sulla sua linea 1.x.
Sul lato Python, PyPI ospita ora mcp 2.0.0b1 come pre-release opzionale, mentre la linea stabile v1 resta alla 1.28.x (mcp su PyPI). Il repository afferma che la v2 è « una riscrittura importante dell'SDK, sia per supportare la specifica del 2026-07-28 sia per risolvere problemi architetturali di lunga data », con la v2 stabile prevista per il 2026-07-27 (repo dell'SDK Python). Il lato TypeScript nasconde una trappola che vale la pena segnalare. La v2 non esce come nuova versione di @modelcontextprotocol/sdk. Su npm esce come due pacchetti del tutto nuovi, @modelcontextprotocol/server e @modelcontextprotocol/client, entrambi in 2.0.0-beta.1, mentre il vecchio pacchetto resta in v1 (repo dell'SDK TypeScript). Se il tuo piano di aggiornamento è « alzare il numero di versione », mancherai del tutto la migrazione. È un cambio di nome del pacchetto, non un semplice salto di versione. Gli analizzatori di dipendenze che sorvegliano solo @modelcontextprotocol/sdk ti dichiareranno aggiornato mentre, in realtà, sei indietro di un'intera versione maggiore. Chi valuta quanto lavoro giustifichi un cambio di dipendenza dovrebbe leggerlo insieme al nostro ragionamento sul costo opportunità della potenza di calcolo. Che cosa si rompe, nella pratica
La cosa che più spesso si rompe in una migrazione alla v2 è l'infrastruttura costruita attorno all'affinità di sessione: bilanciatori con routing persistente, client legati a SSE e qualsiasi codice che conservava stato per sessione sul server.
La dimostrazione più chiara è un test sul bilanciatore di carico: punta un client v1 con stato verso un proxy round-robin che distribuisce su due istanze del server, e il client genera una sessione sull'istanza A, poi la richiesta successiva finisce sull'istanza B, che di quella sessione non sa nulla (analisi sul modello senza sessione). Nella v1 si rimediava con il routing persistente. Nella v2 il problema sparisce, perché non c'è alcuna sessione da lasciare orfana, ma solo dopo aver rimosso il codice che se ne aspettava una. In concreto, metti in conto di toccare quattro cose: la configurazione del trasporto, dove si abbandona l'ipotesi della sessione SSE di lunga durata; qualsiasi archivio di sessione lato server; le regole di routing persistente nel bilanciatore o nel gateway; e la logica di riconnessione del client, che presupponeva un canale permanente. C'è anche una dimensione di sicurezza: la nuova specifica apre quelle che un'analisi definisce tre nuove superfici di attacco, con una finestra di validazione già aperta dal 21 maggio (Backslash Security). L'assenza di stato sposta le decisioni di fiducia su ogni singola richiesta, quindi l'autorizzazione per richiesta conta più di prima. Se non riesamini la tua superficie di strumenti da un po', abbina questa migrazione a un vero audit di strumenti e competenze e alla più ampia checklist di irrobustimento della catena di fornitura. Come organizzare la migrazione prima del 28 luglio
Tratta la v2 come pianificazione della migrazione, non come una guida definitiva: gli SDK sono pre-release, quindi le interfacce possono ancora cambiare prima della release stabile del 2026-07-28, e la mossa prudente è pianificare e prototipare adesso anziché rilasciare sulla beta.
Un ordine di lavoro sensato: primo, censisci ogni punto in cui il tuo stack presuppone una sessione persistente del protocollo, perché questo inventario è il vero risultato di questo mese. Secondo, fissa la beta in modo esplicito in un branch (mcp==2.0.0b1 per Python; i nuovi pacchetti @modelcontextprotocol/server e /client per TypeScript) e allestisci un server prototipo, senza toccare la produzione. Terzo, esegui il test del bilanciatore descritto sopra per confermare che le tue richieste sopravvivano alla distribuzione su più istanze. Quarto, sposta l'autorizzazione per richiesta dentro il percorso della richiesta. Che aspetto ha davvero quell'inventario? Cerca nel codice e nell'infrastruttura una breve lista di indizi: qualsiasi riferimento a un identificativo di sessione salvato o riutilizzato, qualsiasi endpoint SSE aperto dal tuo trasporto MCP, qualsiasi regola del bilanciatore che lega un client a un backend e qualsiasi presupposto che due chiamate consecutive raggiungano lo stesso processo. Ogni riscontro è una voce del tuo piano di migrazione. La maggior parte dei team resta sorpresa da quanto di tutto questo viva nella configurazione dell'infrastruttura più che nel codice applicativo: bilanciatore e gateway sono i luoghi in cui i presupposti con stato si accumulano in silenzio, ed è esattamente per questo che un inventario batte una riscrittura del codice fatta alla cieca. Poiché si tratta di pre-release opzionali, i manutentori della specifica sono espliciti nel dire che le interfacce possono ancora spostarsi prima della disponibilità generale (dati di versione di libraries.io). Considera la beta come una prova generale. I segnali di maturità sono incoraggianti, perché l'ecosistema vive questo momento come quello in cui MCP « cresce », con un lavoro serio di conformità e una governance neutrale (AAIF), ma la disciplina della prova generale resta valida. Tieni una via di ripiego in v1 finché non arrivano gli SDK stabili, allo stesso modo in cui una postura indipendente dal modello ti protegge se una singola dipendenza va storta. Il vantaggio, una volta fatto il lavoro
L'assenza di stato rende i server molto più semplici da scalare e da gestire: qualsiasi istanza può servire qualsiasi richiesta, quindi ottieni scalabilità orizzontale, deploy più semplici e ripristino dai guasti più economico, tutto gratis una volta completata la migrazione.
Vale la pena essere chiari: questa migrazione ti ripaga. Un server con stato è una passività sotto carico, perché richiede routing persistente, un archivio di sessione condiviso e una gestione attenta della riconnessione, e ognuno di questi è un componente che può guastarsi per conto proprio. Un server stateless elimina quest'intera categoria di problemi. Puoi scalare fino a zero e tornare su, ruotare le istanze durante un deploy senza svuotare le sessioni e mettere davanti alla flotta un semplice bilanciatore round-robin. Per chi fa girare carichi di lavoro ad agenti su larga scala, quella semplicità operativa è il vero premio, non la mera conformità alla specifica. In Context Studios trattiamo la disponibilità come un asse di progettazione di prima classe, accanto a capacità e costo, e il trasporto stateless è esattamente il tipo di cambiamento che li migliora tutti e tre insieme. Meno parti in movimento significano meno modalità di guasto, e meno modalità di guasto significano uno stack di agenti di cui puoi davvero fidarti in produzione. Il costo della migrazione è reale, ma è un costo una tantum che riduce un rischio operativo ricorrente: il miglior tipo di scambio che chi costruisce possa fare. Perché la tempistica non è opzionale
La data del 2026-07-28 è una scadenza rigida perché è quando la specifica diventa definitiva e gli SDK v2 stabili sono previsti in uscita, il momento in cui l'adozione dell'ecosistema accelera e i presupposti della v1 iniziano a invecchiare.
La specifica e gli SDK stabili sono allineati a un giorno di distanza l'uno dall'altro: la specifica il 2026-07-28 e la v2 Python stabile prevista per il 2026-07-27 (repo dell'SDK Python). Una volta che gli SDK di prima fascia rilasciano il supporto, l'adozione si moltiplica, e i server che ancora presuppongono sessioni con stato saranno sempre più l'eccezione (documentazione ufficiale MCP). Il repository ufficiale della specifica è la fonte di verità da tenere d'occhio con l'avvicinarsi della data (repo della specifica MCP). Chi ne esce avvantaggiato è chi ha fatto l'inventario a luglio, ha prototipato sulla beta e ha girato l'interruttore la settimana in cui sono usciti gli SDK stabili, non chi ha scoperto il cambio di nome del pacchetto ad agosto. Domande frequenti MCP v2 è disponibile adesso? Sì, come pre-release beta. L'SDK Python è mcp 2.0.0b1 su PyPI e l'SDK TypeScript è in 2.0.0-beta.1 sotto nuovi nomi di pacchetto. Entrambi sono opzionali; la v2 stabile è prevista per il 2026-07-27 (repo dell'SDK Python). Qual è il cambiamento più grande di MCP v2? Il protocollo diventa stateless: le richieste sono autonome e qualsiasi istanza del server può gestire qualsiasi richiesta, sostituendo il modello della v1 legato a sessioni persistenti (blog MCP). Devo migrare io stesso il mio server? Alla fine sì: ogni server con stato dovrà migrare. Non serve migrare oggi, ma le settimane prima del 2026-07-28 sono il momento di censire i presupposti di sessione e prototipare (Backslash Security). Perché è cambiato il nome del pacchetto TypeScript? La v2 esce come @modelcontextprotocol/server e @modelcontextprotocol/client anziché come nuova versione del pacchetto v1 @modelcontextprotocol/sdk, quindi un semplice salto di versione non ti aggiornerà (repo dell'SDK TypeScript). In sintesi La migrazione stateless di MCP v2 è quel raro cambiamento incompatibile che rende la tua infrastruttura più semplice una volta completato: niente più sessioni persistenti, niente più archivi di sessione condivisi, qualsiasi istanza risponde a qualsiasi richiesta. Ma « più semplice dopo » succede solo se fai l'inventario prima che la specifica del 2026-07-28 arrivi. Mappa i tuoi presupposti di sessione, prototipa sulla beta e tieni una via di ripiego in v1 finché non escono gli SDK stabili. Se vuoi un secondo parere sul tuo piano di migrazione MCP, o un server pronto per la produzione conforme alla specifica del 2026-07-28, è esattamente il lavoro che facciamo. Fonti 1. Model Context Protocol — release candidate del 2026-07-28: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate 2. Repository ufficiale dell'SDK Python: https://github.com/modelcontextprotocol/python-sdk 3. Repository ufficiale dell'SDK TypeScript: https://github.com/modelcontextprotocol/typescript-sdk 4. PyPI — pacchetto mcp: https://pypi.org/project/mcp/ 5. Repository ufficiale della specifica MCP: https://github.com/modelcontextprotocol/modelcontextprotocol 6. Documentazione ufficiale MCP: https://modelcontextprotocol.io 7. Backslash Security — nuove superfici di attacco della specifica MCP: https://www.backslash.security/blog/new-mcp-spec-opens-new-attack-surfaces 8. Preparazione ai prossimi aggiornamenti MCP: https://www.linkedin.com/pulse/preparing-upcoming-updates-model-context-protocol-mcp-amit-singh-zziye 9. Agentic AI Foundation — MCP is growing up: https://aaif.io/blog/mcp-is-growing-up 10. libraries.io — dati di versione mcp: https://libraries.io/pypi/mcp