MCP v2 Alpha: prepararsi al 28 luglio
Il Model Context Protocol sta passando da comodità di integrazione a infrastruttura di produzione. Il candidato alla specifica del 28 luglio 2026 rende il passaggio concreto: richieste senza stato, estensioni più ordinate, autorizzazione più rigorosa e rotture negli SDK da pianificare prima che emergano in esercizio.
Model Context Protocol è utile perché offre alle applicazioni di IA un modo comune per raggiungere strumenti, dati e servizi. Dal 21 maggio 2026, però, il tema è diventato operativo. I manutentori di MCP hanno pubblicato il candidato 2026-07-28 con nucleo di protocollo senza stato, Extensions, Tasks, MCP Apps, autorizzazione rafforzata, JSON Schema 2020-12 per gli strumenti e una regola formale di deprecazione (Model Context Protocol blog).
Per i team tecnici, quindi, la domanda non è se MCP sia di tendenza. La domanda è se l’implementazione reggerà il prossimo confine del protocollo. Un flusso di agenti che dipende da sessioni persistenti, memoria implicita del server, ipotesi OAuth troppo ampie o aggiornamenti SDK non vincolati sta ricevendo un avviso anticipato. Una pila con versioni bloccate, prove sul bilanciatore, credenziali limitate e chiamate agli strumenti tracciabili può invece usare il cambiamento per semplificare l’operatività.
Abbiamo già analizzato l’ecosistema MCP nel 2026 e gli effetti sulla comunicazione multi-agente. Qui il perimetro è più stretto: quali verifiche servono prima che la data del 28 luglio diventi il riferimento pratico per l’intero ecosistema?
MCP v2 Alpha è una finestra di validazione, non una scelta di produzione
MCP v2 Alpha concede a chi mantiene SDK e gestisce server il tempo per provare cambiamenti incompatibili prima della specifica del 28 luglio 2026.
Il candidato ufficiale indica il 28 luglio 2026 come data prevista per la specifica finale e segnala la presenza di cambiamenti incompatibili (Model Context Protocol blog). La tabella di marcia del Python SDK rende la finestra ancora più precisa: v2.0.0a1 è stato pubblicato l’11 giugno 2026, la beta è prevista per il 30 giugno 2026 e la v2 stabile per il 27 luglio 2026 (rilascio GitHub).
MCP v2 Alpha appartiene quindi a un percorso di prova, non a un aggiornamento ordinario. I metadati PyPI spiegano che le versioni preliminari sono pubblicate come 2.0.0aN, che ogni alpha può introdurre rotture e che v1.x resta la linea stabile raccomandata per la produzione (PyPI JSON). Per la gestione delle dipendenze è un dettaglio decisivo. Un vincolo non limitato su mcp non genera per forza una rottura immediata, perché i gestori di pacchetti non scelgono una preversione senza richiesta esplicita. Ma una prova di v2 dovrebbe sempre usare una versione esatta e un ramo separato.
La pratica più solida è sobria: mantenere in produzione un vincolo come mcp>=1.27,<2, poi aprire un ramo di migrazione bloccato sull’alpha esatta. Il README.v2 del SDK esprime lo stesso criterio: le versioni preliminari devono essere selezionate in modo esplicito, mentre le installazioni non vincolate restano sulla v1.x stabile (README.v2).
Per un’organizzazione che costruisce strumenti agentici per i clienti, questa disciplina rientra nello stesso ambito di routing dei modelli, osservabilità e governance dei rilasci. Context Studios la include nel lavoro di AI Agent Development, perché raramente il problema è solo il modello. Più spesso cambiano un connettore, un permesso o un’ipotesi di esecuzione senza un percorso di migrazione controllato.
MCP senza stato cambia la gestione dei server
Il principale cambio architetturale è il routing senza stato: una richiesta MCP non dovrebbe più dipendere da sessioni di protocollo o da un server specifico.
Il candidato ufficiale descrive il passaggio da un trasporto legato alle sessioni a una normale infrastruttura HTTP: i server remoti non dovrebbero più richiedere sessioni persistenti, archivi di sessione condivisi o routing del gateway basato sull’ispezione profonda del payload (Model Context Protocol blog). MCP Playground riassume il modello in modo diretto: niente handshake initialize, niente aggancio tramite Mcp-Session-Id, e richieste con intestazioni Mcp-Method e Mcp-Name per consentire il routing senza leggere il corpo JSON-RPC (MCP Playground).
La distinzione è importante. L’Agentic AI Foundation spiega che lo stato si sposta verso handle visibili, mentre il traffico protocollare diventa più semplice da gestire dietro bilanciatori, gateway e limiti di velocità (AAIF). Un server che analizza repository non dovrebbe presupporre che « la stessa sessione conosca il repository ». Dovrebbe emettere un handle, definirne la durata, limitarne il riuso e renderlo visibile nelle tracce.
Il rischio non è solo nel codice. È nell’infrastruttura. I test del bilanciatore devono dimostrare che qualunque richiesta può raggiungere qualunque istanza. I test del gateway dovrebbero instradare sulle intestazioni, non sull’analisi del corpo. Le prove di riavvio devono mostrare che un lavoro applicativo in corso sopravvive alla scomparsa di un processo server. Sono verifiche normali nei sistemi distribuiti, ma MCP ha permesso a molti team di rimandarle durante la fase prototipale.
La nostra panoramica dei servizi descrive come progettiamo sistemi IA nativi attorno a osservabilità, governance e disciplina di rilascio, non attorno a dimostrazioni isolate. MCP v2 Alpha va nella stessa direzione: rende esplicite ipotesi infrastrutturali che i team devono chiarire prima che siano i clienti a scoprirle.
Extensions, Apps e Tasks rendono più chiaro il contratto opzionale
Il candidato trasforma capacità MCP opzionali in estensioni negoziate, riducendo comportamenti su misura tra client e server.
I manutentori indicano Extensions, MCP Apps e Tasks tra le parti centrali del candidato (Model Context Protocol blog). MCP.Directory descrive cinque pilastri: nucleo senza stato, operatività tramite intestazioni e cache, Extensions/MCP Apps/Tasks, autorizzazione rafforzata e JSON Schema 2020-12 (MCP.Directory).
MCP Apps conta perché interfacce rese dal server possono diventare parte dell’esperienza dello strumento, invece di restare un canale separato. Tasks conta perché un lavoro lungo non dovrebbe essere mascherato da chiamata bloccante. Extensions conta perché un client deve sapere su quali capacità può fare affidamento prima di invocarle.
Questo non rende ogni estensione sicura per definizione. Rende il contratto più verificabile. Un server che esegue task dovrebbe definire proprietà, annullamento, avanzamento, conservazione e audit. Un server che espone una superficie applicativa dovrebbe chiarire isolamento e consenso. Un server che annuncia estensioni proprie dovrebbe pubblicare note di compatibilità e comportamento di ripiego.
La guida di migrazione del SDK mostra lo stesso orientamento a livello di libreria. Documenta cambiamenti incompatibili nei valori restituiti dal client HTTP streamable, nell’interfaccia dispatcher/server, nei tipi più rigorosi e nella rinomina di FastMCP (migration guide). Sono dettagli Python, ma il messaggio è più ampio: il codice che trattava MCP come un sottile strato di comodità deve ora modellare consapevolmente il confine del protocollo.
I team piattaforma dovrebbero gestire ogni integrazione come un prodotto mantenuto: regola di versione, modalità di guasto e nota operativa comprensibile. Le estensioni MCP non sono solo nuove capacità. Sono impegni tra client, server e persone che risponderanno agli incidenti.
L’autorizzazione non va rimandata
Il candidato del 28 luglio rafforza le aspettative sull’autorizzazione mentre i server MCP raggiungono strumenti e dati più sensibili.
Il candidato ufficiale afferma che l’autorizzazione si allinea meglio agli ambienti OAuth e OpenID Connect (Model Context Protocol blog). Non è una formalità. Un server MCP spesso si colloca tra un client IA e sistemi con codice sorgente, ticket, calendari, risorse cloud, dati dei clienti o documenti interni.
La cronologia aggiornata degli incidenti MCP pubblicata da AuthZed offre il contesto più scomodo. Descrive pattern ricorrenti: accesso a strumenti sensibili, isolamento dei tenant, server malevoli, prompt injection e confini di autorizzazione deboli in sistemi collegati a MCP (AuthZed). Anche quando un singolo caso viene interpretato diversamente, la lezione di controllo resta solida: MCP introduce una nuova interfaccia, non sospende i fondamentali della sicurezza.
GitHub, PyPI e i registri di pacchetti rendono l’alpha facile da ottenere. Questa comodità non deve diventare una scorciatoia nella catena di fornitura. Servono versioni bloccate, build riproducibili, revisione dei rilasci e un ambiente di preproduzione che rifletta i flussi di identità reali. Se un server MCP può chiamare un’API distruttiva, il piano di test deve includere permessi negati e credenziali revocate, non solo il percorso riuscito.
Il glossario Model Context Protocol aiuta anche le figure non specialistiche. Senza un linguaggio condiviso su client, server, strumenti, risorse, trasporti e autorizzazione, una migrazione vicina alla produzione diventa difficile da approvare con rigore.
Lista di preparazione prima del 28 luglio
Un buon piano MCP v2 Alpha verifica compatibilità del protocollo, rotture SDK, routing, sicurezza e ripristino prima della data stabile.
Si parte dall’inventario. Elencare ogni client MCP, server, SDK, strumento ospitato e connettore interno. Classificare ogni voce come produzione, preproduzione, esperimento o non utilizzata. Aggiungere versione del protocollo, versione SDK, trasporto, modello di autenticazione e responsabile. Stacktree ricorda che la versione finalizzata corrente resta 2025-11-25 mentre il candidato 2026-07-28 è in validazione (Stacktree). Una fase con versioni miste è quindi normale.
Poi conviene suddividere la migrazione in anelli. Anello 0: server usa e getta bloccato sull’alpha. Anello 1: flusso di preproduzione con dati non sensibili. Anello 2: percorso ombra vicino alla produzione. Anello 3: produzione controllata dopo il SDK stabile. Un singolo laptop di sviluppo non basta come prova.
Serve anche un ritorno definito. Un buon piano indica la versione a cui tornare, come ruotare le credenziali, quali cache o handle invalidare e quali log dimostrano che il ripristino ha funzionato. Deve anche chiarire quando non procedere: server che non gira senza sessioni persistenti, proprietà dei task ambigua, controlli sull’emittente OAuth incompleti.
Infine, prodotto e clienti vanno informati. Un prodotto che espone server MCP ospitati dovrebbe pubblicare una nota di compatibilità prima della data obiettivo. Se agenti interni dipendono da server di terze parti, le funzioni piattaforma o procurement dovrebbero sapere quali fornitori hanno comunicato un piano v2.
L’ultimo passo è trasformare la migrazione in un modello di governance riutilizzabile. Il prossimo cambio di protocollo sarà diverso, ma i controlli si somiglieranno: versioni fissate, matrice di compatibilità, adozione graduale, revisione di sicurezza, osservabilità e ripristino pulito. Per trasformare prototipi agentici in sistemi di produzione, si può partire dal nostro AI Agent Development o portare le domande architetturali a Context Studios.
FAQ
MCP v2 Alpha è pronto per la produzione?
No. v1.x resta la linea stabile per la produzione, mentre v2.0.0a1 è un’alpha opzionale con cambiamenti incompatibili attesi (PyPI JSON).
Qual è il cambiamento principale del candidato MCP del 28 luglio?
Il protocollo diventa senza stato a livello protocollare: niente handshake, niente vincolo di sessione e routing tramite intestazioni standard (RC ufficiale).
Che cosa va testato prima di MCP v2?
Versioni SDK esatte, bilanciamento senza stato, handle di stato espliciti, flussi di autorizzazione, annullamento dei task, log e ritorno dall’alpha a v1.x (migration guide).
MCP senza stato impedisce agli agenti di mantenere contesto?
No. Lo stato applicativo rimane possibile, ma dovrebbe passare da handle o identificatori di task espliciti, non da sessioni nascoste del protocollo (AAIF).
Conclusione
MCP v2 Alpha è un buon test di realtà. Mostra quali parti dell’infrastruttura agentica sono ancora prototipi e quali possono reggere la pressione della produzione. Non vinceranno le organizzazioni che aggiornano per prime, ma quelle che testano il confine del protocollo, fissano il percorso SDK, rafforzano l’autorizzazione e danno a ogni flusso un ritorno pulito.
Se il team costruisce server MCP, strumenti agentici ospitati o workflow multi-agente, Context Studios può trasformare questa migrazione in un piano architetturale controllato, non in una sorpresa di calendario. Si può iniziare dal nostro AI Agent Development o rileggere la nostra analisi dell’ecosistema MCP prima della data di specifica del 28 luglio 2026.
Fonti
- https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate
- https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.0.0a1
- https://pypi.org/pypi/mcp/2.0.0a1/json
- https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.v2.md
- https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/docs/migration.md
- https://aaif.io/blog/mcp-is-growing-up/
- https://mcp.directory/blog/mcp-2026-07-28-release-candidate
- https://stacktr.ee/blog/mcp-2026-spec-changes
- https://mcpplaygroundonline.com/blog/mcp-stateless-2026-release-candidate
- https://authzed.com/blog/timeline-mcp-breaches