IT
Prenoti una chiamata

Tecnologia

MCP v2 stateless vs MCP v1 stateful (2026): Python alla 2.2.0, SDK core ancora all'1.30.0

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.

Verificato da Michael Kerkhoff, aggiornato al

Definizione
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.
Categoria
Tecnologia
Opzioni
MCP v2 senza statoMCP v1 con stato

Confronto Dettagliato

Un'analisi comparativa dei fattori chiave per aiutarLa a fare la scelta giusta.

MCP v2 senza stato vs MCP v1 con stato
FattoreMCP v2 senza statoMCP v1 con stato
Scalabilità orizzontaleOgni richiesta può raggiungere qualsiasi istanza compatibile quando lo stato dell'applicazione non vive più nel server di protocollo VincitoreSessioni lunghe e affinità di connessione sono più semplici da ragionare, ma complicano autoscaling e failover
Stabilità dell'SDKRilascio 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 principaleResta ciò che fornisce @modelcontextprotocol/sdk e, per quel pacchetto, la linea mantenuta per correzioni di bug e di sicurezza
Hosting serverless ed effimeroProgettato per esecuzioni brevi richiesta-risposta, rendendo più puliti i modelli Vercel, Cloud Run, Lambda e container in autoscaling VincitoreFunziona meglio quando un processo può tenere vivo il contesto di sessione; possibile in serverless, ma più scomodo da gestire
Gestione dello statoSposta lo stato in contesti client espliciti, storage condivisi o database applicativi; più pulito, ma richiede refactoringPermette al codice server di mantenere in memoria ipotesi di sessione, comodo per piccoli strumenti interni
Compatibilità dell'ecosistema oggiLa 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 VincitoreLa maggior parte di esempi, pacchetti e server interni presuppone ancora il comportamento v1, e chi importa l'SDK TypeScript principale non ha alternative
Autorizzazione e governanceLa 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 VincitoreL'autorizzazione può essere governata al gateway, ma la linea di protocollo è più vecchia e meno esplicita sul nuovo modello
Rischio di migrazioneOra 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 obbligatoriBasso se fissa le versioni — ma il rischio ora è concreto su npm e su PyPI, non più solo su npm Vincitore
A prova di futuroAllineato 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 VincitoreUna base di compatibilità con una via d'uscita dichiarata (server-legacy), rilasciata però già come deprecata
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 Vincitorev1.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
Punteggio Totale · 2 pareggi6 / 91 / 9

Statistiche Chiave

Dati reali da fonti verificate del settore per supportare la Sua decisione.

  • 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) (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 (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) (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) (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) (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 (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 (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 (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) (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) (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) (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) (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 (2026)

Tutte le statistiche provengono da fonti terze verificate. Fonte, anno e link diretto sono mostrati su ogni metrica.

Quando Scegliere Ogni Opzione

Una guida chiara basata sulla Sua situazione specifica ed esigenze.

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à.

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

Risposte alle domande comuni su questo confronto.

Domande Frequenti

(01)MCP v2 è stato davvero rilasciato il 28 luglio 2026?
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.
(02)MCP v2 è pronto per la produzione oggi?
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.
(03)I team dovrebbero fissare ora le dipendenze MCP?
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.
(04)A cosa serve @modelcontextprotocol/server-legacy?
È 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.
(05)MCP senza stato significa che l'applicazione non può mantenere stato?
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.
(06)Chi dovrebbe passare per primo a MCP v2?
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.
(07)Cosa cambia per questa decisione il rilascio di irrobustimento dell'SDK del 7 settembre?
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.

Ha bisogno di aiuto per decidere?

Prenoti una consulenza gratuita di 30 minuti e La aiuteremo a determinare l'approccio migliore per il Suo progetto specifico.

Prenoti Consulenza GratuitaCi scriva

Consulenza gratuita · Senza impegno · Risposta personale