MCP 2.0 diventa stateless: cosa cambia davvero

La specifica MCP 2026-07-28 elimina handshake e sessioni, introduce MRTR, Tasks, nuove estensioni e OAuth più rigoroso: architettura, rischi e guida alla migrazione.

2026-08-04

MCP cambia pelle. La specifica del 28 luglio 2026 elimina handshake e sessioni dal cuore del protocollo; su Streamable HTTP, ogni chiamata diventa una richiesta POST autosufficiente. Introduce inoltre un modo nuovo per gestire input dell’utente, lavori lunghi e interfacce dentro la chat. È la revisione più profonda del Model Context Protocol dal lancio.

Alcune fonti secondarie la chiamano “MCP 2.0”, ma serve una precisazione: il protocollo ufficiale è versionato 2026-07-28. Il numero 2.0 appartiene certamente alla nuova major release dell’SDK C# ufficiale di Microsoft ed è usato informalmente come etichetta sintetica per il passaggio generazionale.

MCP 2.0 o MCP 2026-07-28?

Il Model Context Protocol è lo standard aperto che collega applicazioni AI a strumenti, dati e workflow. Claude, ChatGPT, Visual Studio Code e altri client possono usare lo stesso linguaggio per invocare un server MCP che espone file, database, API o operazioni aziendali.

La nuova revisione è la quinta release della specifica. Secondo Anthropic, gli SDK MCP hanno superato 400 milioni di download mensili, quattro volte il livello di inizio anno, mentre la directory dei connettori Claude raccoglie oltre 950 server. Sono dati del produttore, utili per misurare la scala raggiunta ma non un censimento indipendente dell’intero ecosistema.

Dal protocollo con sessione al core stateless

Prima una connessione Streamable HTTP iniziava con initialize e notifications/initialized. Il server poteva restituire un header Mcp-Session-Id, che il client doveva ripresentare nelle richieste successive. In un deployment orizzontale questo legava il traffico all’istanza che conosceva la sessione, imponendo sticky routing o uno store condiviso.

La specifica 2026-07-28 rimuove handshake e sessioni a livello di protocollo. Ogni richiesta include in _meta la versione, le capacità del client e, come raccomandazione, la sua identità software. Il server risponde allo stesso modo con le proprie informazioni. Qualunque istanza compatibile può quindi elaborare la chiamata senza memoria della connessione precedente.

Stateless non significa che l’applicazione non possa conservare stato. Un server può creare un identificatore esplicito — per esempio basketId, workflowId o browserId — e farlo ripassare al modello come normale argomento dei tool. La differenza è che lo stato non rimane più nascosto nel trasporto.

Dal handshake alla richiesta autosufficiente

Il cambio può essere riassunto così: nel vecchio flusso la chiamata dipendeva da un contesto negoziato in precedenza; nel nuovo il messaggio dichiara ciò che serve per essere interpretato.

HTTP diventa una superficie operativa vera

Streamable HTTP usa un singolo endpoint che accetta POST. Ogni richiesta deve includere MCP-Protocol-Version e gli header standard Mcp-Method e, quando applicabile, Mcp-Name. Parametri selezionati possono essere riflessi in header Mcp-Param-*. Gateway, WAF, load balancer e sistemi di osservabilità possono così instradare o classificare il traffico senza analizzare il corpo JSON-RPC.

Il body resta però la fonte autorevole: se header e payload non coincidono, il server deve rispondere con un errore HeaderMismatch. La revisione aggiunge inoltre ttlMs e cacheScope ai risultati cacheabili di tool, prompt e risorse, distinguendo cache pubbliche e private.

Dire che “MCP elimina SSE” sarebbe sbagliato. Viene rimosso il vecchio endpoint GET e non è più prevista la ripresa tramite Last-Event-ID, ma una risposta a una POST può ancora essere uno stream SSE legato alla singola richiesta. Le notifiche persistenti passano invece dal nuovo subscriptions/listen.

Come funziona una richiesta MRTR

Il core stateless crea un problema: come può un tool chiedere conferma all’utente o un’informazione aggiuntiva senza una connessione bidirezionale permanente? La risposta è Multi Round-Trip Requests, o MRTR.

Il server risponde con resultType: "input_required" e deve includere almeno uno fra una mappa inputRequests e un requestState opaco; entrambi i campi sono singolarmente facoltativi. Quando sono presenti richieste di input, il client le soddisfa — elicitation, sampling o elenco delle roots — e ripete la chiamata originale con un nuovo ID JSON-RPC. Tutta la continuità necessaria viaggia nel payload.

La sicurezza è cruciale: la specifica considera requestState un input controllato dall’attaccante. Se influenza autorizzazioni o logica di business, il server deve proteggerne l’integrità, per esempio con HMAC o AEAD, e dovrebbe includere principal, scadenza breve e legame alla richiesta originaria. Per operazioni monouso serve comunque un controllo lato server contro il replay.

