MCP 2.0 diventa stateless: cosa cambia con la specifica 2026-07-28

Perché se ne parla#

Il 28 luglio 2026 è uscita una nuova revisione del Model Context Protocol, la più radicale da quando esiste. Sparisce la "stretta di mano" iniziale, sparisce la sessione legata alla connessione, e su Streamable HTTP ogni chiamata diventa una singola POST che contiene tutto il necessario per essere capita. In più arrivano strumenti nuovi per chiedere dati all'utente a metà lavoro, per le operazioni lunghe e per mostrare interfacce dentro la chat.

In giro la trovate come "MCP 2.0", ma il nome ufficiale è la data: 2026-07-28. Il 2.0 appartiene alla nuova versione principale dell'SDK C# pubblicato da Microsoft, ed è diventato per comodità il soprannome del salto di generazione.

MCP, per chi arriva ora, è lo standard aperto con cui un'applicazione di intelligenza artificiale si collega a strumenti, dati e flussi di lavoro: una presa universale, che Claude, ChatGPT, Visual Studio Code e parecchi altri programmi sanno usare. Dall'altra parte un server MCP espone file, database, API o operazioni del gestionale (il quadro generale è nella guida su cosa sono gli agenti AI).

È la quinta release della specifica, e arriva su un ecosistema cresciuto in fretta. I numeri qui sotto sono di Anthropic: misurano la crescita, non sono un censimento indipendente.

Prima e dopo, in una tabella#

Richieste che bastano a sé stesse#

Come funzionava prima#

Una connessione Streamable HTTP cominciava con un piccolo rito: il client mandava initialize, poi notifications/initialized. Il server poteva assegnare un identificativo nell'header Mcp-Session-Id, che il client doveva ripresentare a ogni chiamata.

Con più istanze dietro un bilanciatore, la richiesta doveva tornare proprio all'istanza che "si ricordava" di voi (le sticky session), oppure tutte dovevano condividere un archivio delle sessioni. Come un ristorante dove solo il cameriere che ha preso l'ordinazione sa cosa avete chiesto.

Come funziona adesso#

Handshake e sessioni escono dal protocollo. Nel campo _meta ogni richiesta porta la versione del protocollo, ciò che il client sa fare e, come buona pratica, il nome del software che la manda; il server risponde allo stesso modo. L'ordinazione ora è scritta sul foglietto, e qualunque cameriere può leggerla: qualsiasi istanza compatibile risponde a qualsiasi chiamata, e serverless, esecuzione sull'edge e bilanciamento a rotazione diventano scelte naturali.

Senza stato non vuol dire senza memoria#

"Stateless" riguarda il protocollo, non la vostra applicazione. Un server può ancora ricordare un carrello o un flusso di approvazione, purché lo faccia alla luce del sole: crea un identificativo (per esempio basketId, workflowId o browserId) e il modello lo ripassa come un argomento qualsiasi.

{
  "name": "aggiungi_al_carrello",
  "arguments": { "basketId": "b-7f3a", "prodotto": "POLTRONA-BLU", "quantita": 1 }
}

I nomi sono d'esempio. Il punto è che lo stato non si nasconde più nel trasporto: sta negli argomenti, dove si vede e si controlla.

HTTP leggibile anche da chi sta in mezzo#

Streamable HTTP usa un unico endpoint che riceve POST. Ora ogni richiesta dichiara negli header versione (MCP-Protocol-Version) e metodo (Mcp-Method), più Mcp-Name quando riguarda un elemento con un nome, come un tool; alcuni parametri possono finire anche in header Mcp-Param-*. Con valori d'esempio:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: crea_preventivo

Così gateway, firewall applicativi (WAF), bilanciatori e monitoraggio possono instradare o classificare il traffico leggendo l'etichetta, senza aprire il pacco JSON-RPC. Fa fede comunque il corpo: se non coincide con gli header, il server risponde con l'errore HeaderMismatch.

Altre due novità:

• Cache. I risultati memorizzabili di tool, prompt e risorse possono indicare ttlMs (per quanto valgono) e cacheScope (cache pubblica o privata).

• SSE non è morto. Spariscono il vecchio endpoint GET e la ripresa con Last-Event-ID, ma la risposta a una POST può ancora arrivare in streaming SSE, legata a quella sola richiesta. Per le notifiche continue c'è il nuovo subscriptions/listen.

MRTR: chiedere qualcosa all'utente senza una linea aperta#

Senza sessione, come fa un tool a chiedere una conferma o un dato mancante a metà lavoro? La specifica risponde con MRTR, Multi Round-Trip Requests: richieste che si completano in più giri.

