--- type: "Comparison" title: "MCP v2 stateless vs MCP v1 stateful (2026): Python alla 2.2.0, SDK core ancora all'1.30.0" description: "MCP v2 stateless vs MCP v1 stateful, quattro giorni dopo la scadenza del 28 luglio: il tag della specifica è finale e PyPI mcp è alla 2.0.0, ma @modelcontextprotocol/sdk resta alla 1.30.0. Confronto su scalabilità, stabilità degli SDK, autorizzazione e rischio di migrazione." resource: "https://www.contextstudios.ai/it/confronto/mcp-v2-stateless-vs-mcp-v1-stateful" language: "it" tags: ["MCP v2", "MCP senza stato", "MCP v1", "Model Context Protocol", "migrazione MCP", "Python SDK v2"] generated: by: "process:contextstudios-md/1" at: "2026-10-08T22:10:37.194Z" status: "stable" --- # MCP v2 stateless vs MCP v1 stateful (2026): Python alla 2.2.0, SDK core ancora all'1.30.0 Il 28 luglio 2026 era la scadenza per la migrazione MCP, e la risposta onesta è cambiata nel giro di poche ore. Verifica ripetuta sui registri il 1° agosto: il tag 2026-07-28 del repository della specifica è ora finale (prerelease=false, pubblicato il 2026-07-28T16:47:49Z) e PyPI ha portato mcp alla 2.0.0 lo stesso giorno. Le due obiezioni che avevano definito il giorno della scadenza — una specifica solo in RC e un ecosistema Python fermo alla 1.28.1 — sono quindi cadute. Resta una lacuna: l'SDK TypeScript principale, @modelcontextprotocol/sdk, è ancora alla 1.30.0 del 27 luglio. MCP v2 porta il nucleo del protocollo a un modello richiesta/risposta stateless e aggiunge Extensions, Tasks, MCP Apps, un irrigidimento dell'autorizzazione e una politica formale di deprecazione. MCP v1 resta la linea mantenuta — e, se il suo codice importa l'SDK TypeScript principale, l'unica cosa che può installare. riverificato il 08/09/2026: mcp su PyPI è ora alla 2.2.0 (con backport v1.30.0 lo stesso giorno), mentre @modelcontextprotocol/sdk giace alla 1.30.0 su npm da sei settimane. ## Confronto Dettagliato | Fattore | MCP v2 senza stato | MCP v1 con stato | Vincitore | |--------|------|------|--------| | Scalabilità orizzontale | Ogni richiesta può raggiungere qualsiasi istanza compatibile quando lo stato dell'applicazione non vive più nel server di protocollo | Sessioni lunghe e affinità di connessione sono più semplici da ragionare, ma complicano autoscaling e failover | MCP v2 senza stato | | Stabilità dell'SDK | Rilascio a tappe: i pacchetti server con scope sono passati a 2.0.0 stable il 27 luglio e PyPI mcp ha seguito il 28, ma @modelcontextprotocol/sdk resta alla 1.30.0 — v2 è installabile ovunque tranne nel pacchetto TypeScript principale | Resta ciò che fornisce @modelcontextprotocol/sdk e, per quel pacchetto, la linea mantenuta per correzioni di bug e di sicurezza | Pareggio | | Hosting serverless ed effimero | Progettato per esecuzioni brevi richiesta-risposta, rendendo più puliti i modelli Vercel, Cloud Run, Lambda e container in autoscaling | Funziona meglio quando un processo può tenere vivo il contesto di sessione; possibile in serverless, ma più scomodo da gestire | MCP v2 senza stato | | Gestione dello stato | Sposta lo stato in contesti client espliciti, storage condivisi o database applicativi; più pulito, ma richiede refactoring | Permette al codice server di mantenere in memoria ipotesi di sessione, comodo per piccoli strumenti interni | Pareggio | | Compatibilità dell'ecosistema oggi | La specifica è finale e sia la superficie server TypeScript sia Python sono installabili alla 2.0.0: uno stack multilingua ora può muoversi quasi come un blocco unico | La maggior parte di esempi, pacchetti e server interni presuppone ancora il comportamento v1, e chi importa l'SDK TypeScript principale non ha alternative | MCP v2 senza stato | | Autorizzazione e governance | La specifica finale 2026-07-28 richiede OAuth 2.0 Protected Resource Metadata (RFC 9728) per annunciare la posizione del server di autorizzazione e inserisce una politica formale di deprecazione nella roadmap del protocollo | L'autorizzazione può essere governata al gateway, ma la linea di protocollo è più vecchia e meno esplicita sul nuovo modello | MCP v2 senza stato | | Rischio di migrazione | Ora distribuito su entrambi i registri: un'installazione non fissata può saltare alla 2.0.0 su quattro pacchetti npm con scope e su pip install mcp senza che lei lo chieda — vincoli di versione e test paralleli sono obbligatori | Basso se fissa le versioni — ma il rischio ora è concreto su npm e su PyPI, non più solo su npm | MCP v1 con stato | | A prova di futuro | Allineato a una specifica ora finale e non più release candidate; i pacchetti server e Python ci sono già, l'SDK principale è l'unico pezzo che deve ancora seguire | Una base di compatibilità con una via d'uscita dichiarata (server-legacy), rilasciata però già come deprecata | MCP v2 senza stato | | Irrobustimento sicurezza (settembre 2026) | 2.x è la linea di irrobustimento: redirect vincolati all'origin dalla 2.2.0, verifica dell'issuer su ogni percorso OAuth, validazione token-resource opt-in, scadenza delle sessioni — le lezioni di contenimento degli incidenti agent-SSRF, incorporate nel client | v1.30.0 backbona solo il vincolo d'origine dei redirect; verifica issuer sul percorso legacy e i nuovi controlli auth/sessione restano fuori. La linea 1.x riceve ormai manutenzione, non evoluzione | MCP v2 senza stato | ## Statistiche Chiave - **I pacchetti server MCP — @modelcontextprotocol/server, /node, /hono e /server-legacy — hanno pubblicato la loro prima versione stabile 2.0.0 il 27/07/2026 alle 23:55 UTC, cinque minuti prima della scadenza, dopo quattro alpha e cinque beta.** — [registro npm (@modelcontextprotocol/server)](https://www.npmjs.com/package/@modelcontextprotocol/server) (2026) - **Il tag di specifica 2026-07-28 è finale: GitHub riporta prerelease=false, pubblicato il 2026-07-28T16:47:49Z — la prima specifica MCP finale dal 2025-11-25.** — [Release GitHub modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol/releases) (2026) - **L'SDK TypeScript principale non ha ancora una 2.x: @modelcontextprotocol/sdk è alla 1.30.0 sul tag latest, pubblicata il 2026-07-27 alle 17:56 UTC — non si è mossa quando pacchetti server, PyPI e specifica sono diventati finali.** — [registro npm (@modelcontextprotocol/sdk)](https://www.npmjs.com/package/@modelcontextprotocol/sdk) (2026) - **Il mcp di PyPI è passato alla 2.0.0 il 2026-07-28T13:45:28Z, sostituendo la 1.28.1 pubblicata il 2026-06-26 — un semplice pip install mcp ora installa v2.** — [PyPI (mcp)](https://pypi.org/project/mcp/) (2026) - **La via d'uscita v1 è stata rilasciata già deprecata: server-legacy è pubblicato come «trasporto SSE v1 congelato e helper OAuth Authorization Server… Deprecato; usare StreamableHTTP e un server OAuth dedicato in produzione».** — [registro npm (@modelcontextprotocol/server-legacy)](https://www.npmjs.com/package/@modelcontextprotocol/server-legacy) (2026) - **Secondo i manutentori, l'84% degli oltre 10.000 pacchetti PyPI che dipendono da mcp non dichiara alcun limite superiore: un'installazione non fissata può quindi scaricare una pre-release v2 incompatibile.** — [GitHub modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) (2026) - **Le deprecazioni di Roots, Sampling e Logging del 28 luglio sono solo annotazioni: metodi, tipi e capability flag continuano a funzionare in questa release e in ogni versione della specifica pubblicata entro un anno — i server v1 esistenti non si rompono il 28 luglio.** — [Blog Model Context Protocol](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) (2026) - **I server MCP DEVONO implementare OAuth 2.0 Protected Resource Metadata (RFC 9728) per annunciare la posizione del proprio authorization server; l'RC del 28/07/2026 limita inoltre le richieste avviate dal server ai soli momenti in cui sta elaborando attivamente una richiesta del client (SEP-2260).** — [Specifica di autorizzazione Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) (2026) - **La linea Python dell'SDK è approdata alla 2.2.0 su PyPI il 07/09/2026, quattro settimane dopo che la 2.0.0 era diventata il default di pip — mentre @modelcontextprotocol/sdk resta alla 1.30.0 su npm, sei settimane dopo la scadenza di migrazione.** — [PyPI (mcp) + registro npm (@modelcontextprotocol/sdk)](https://pypi.org/pypi/mcp/) (2026) - **python-sdk v2.2.0 vincola i redirect HTTP client all'origin dell'endpoint (schema, host, port): un redirect cross-origin ora fallisce con MCPError — la classe SSRF delle evasioni degli agenti Hugging Face è chiusa a livello di libreria.** — [modelcontextprotocol/python-sdk release v2.2.0 (#3397)](https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0) (2026) - **L'irrobustimento non è esclusivo di 2.x: un backport v1.30.0 pubblicato lo stesso giorno porta la stessa regola di vincolo dell'origine (#3448) — ma la verifica dell'issuer sul percorso auth legacy e i controlli di sessione esistono solo in 2.x.** — [modelcontextprotocol/python-sdk release v1.30.0 (07/09/2026)](https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0) (2026) - **v2.2.0 aggiunge barriere operative: le sessioni Streamable-HTTP stateful inattive scadono dopo 30 minuti e i server sono limitati a 10.000 sessioni concorrenti — configurabili, senza effetti su connessioni stateless o specifica 2026-07-28.** — [note di rilascio python-sdk v2.2.0 (#3395)](https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0) (2026) - **23 settembre 2026 (15:45 UTC): la linea TypeScript entra nell'era v2 — @modelcontextprotocol/server e @modelcontextprotocol/node pubblicano entrambi la 2.1.0, in linea con il modello PyPI 2.2.0; l'API server stateless-first è ora disponibile in entrambe le principali famiglie SDK.** — [npm registry](https://www.npmjs.com/package/@modelcontextprotocol/server) (2026) ## Scelga MCP v2 senza stato quando... - @modelcontextprotocol/server 2.0.0) o in Python, dove pip install mcp ora risolve alla 2.2.0 - Le serve scalabilità orizzontale senza sessioni sticky, oppure hosting serverless ed effimero per strumenti remoti - Può spostare lo stato di sessione su client, database o store condivisi prima della migrazione - La sua governance richiedeva un tag di specifica finale prima della migrazione — il tag 2026-07-28 è ora finale, non più un release candidate ## Scelga MCP v1 con stato quando... - Il suo codice importa direttamente @modelcontextprotocol/sdk: resta alla 1.30.0 e non esiste alcuna release 2.x da installare - La logica dei suoi server dipende ancora da sessioni di lunga durata, o i suoi client e adattatori non sono testati contro un server stateless - Gestisce infrastruttura v1 con versioni fissate, dove un aggiornamento major sul posto è più rischioso del margine di scalabilità che otterrebbe - Il suo processo di rilascio richiede che strumenti client e server stiano sulla stessa versione major ## La Nostra Raccomandazione Quattro giorni dopo la scadenza il quadro è cambiato due volte. La specifica è finale: il tag 2026-07-28 è passato a non-prerelease il 28 luglio alle 16:47 UTC, quindi l'obiezione di governance alla migrazione decade. PyPI ha seguito lo stesso giorno — pip install mcp ora risolve alla 2.0.0 (caricata il 28 luglio alle 13:45 UTC), non più alla 1.28.1 ancora corrente la mattina della scadenza. Ciò che non si è mosso è l'SDK TypeScript principale: @modelcontextprotocol/sdk resta alla 1.30.0, pubblicata il 2026-07-27 alle 17:56 UTC. La linea di frattura non separa più TypeScript da Python, ma i pacchetti server e Python da quell'unico pacchetto TypeScript principale che quasi ogni client su misura importa. Scelga v2 stateless ora se sviluppa server MCP in TypeScript (i pacchetti con scope @modelcontextprotocol/server, /node e /hono sono 2.0.0 stable) o in Python, e se le servono scalabilità orizzontale senza sessioni sticky, routing resistente ai riavvii ed esecuzione serverless pulita. Resti su v1 stateful dove dipende direttamente da @modelcontextprotocol/sdk — il codice client e tutto ciò che poggia sull'SDK principale non ha alcun 2.x da installare — o dove i suoi client e adattatori non sono stati testati contro un server stateless. In ogni caso fissi le versioni: quattro pacchetti npm con scope e il mcp di PyPI risolvono ormai latest alla 2.0.0, quindi un'installazione non fissata attraversa da sola una versione major. E il 28 luglio non si è rotto nulla: le deprecazioni di Roots, Sampling e Logging restano semplici annotazioni per almeno un anno — migri con criterio, pacchetto per pacchetto. Settembre 2026 rende operativa l'asimmetria: con la 2.2.0 e il backport v1.30.0 usciti lo stesso giorno, il contenimento dei redirect è diventato prerequisito su entrambe le linee — ma validazione dell'issuer, controlli token-resource e gestione sessioni restano solo in 2.x. La linea v1 ormai riceve manutenzione, non evoluzione; se aspettavi una ragione per pianificare il passaggio, è questa. Al 23/09/2026: con server e node entrambi alla 2.1.0, la linea 2.x è il default in entrambe le famiglie di pacchetti; i pin 1.x residui sono ormai debito di transizione, non ancoraggio di stabilità. ## Domande Frequenti **Q: MCP v2 è stato davvero rilasciato il 28 luglio 2026?** A: Sì, a tappe, e gran parte proprio nel giorno stesso. I pacchetti server TypeScript con scope sono passati a 2.0.0 stable il 27 luglio alle 23:55 UTC; il mcp di PyPI è passato alla 2.0.0 il 28 luglio alle 13:45 UTC; e il tag di specifica 2026-07-28 è passato a non-prerelease il 28 luglio alle 16:47 UTC. Resta soltanto l'SDK TypeScript principale, @modelcontextprotocol/sdk, ancora alla 1.30.0. **Q: MCP v2 è pronto per la produzione oggi?** A: Per i server, in larga misura sì: la specifica è finale, i pacchetti server TypeScript sono 2.0.0 stable e Python installa 2.0.0 per impostazione predefinita. La lacuna residua è lato client e librerie — tutto ciò che importa @modelcontextprotocol/sdk è ancora alla 1.30.0. Faccia un pilota sullo strato server e mantenga fissato il codice che dipende dall'SDK principale. **Q: I team dovrebbero fissare ora le dipendenze MCP?** A: Con più urgenza rispetto al giorno della scadenza. Il tag latest ora risolve alla 2.0.0 su quattro pacchetti npm con scope e sul mcp di PyPI: un'installazione non fissata attraversa quindi da sola una versione major. I manutentori riferiscono che l'84% degli oltre 10.000 pacchetti PyPI che dipendono da mcp non dichiara alcun limite superiore — quella popolazione ora è esposta in pratica, non più solo in teoria. **Q: A cosa serve @modelcontextprotocol/server-legacy?** A: È la via d'uscita v1 esplicita, ed è stata rilasciata già deprecata: trasporto SSE v1 congelato e helper OAuth Authorization Server, pubblicati con l'indicazione di usare StreamableHTTP e un server OAuth dedicato in produzione. Usatela per mantenere in vita un server v1 durante la migrazione — non come destinazione. **Q: MCP senza stato significa che l'applicazione non può mantenere stato?** A: No. Senza stato significa che il server di protocollo non deve dipendere da una sessione di lunga durata per rispondere a una richiesta. L'applicazione può comunque mantenere stato, ma questo deve risiedere nel client, in un database, in una cache o in un altro livello di persistenza esplicito. **Q: Chi dovrebbe passare per primo a MCP v2?** A: I team che gestiscono su larga scala infrastrutture di server MCP remoti, sia in TypeScript sia in Python: ottengono load balancing ordinario, routing stateless e autorizzazione più chiara, ed entrambi i linguaggi hanno ora una 2.0.0 stabile. I team il cui codice importa l'SDK TypeScript principale dovrebbero attendere la sua 2.x, perché al momento non c'è nulla da installare. **Q: Cosa cambia per questa decisione il rilascio di irrobustimento dell'SDK del 7 settembre?** A: Chiude la fase di attesa su entrambe le linee. mcp 2.2.0 e il backport v1.30.0 sono usciti lo stesso giorno, quindi il contenimento dei redirect è ormai standard ovunque — ma validazione dell'issuer, controlli token-resource e gestione delle sessioni arrivano solo in 2.x. Restare su v1 significa ricevere le correzioni in ritardo e perdere del tutto i controlli, il che rafforza silenziosamente il passaggio, anche nei team prudenti.