Tasks: lavori lunghi senza tenere aperta la connessione

MRTR gestisce più scambi relativi alla stessa operazione; MCP Tasks affronta invece job che durano secondi, ore o richiedono approvazioni. È un’estensione ufficiale, non parte obbligatoria del core.

Un server può restituire resultType: "task" con taskId, stato iniziale, TTL e intervallo di polling. Il client interroga tasks/get, invia eventuali risposte con tasks/update e può chiedere tasks/cancel. Gli stati previsti sono working, input_required, completed, failed e cancelled.

Il task ID è durevole: un client può disconnettersi e riprendere il polling. Ma la durabilità non arriva gratis. Microsoft avverte che lo store in memoria dell’SDK C# serve solo per sviluppo; deployment multiistanza e ripartenze richiedono storage condiviso persistente.

Estensioni: Apps, Tasks e autorizzazione enterprise

La release formalizza un framework per funzionalità opzionali con identificatori namespaced, negoziazione delle capacità e repository separati. Le estensioni ufficiali oggi includono:

• MCP Apps: HTML interattivo — moduli, dashboard, grafici e player — renderizzato dentro client compatibili;
• Tasks: esecuzione asincrona e handle durevoli;
• OAuth Client Credentials: autenticazione machine-to-machine;
• Enterprise-Managed Authorization: controllo centralizzato tramite identity provider aziendale.

Le estensioni sono disabilitate di default e devono essere dichiarate da entrambe le parti. La matrice ufficiale mostra già MCP Apps su Claude, ChatGPT, VS Code Copilot e altri client, ma il supporto alle estensioni di autorizzazione è molto meno uniforme. “Ufficiale” non significa quindi “disponibile ovunque”.

OAuth più rigoroso, ma non automatico

L’autorizzazione rimane opzionale nel protocollo; quando viene implementata su HTTP, la specifica la allinea a OAuth 2.1 e a standard di discovery e protezione delle risorse. I server protetti devono pubblicare Protected Resource Metadata, i client devono supportare discovery OAuth e OpenID Connect, usare PKCE e associare i token alla risorsa MCP corretta.

Una novità importante è la validazione dell’issuer: se la risposta contiene iss, il client deve confrontarlo con l’emittente registrato prima di riscattare il codice. Le credenziali devono essere indicizzate per issuer e non riutilizzate con authorization server diversi. Questo riduce mix-up e confused-deputy, ma non sostituisce la verifica applicativa di identità, ruolo, tenant e permessi a ogni richiesta.

L’estensione Enterprise-Managed Authorization usa l’IdP aziendale — per esempio Okta o Microsoft Entra — come decisore centrale. L’IT può approvare connettori, applicare policy di gruppo e revocare accessi senza far autorizzare manualmente ogni server a ogni dipendente. È una base più credibile per l’adozione enterprise, purché client, authorization server e IdP implementino davvero l’estensione.

Cosa viene deprecato

Roots, Sampling e Logging restano funzionanti ma entrano nello stato Deprecated. Le nuove implementazioni non dovrebbero adottarli: percorsi e directory possono passare come parametri o URI; i server possono chiamare direttamente i provider LLM; log e trace vanno su stderr o OpenTelemetry.

La policy introduce una finestra minima di dodici mesi: per Roots, Sampling e Logging, la prima rimozione possibile è in una revisione pubblicata non prima del 28 luglio 2027. Anche Dynamic Client Registration viene deprecato in favore dei Client ID Metadata Documents. I valori includeContext: "thisServer" e "allServers", già deprecati dalla revisione 2025-11-25, seguiranno la rimozione di Sampling.

Il vecchio trasporto HTTP+SSE costituisce un’eccezione transitoria: era già deprecato prima della nuova policy e diventa eleggibile alla rimozione tre mesi dopo che SEP-2596 raggiunge lo stato Final, non dopo la finestra generale di dodici mesi. La migrazione consigliata resta Streamable HTTP.

Agent Skills: utili, ma non sono MCP 2.0

La documentazione 2026-07-28 aggiunge una guida per costruire server con Agent Skills. Sono pacchetti di istruzioni — file SKILL.md e riferimenti — che aiutano un coding agent a scegliere deployment, pattern dei tool, autenticazione e packaging.

Il plugin di riferimento mcp-server-dev offre tre skill: build-mcp-server, build-mcp-app e build-mcpb. È un acceleratore per sviluppatori, non un messaggio o una capacità del protocollo. Confondere Agent Skills con una feature wire-level di MCP 2026-07-28 porterebbe a una migrazione sbagliata.

L’SDK C# 2.0 e il rollout di Claude

