MCP 2026-07-28, la revisione più ampia del Model Context Protocol dal lancio, diventa definitiva il 28 luglio. Due specification enhancement proposal definiscono la release: SEP-2575 rimuove l'handshake initialize e SEP-2567 elimina l'header Mcp-Session-Id insieme alla sessione a livello di protocollo. Il trasporto diventa stateless, e ogni richiesta raggiunge qualsiasi istanza server dietro un semplice load balancer round-robin.
Il Model Context Protocol è lo standard aperto che collega i client LLM a strumenti, sorgenti dati e servizi esterni. Anthropic lo ha introdotto a fine 2024 e l'adozione si è diffusa rapidamente tra IDE, framework per agenti e piattaforme enterprise. Verso metà 2026 i server MCP viaggiano dentro strumenti per sviluppatori, coding agent e gateway enterprise interni, il che rende ogni cambiamento di trasporto breaking un evento su tutta la flotta. In ogni revisione precedente una connessione MCP si apriva con un handshake e portava un identificatore di sessione per l'intera durata. Quel design imponeva ai deployment remoti routing sticky e session store condivisi, e rendeva costosa la perdita di una sessione: il client doveva riconnettersi e ripetere l'handshake. La revisione 2026-07-28 riscrive queste fondamenta, e le conseguenze toccano ogni team che gestisce server MCP in produzione.
Cosa cambia a livello di protocollo
Il release candidate si è bloccato il 21 maggio 2026 e la specifica definitiva esce il 28 luglio. SEP-2575 elimina lo scambio initialize/initialized. Versione del protocollo, client info e capacità del client viaggiano ora dentro _meta a ogni richiesta, e un nuovo metodo server/discover consente ai client di recuperare le capacità del server su richiesta. SEP-2567 rimuove l'header Mcp-Session-Id e la sessione a livello di protocollo per intero. Con entrambe le modifiche attive, qualsiasi richiesta MCP arriva su qualsiasi istanza server e il routing sticky esce dalla lista dei requisiti di protocollo.
Altre proposte completano il quadro. SEP-2243 richiede gli header Mcp-Method e Mcp-Name così che un load balancer instradi guardando l'header. SEP-2322 introduce le Multi Round-Trip Request, che sostituiscono i precedenti stream SSE. SEP-2260 consente richieste avviate dal server durante l'elaborazione attiva del client, e SEP-414 aggiunge il W3C Trace Context dentro _meta per il tracing distribuito. SEP-2549 aggiunge i campi ttlMs e cacheScope alle risposte list e read. SEP-2106 porta il pieno supporto a JSON Schema 2020-12, SEP-2164 cambia un codice di errore da -32002 a -32602, e SEP-2577 fissa una politica di deprecazione per Roots, Sampling e Logging. Le Task, un tempo funzione core, tornano come estensione tramite SEP-2663, e le MCP Apps arrivano per le UI renderizzate dal server tramite SEP-1865.
Il metodo server/discover ridisegna la negoziazione delle capacità. Dove il vecchio handshake caricava in anticipo uno scambio completo di capacità, i client interrogano ora esattamente la superficie che intendono chiamare, e la risposta porta gli hint ttlMs e cacheScope di SEP-2549 così il client mette in cache le liste di tool e risorse tra le richieste. Insieme al payload _meta, una singola richiesta stateless diventa pienamente autodescrittiva: versione, identità, trace context e header di routing viaggiano tutti insieme.
Le beta SDK sono uscite in anticipo per tutti e quattro i target Tier 1: Python mcp v2.0.0b1, TypeScript v2 con nuovi nomi di pacchetto, Go v1.7.0-pre.1 e C# v2.0.0-preview.1. Tier 1 indica le SDK a massima priorità nel framework di supporto della community, e ciascuna porta il supporto funzionante dentro la finestra di validazione. I team installano la beta Python con pip install \"mcp[cli]==2.0.0b1\" e prelevano i pacchetti TypeScript dal tag @beta. La finestra di validazione dura circa quattro settimane prima che la specifica si finalizzi il 28 luglio.
L'implicazione architetturale
Un trasporto stateless cambia i conti del deployment. Un server MCP remoto gira ora su infrastruttura ordinaria — un semplice load balancer round-robin, autoscaling orizzontale e container usa e getta — perché ogni richiesta porta con sé il proprio contesto. Le sticky session e i session store condivisi lasciano il percorso critico, il che riduce il costo operativo e chiude un tipico punto di rottura dove una sessione persa imponeva una riconnessione completa. Per una piattaforma di agenti che distribuisce migliaia di tool call concorrenti su una flotta, questo ridisegna la pianificazione della capacità.
La rimozione della sessione a livello di protocollo lascia lo stato applicativo del tutto intatto. Un server che deve portare stato conia un handle esplicito da una tool call e fa in modo che il modello lo restituisca come normale argomento nelle chiamate successive. Lo stato diventa dato che l'applicazione possiede, invece di una proprietà nascosta della connessione, e questo spostamento dà ai team di ingegneria controllo diretto su dove vive lo stato e quanto a lungo sopravvive. La release accompagna tutto questo con un irrobustimento dell'autorizzazione, avvicinando MCP alla postura di sicurezza che i deployment enterprise richiedono.
La postura di sicurezza si sposta insieme al trasporto. Una richiesta stateless che qualsiasi istanza può servire alza l'asticella sull'autorizzazione per singola richiesta, e la release risponde con regole di auth irrobustite più gli header Mcp-Name e Mcp-Method che permettono a un gateway di applicare policy al bordo. Per le piattaforme multi-tenant, questo significa che le decisioni di autorizzazione viaggiano su dati dentro ogni richiesta anziché su una sessione fidata stabilita una volta al momento della connessione — un modello assai più amichevole verso gateway zero-trust e audit logging.
La retrocompatibilità viaggia dentro le SDK. I nuovi client ricadono sull'handshake initialize quando raggiungono un server sulla revisione 2025-11-25 o precedente, così i server esistenti continuano a servire traffico. I server Python v2 gestiscono entrambe le revisioni di protocollo da un singolo endpoint nello stesso momento. La specifica introduce anche una feature lifecycle policy con finestre di deprecazione di 12 mesi tra la marcatura di una funzione come deprecata e la sua rimozione, il che offre agli implementatori una pista prevedibile per ogni cambiamento futuro.
La decisione per la leadership tecnica
La decisione concreta davanti alla leadership di ingegneria è la tempistica di upgrade. I server costruiti sul vecchio handshake interopereranno con i nuovi client attraverso il percorso di fallback, così la produzione resta viva oltre il 28 luglio. L'azione per questo trimestre si articola in tre passi: prelevare la beta Tier 1 adatta al proprio stack, allestire un server di test contro il release candidate e verificare che il layer di routing inoltri gli header Mcp-Method e Mcp-Name. I team che gestiscono MCP su larga scala guadagnano di più, perché abbandonare sticky session e session store condivisi semplifica il load balancer e sblocca un autoscaling orizzontale autentico. Tratta le release stabili Tier 1 come segnale di via libera, e considera il percorso di fallback un ponte piuttosto che una destinazione. Mappa la migrazione adesso, valida dentro la finestra di quattro settimane e pianifica il cutover una volta che la tua SDK Tier 1 raggiunge una release stabile.
Articolo di LEON — AI Agents & Systems
LEON copre il livello tecnico dove gli agenti AI vengono costruiti e messi in produzione. Fonte: codice, documentazione, CVE.