MCP 2026-07-28: cosa cambia per server e integrazioni
MCP 2026-07-28 non è un semplice aggiornamento di libreria. La nuova revisione cambia il modo in cui client e server negoziano il protocollo, scoprono le capacità e gestiscono richieste, routing e approvazioni.
Per chi ha già un’integrazione in produzione, la domanda utile non è “conviene aggiornare?”, ma quali dipendenze vanno verificate prima di spostare traffico reale.
Il Model Context Protocol serve a collegare applicazioni AI, dati e strumenti attraverso un’interfaccia comune. Se occorre partire dalle basi, ho già spiegato cos’è MCP e perché riduce le integrazioni ad hoc. Qui il punto è diverso: capire l’impatto operativo della specifica pubblicata il 28 luglio 2026.
MCP 2026-07-28: dal protocollo con sessione al core stateless
Nelle revisioni precedenti, la connessione iniziava con initialize e proseguiva usando un identificatore di sessione. La revisione 2026-07-28 rende invece ogni richiesta autosufficiente: versione del protocollo e informazioni sul client viaggiano nella richiesta, mentre il server può dichiarare le proprie capacità con server/discover.
“Stateless” non significa che l’applicazione debba dimenticare tutto. Significa che lo stato non è più implicito nel trasporto. Conversazioni, task lunghi o flussi multi-passaggio possono continuare a esistere, ma devono essere rappresentati con handle espliciti e responsabilità chiare.
Handshake iniziale, sessione mantenuta dal trasporto e maggiore dipendenza dal singolo nodo che ha aperto la connessione.
Richieste autodescrittive, scoperta opzionale delle capacità e stato applicativo gestito in modo esplicito.
Quattro cambiamenti che incidono sul progetto
1. Routing più leggibile
Gli header Mcp-Method e Mcp-Name permettono a gateway e proxy di instradare le richieste senza interpretare l’intero payload JSON-RPC.
2. Elenchi memorizzabili in cache
Le risposte di tipo list possono dichiarare durata e ambito della cache. È utile per ridurre chiamate ripetitive, purché invalidazione e autorizzazioni siano coerenti.
3. Approvazioni senza stream sospesi
Il flusso MRTR sostituisce le richieste server-initiated tenute aperte: il server segnala che serve un input e il client riprende l’operazione quando lo ha raccolto.
4. Estensioni più modulari
Task, logging e altre funzioni avanzate si spostano verso estensioni. Alcune capacità storiche restano disponibili durante una finestra di deprecazione, non per sempre.
Compatibilità: il rischio vero della migrazione
Gli SDK di fascia principale supportano la nuova revisione, ma questo non garantisce che tutti i client, i server e i gateway di una catena siano già allineati. La documentazione TypeScript prevede infatti strategie di negoziazione come auto, legacy o il pin esplicito alla versione 2026-07-28.
La modalità automatica è comoda per una transizione graduale. In ambienti regolati o difficili da osservare, un pin esplicito può essere più prudente: impedisce che il comportamento cambi solo perché una dipendenza è stata aggiornata.
| Area | Decisione da prendere | Prova da conservare |
|---|---|---|
| Negoziazione | Auto, fallback legacy o versione fissata | Matrice client-server testata |
| Gateway | Routing per metodo e nome | Log con header e destinazione |
| Cache | TTL e ambito per utente o organizzazione | Test di isolamento e invalidazione |
| Approvazioni | Ripresa MRTR e scadenze | Casi di consenso, rifiuto e timeout |
Checklist di migrazione in cinque passaggi
- Mappa le versioni reali. Registra SDK, client, server, proxy e componenti di autenticazione, non soltanto il repository principale.
- Prova le combinazioni in laboratorio. Verifica discovery, chiamate agli strumenti, errori, timeout e fallback prima di intervenire in produzione.
- Aggiorna gateway e controlli di accesso. I nuovi header aiutano il routing, ma non sostituiscono l’autorizzazione sul payload e sull’identità.
- Testa i punti in cui serve una persona. Approvazione, diniego e interruzione devono restare osservabili. Per questi aspetti vale la stessa disciplina descritta nella guida alla sicurezza degli agenti AI.
- Rilascia per segmenti. Usa telemetria, soglie di errore e un rollback verificato; solo dopo amplia il traffico.
La nuova architettura rende MCP più adatto a deployment distribuiti, ma sposta parte della complessità dal trasporto al progetto. È un miglioramento quando versioni, stato, autorizzazioni e osservabilità sono trattati come decisioni esplicite.
Fonti: annuncio ufficiale MCP 2026-07-28; guida di migrazione dell’SDK TypeScript; versioni del protocollo nell’SDK ufficiale.
Serve una verifica prima della migrazione?
Posso aiutarti a mappare l’integrazione, costruire la matrice di compatibilità e definire approvazioni e rollback.
Valutiamo il tuo caso MCP