Client → tools/call (id 41)
Server ← resultType: "input_required" con inputRequests e/o requestState
Client   soddisfa le richieste: elicitation, sampling o elenco delle roots
Client → stessa chiamata con un nuovo id (42) + inputResponses + requestState
Server ← risultato finale

La risposta del server contiene resultType: "input_required" e porta con sé la mappa inputRequests con le domande, un requestState opaco (un blocco di dati che il client non interpreta e si limita a restituire) oppure entrambi: non possono mancare tutti e due. Il client raccoglie le risposte e rimanda la stessa chiamata, questa volta con un ID JSON-RPC diverso. La continuità viaggia nel messaggio, nessuna istanza deve ricordare niente.

Il punto delicato: requestState#

La specifica lo tratta come un dato che un attaccante può manipolare, perché passa dalle mani del client. Quando decide permessi o regole di business va blindato contro le modifiche, con una firma HMAC o una cifratura autenticata AEAD, e conviene che contenga l'utente (il principal), una scadenza breve e il legame con la richiesta di partenza. Per le operazioni da eseguire una volta sola serve anche un controllo lato server contro il replay.

Tasks: lavori lunghi senza connessione aperta#

MRTR gestisce più scambi dentro la stessa operazione. Tasks serve per lavori che durano secondi o ore, o che aspettano un'approvazione. Fa parte delle estensioni ufficiali, quindi il nucleo non la impone.

Il server restituisce resultType: "task" con un taskId, lo stato iniziale, una validità (TTL) e l'intervallo consigliato per ricontrollare. Poi:

tasks/get     a che punto è il lavoro?
tasks/update  invia una risposta, se il task ne chiede una a metà strada
tasks/cancel  annulla il lavoro

Gli stati sono cinque: working, input_required, completed, failed, cancelled. L'identificativo è durevole, quindi il client può scollegarsi e riprendere più tardi, ma la durata va costruita: Microsoft avverte che l'archivio in memoria dell'SDK C# va bene solo in sviluppo, e con più istanze o riavvii serve uno storage condiviso e persistente. Cioè un database in più da gestire.

Le estensioni, e dove funzionano davvero#

La release dà una forma ufficiale alle funzioni opzionali: identificativi con il proprio spazio dei nomi, negoziazione delle capacità, repository separati. Le estensioni ufficiali sono quattro:

• MCP Apps: HTML interattivo (moduli, dashboard, grafici, player) mostrato dentro i client compatibili;

• Tasks: esecuzione asincrona con identificativi durevoli;

• OAuth Client Credentials: autenticazione tra macchine;

• Enterprise-Managed Authorization: accessi governati dal sistema di identità aziendale.

Sono spente di default e funzionano solo se entrambe le parti le dichiarano. La tabella ufficiale elenca MCP Apps già attive in Claude, ChatGPT, VS Code Copilot e diversi altri, mentre per le estensioni di autorizzazione il quadro è molto più disomogeneo. Ufficiale non vuol dire disponibile ovunque.

OAuth più severo, ma non fa il lavoro al posto vostro#

L'autorizzazione resta facoltativa. Chi la implementa su HTTP segue OAuth 2.1 e gli standard di scoperta e protezione delle risorse: i server protetti pubblicano i Protected Resource Metadata, i client supportano la scoperta OAuth e OpenID Connect, usano PKCE e legano ogni token alla risorsa MCP giusta.

La novità principale riguarda l'emittente. Se la risposta contiene iss, il client lo verifica rispetto all'emittente che ha registrato, e solo dopo scambia il codice; le credenziali si archiviano per emittente e non si riusano con server di autorizzazione diversi. Si chiudono così gli attacchi di tipo mix-up e confused deputy, ma a ogni richiesta il server deve comunque controllare identità, ruolo, organizzazione e permessi dell'utente.

L'estensione Enterprise-Managed Authorization mette al centro il provider di identità aziendale, come Okta o Microsoft Entra: l'IT approva i connettori, applica regole per gruppi e revoca accessi senza che ogni dipendente autorizzi a mano ogni server. È la base più credibile per un'azienda strutturata, a patto che client, server di autorizzazione e provider di identità la implementino davvero.

Cosa viene deprecato, e con che tempi#

Roots, Sampling e Logging funzionano ancora ma sono deprecated: le implementazioni nuove non dovrebbero usarli.

Tra deprecazione e rimozione passano almeno dodici mesi: Roots, Sampling e Logging potranno sparire solo in una revisione pubblicata dal 28 luglio 2027 in poi. I valori includeContext: "thisServer" e "allServers", deprecati già dalla revisione 2025-11-25, se ne andranno insieme a Sampling.

