MCP 2026-07-28: cosa cambia per chi costruisce agenti IA

Il 28 luglio 2026 è uscita la revisione 2026-07-28 del Model Context Protocol (MCP), il protocollo con cui un agente IA usa strumenti e dati esterni. Il blog ufficiale la descrive come il passaggio da un protocollo bidirezionale con stato a uno di richiesta e risposta senza stato: ogni richiesta può arrivare a qualunque istanza dietro un normale bilanciatore. Fonte: blog MCP e changelog.

Cosa è cambiato

• Niente sessioni né handshake. Sono rimossi l’header Mcp-Session-Id e lo scambio initialize. Ogni richiesta porta versione di protocollo e capability del client in _meta. Un nuovo metodo, server/discover, annuncia versioni e capability del server.
• Trasporto Streamable HTTP più semplice. Ogni messaggio è una POST verso un solo endpoint; la ripresa degli stream SSE è rimossa. Compaiono header come Mcp-Method e Mcp-Name, utili a bilanciatori e firewall applicativi.
• Richieste del server al client. Roots, Sampling ed Elicitation non viaggiano più come richieste dal server: il server risponde con un risultato input_required e il client ritenta con le risposte (schema chiamato Multi Round-Trip Requests).
• Cache. I risultati degli elenchi (tools/list e simili) portano ttlMs e cacheScope.
• Task. I task sperimentali escono dal nucleo e diventano un’estensione ufficiale.

Autenticazione

L’autorizzazione resta opzionale. Se usi HTTP, la specifica indica OAuth 2.1 con Protected Resource Metadata (RFC 9728) e il parametro resource (RFC 8707). La registrazione preferita dei client passa ai Client ID Metadata Documents; la Dynamic Client Registration è deprecata. Il server deve verificare che il token sia stato emesso per lui e non deve inoltrare token ricevuti.

Cosa migrare, in ordine

1. Inventario degli stati. Se il tuo server teneva stato per sessione, sposta lo stato in handle espliciti (per esempio un identificativo di carrello) passati come argomenti, con autorizzazione verificata a ogni chiamata.
2. Aggiornamento degli SDK. Gli SDK di primo livello sono TypeScript, Python, C#, Go, Rust e Ruby; per TypeScript e Python esistono versioni 2 che supportano la nuova revisione. Controlla le guide di migrazione di ciascun SDK, perché le date e i numeri di versione vanno riconfermati sulle pagine delle release.
3. Compatibilità. Un client moderno non parla con un server solo legacy, e viceversa. Durante la transizione servono client e server che supportano entrambe le epoche.
4. Input all’utente. Rivedi i punti in cui il server chiedeva dati al client: vanno riscritti con il nuovo schema input_required.
5. Deprecazioni. Roots, Sampling, Logging e HTTP+SSE restano per almeno dodici mesi: pianifica l’uscita.

Rischi di sicurezza da controllare

La pagina ufficiale Security Best Practices elenca tra l’altro: confused deputy nei proxy OAuth, inoltro di token (vietato), SSRF nella scoperta OAuth, dirottamento degli handle di stato (possedere un handle non è autenticazione) e server MCP locali non isolati. Le annotazioni dei tool vanno considerate non attendibili salvo server fidato, e per le azioni sensibili la specifica raccomanda un essere umano nel ciclo.

Cosa non è verificato

Date e versioni esatte delle release degli SDK su GitHub e i valori predefiniti delle annotazioni dei tool non sono stati confermati su fonte primaria in questa nota. Prima di migrare, leggi le guide ufficiali degli SDK che usi.

Per progettare un agente con permessi minimi, valutazioni e controlli, vedi Agenti IA e automazioni con LLM.