Microsoft rende lo stateless il default del trasporto HTTP in C# e separa Apps e Tasks in pacchetti opt-in. Gli API stabili v1 continuano a compilare e l’SDK offre fallback verso implementazioni precedenti; le deprecazioni diventano warning. La vecchia Tasks sperimentale è però incompatibile con il nuovo disegno e richiede migrazione.

Questo supporto non rende il nuovo wire format universalmente retrocompatibile. La specifica cambia in modo breaking handshake, risultati e richieste server-to-client; la compatibilità dipende dai fallback implementati da ciascun SDK. In ambienti misti bisogna testare ogni coppia client-server.

Claude sta distribuendo il supporto nei propri prodotti. Anthropic associa alla release MCP Apps, enterprise-managed auth, dashboard di osservabilità e MCP tunnels in research preview per raggiungere server in reti private senza endpoint pubblico. Queste ultime sono capacità di Claude, non requisiti generali del protocollo.

Checklist di migrazione MCP 2026-07-28

1. Censire dipendenze legacy: handshake, Mcp-Session-Id, GET stream, vecchie Tasks, Roots, Sampling e Logging.
2. Rendere ogni richiesta autosufficiente: versione, capacità e client info in _meta; header HTTP coerenti con il body.
3. Esplicitare lo stato applicativo: handle firmati o persistenti come argomenti dei tool, non sessioni nascoste.
4. Implementare discovery e fallback: server/discover, errori di versione e test fra revisioni.
5. Convertire le richieste inverse in MRTR: proteggere requestState da manipolazione e replay.
6. Spostare i job lunghi su Tasks: store durevole, TTL, polling, cancellazione e input intermedi.
7. Aggiornare gateway e osservabilità: routing sugli header, trace context OpenTelemetry e correlazione fra più richieste.
8. Rifare i test OAuth: issuer, audience, resource indicator, scope escalation e revoca.
9. Rilasciare in canary: misurare errori e latenza prima di ritirare il percorso precedente.

Cosa non sappiamo ancora

L’adozione reale sarà graduale. Le matrici delle estensioni sono mantenute dalla community e possono inseguire i rilasci; Anthropic parla esplicitamente di rollout; gli SDK non hanno tutti lo stesso livello di fallback. Restano da misurare sul campo costi operativi di Tasks, supporto MRTR nei client, interoperabilità OAuth fra IdP e server e qualità dell’osservabilità end-to-end.

Non va inoltre confusa la rimozione delle sessioni di protocollo con una riduzione automatica del rischio. Un’azione può ora attraversare molte richieste e durare ore: inventario dei server, autorizzazioni per richiesta e correlazione dei task diventano più importanti, non meno.

La valutazione di Velthub

MCP 2026-07-28 porta il protocollo dal modello “connessione intelligente” a un’architettura più vicina ai servizi web moderni. Stateless core, header instradabili, caching, MRTR e Tasks risolvono problemi concreti di deployment. Il framework delle estensioni evita inoltre di gonfiare il core.

Il prezzo è una migrazione non banale: alcune API spariscono, altre cambiano forma e la compatibilità dipende dagli SDK. La release merita un giudizio alto per direzione architetturale e disciplina di governance, ma non il massimo finché supporto client ed estensioni enterprise non saranno più uniformi.

Domande frequenti

MCP 2.0 è il nome ufficiale?

No. La specifica ufficiale usa la data 2026-07-28. “2.0” è la major version dell’SDK C# Microsoft ed è diventata un’etichetta informale per la revisione.

MCP è completamente stateless?

Il core del protocollo sì: niente handshake o session ID. Le applicazioni possono comunque mantenere stato tramite handle espliciti e le estensioni Tasks usano storage durevole.

SSE è stato eliminato?

No. È stato rimosso il vecchio endpoint GET e non c’è resumability con Last-Event-ID. Streamable HTTP può ancora restituire SSE per una singola richiesta e subscriptions/listen usa uno stream lungo per le notifiche.

Serve riscrivere subito tutti i server MCP?

Non necessariamente, ma bisogna censire dipendenze da sessioni e feature deprecate. Alcuni SDK offrono fallback; la vecchia Tasks sperimentale e i flussi server-initiated richiedono interventi specifici.

Agent Skills fa parte del protocollo?

No. È un formato di istruzioni per coding agent usato dalla documentazione per accelerare la costruzione di server, Apps e bundle MCP.

La nuova autorizzazione rende MCP sicuro automaticamente?

No. Rafforza OAuth, discovery, issuer e audience binding. Restano obbligatorie validazione dei token, autorizzazioni per operazione, protezione di requestState, gestione dei replay e monitoraggio applicativo.

https://velthub.ai/blog/mcp-2-0-stateless-specifica-2026-07-28-v2