Fa eccezione il vecchio trasporto HTTP+SSE, deprecato prima che la regola esistesse: potrà essere rimosso tre mesi dopo che la proposta SEP-2596 sarà diventata Final, senza aspettare l'anno. Chi lo usa dovrebbe passare a Streamable HTTP.

Agent Skills: utili, ma fuori dal protocollo#

La documentazione della 2026-07-28 include una guida per costruire server con le Agent Skills: pacchetti di istruzioni (un file SKILL.md più riferimenti) che aiutano un agente di programmazione a scegliere deployment, struttura dei tool, autenticazione e pacchettizzazione. Il plugin di riferimento mcp-server-dev ne contiene tre: build-mcp-server, build-mcp-app e build-mcpb. Fanno risparmiare tempo a chi sviluppa, ma non sono una funzione del protocollo e non vanno nella lista delle cose da migrare.

L'SDK C# 2.0 e il supporto in Claude#

Con l'SDK C# 2.0 Microsoft rende stateless il comportamento predefinito del trasporto HTTP e sposta Apps e Tasks in pacchetti da aggiungere solo se servono. Le API stabili della versione 1 continuano a compilare, l'SDK sa ricadere sulle implementazioni precedenti e le deprecazioni producono avvisi, non errori. Fa eccezione la vecchia Tasks sperimentale, incompatibile con il nuovo disegno.

Ma i ripieghi di un SDK non rendono compatibile tutto il resto: avvio, risultati e richieste dal server al client cambiano in modo incompatibile, e in un ambiente misto va provata ogni coppia di client e server.

Anthropic sta distribuendo il supporto in Claude gradualmente. Insieme alla release ha annunciato MCP Apps, l'autorizzazione gestita dall'azienda, dashboard di osservabilità e, in anteprima di ricerca, gli MCP tunnels, per raggiungere server in reti private senza un endpoint pubblico. Sono funzioni di Claude, non requisiti del protocollo.

La migrazione in nove passi#

Se avete già server MCP in funzione, procederei così:

1. Inventario: handshake, Mcp-Session-Id, stream su GET, vecchia Tasks, Roots, Sampling, Logging.

2. Richieste autosufficienti: versione, capacità e dati del client in _meta, header coerenti con il corpo.

3. Stato esplicito: identificativi firmati o persistenti passati ai tool, al posto delle sessioni implicite.

4. Scoperta e ripieghi: server/discover, errori di versione, test tra revisioni.

5. MRTR al posto delle richieste avviate dal server, con requestState protetto da manomissioni e replay.

6. Tasks per i lavori lunghi: archivio durevole, TTL, polling, annullamento, input intermedi.

7. Gateway e monitoraggio: instradamento sugli header, tracciamento OpenTelemetry, collegamento tra le richieste della stessa operazione.

8. Test OAuth da rifare: emittente, destinatario del token, resource indicator, allargamento degli scope, revoca.

9. Rilascio in canary: poco traffico sul percorso nuovo, misurando errori e latenza prima di spegnere il vecchio.

Se il server tocca gestionali o dati dei clienti, è anche l'occasione per rivedere permessi e tracciabilità: lavoro da sistemi AI su misura.

Cosa non sappiamo ancora#

L'adozione sarà graduale: le tabelle delle estensioni le cura la community e possono restare indietro, Anthropic parla di distribuzione progressiva, gli SDK non hanno tutti gli stessi ripieghi. Vanno ancora misurati sul campo il costo operativo di Tasks, il supporto a MRTR nei client, l'interoperabilità OAuth tra provider di identità e server, la qualità del monitoraggio da un capo all'altro.

E togliere la sessione non riduce il rischio da sé. Adesso una singola operazione può spezzarsi in tante richieste e protrarsi per ore: sapere quali server sono attivi, autorizzare ogni singola richiesta e collegare i pezzi dello stesso task conta più di prima.

Il mio parere#

Con la 2026-07-28 MCP smette di assomigliare a una telefonata, dove entrambi devono restare in linea, e si avvicina a un normale servizio web moderno. Nucleo senza stato, header leggibili, cache, MRTR e Tasks risolvono problemi che chi ha messo MCP in produzione conosce bene, e le estensioni evitano di gonfiare il nucleo con funzioni che servono solo ad alcuni.

Il conto è una migrazione vera: alcune API spariscono, altre cambiano forma, e la compatibilità dipende dall'SDK. Sulla direzione e sul metodo il mio giudizio è molto positivo; diventerà pieno quando il supporto dei client e delle estensioni aziendali sarà più uniforme. Nel frattempo, nessuna fretta: ma sapere da subito quanto i vostri server dipendono da sessioni e funzioni deprecate costa poco e vi evita sorprese.

Domande frequenti#