MCP Diventa Stateless: Guida alla Migrazione e Impatto sui Server

MCP Diventa Stateless: Cosa Cambia con la Specifica 2026-07-28

Con la specifica del 28 luglio 2026, il protocollo MCP introduce un cambiamento tanto semplice quanto profondo: diventa stateless. Se questa parola ti suona come un campanello d'allarme, probabilmente non hai torto. La migrazione a un'architettura MCP stateless richiede un nuovo modo di pensare.

In parole povere, l'intero concetto di sessione a livello di protocollo è stato eliminato. L'handshake di inizializzazione non esiste più e, di conseguenza, l'header Mcp-Session-Id è stato eliminato. Se il tuo server si basa sulle sessioni, questo cambiamento ti riguarda direttamente.

La gestione dello stato non è sparita, ma ha cambiato casa: è passata dal protocollo alla tua applicazione.

Cosa significa che il protocollo MCP è diventato stateless?

Un protocollo stateless (senza stato) è un protocollo di comunicazione in cui ogni richiesta dal client al server deve contenere tutte le informazioni necessarie al server per comprenderla ed elaborarla. Il server non memorizza alcuna informazione sul client tra una richiesta e l'altra, rendendo ogni interazione indipendente e atomica.

Migrazione a MCP Stateless: Dagli Handshake agli Handle

Per anni, abbiamo pensato alle sessioni come a un post-it invisibile che il server attaccava a ogni client. Su quel post-it c'erano appunti essenziali: chi era l'utente, cosa stava facendo, a quali strumenti aveva accesso. Ora, quel blocchetto di post-it è stato gettato via, e per una buona ragione.

Perché l'handshake stateful era un problema

Immagina l'handshake come un vecchio centralinista che doveva tenere una linea dedicata aperta per ogni conversazione. Questo approccio, tecnicamente noto come stateful, presentava diversi svantaggi:

• Complessità e fragilità: Mantenere lo stato delle sessioni era complesso e soggetto a errori.

• Difficoltà di scalabilità: Scalare in orizzontale era un incubo, poiché ogni istanza del server doveva accedere allo stesso "schedario" di sessioni.

• Overhead significativo: Stabilire e mantenere una sessione per ogni client consumava risorse.

• Caching inefficace: Endpoint come tools/list erano impossibili da mettere in cache, poiché la loro risposta dipendeva dalla sessione.

Come ha osservato anche The Register, l'evoluzione del protocollo ha reso questo cambiamento inevitabile. La rimozione dell'handshake allinea MCP alle moderne architetture web, come le API RESTful, migliorando manutenibilità e scalabilità.

Il nuovo paradigma: gli handle come "gettoni" per lo stato

Lo stato non si può eliminare. Flussi di lavoro come un acquisto a più passaggi richiedono di "ricordare" le scelte precedenti. La soluzione proposta dalla nuova specifica è tanto semplice quanto efficace: gli handle.

La metafora migliore è quella del gettone del guardaroba. Ti viene dato un gettone (una stringa opaca) e quando lo restituisci, l'addetto sa esattamente quale cappotto darti. Lo stato non è sparito, è stato incapsulato nel gettone.

Tecnicamente, per ogni operazione che richiede memoria, il server genera un handle. Il client lo riceve e lo passa come argomento nella chiamata successiva. Sarà il server a usare quella stringa per recuperare il contesto da un database (nel nostro caso, Firestore).

Nel nostro monorepo, abbiamo implementato una funzione che genera un handle sicuro. Ecco uno snippet semplificato:

// Esempio di generazione handle in TypeScript con Firestore
import { firestore } from './firebase';

import { randomBytes } from 'crypto';
async function createStatefulOperation(initialData: any): Promise<string> {

  const handle = randomBytes(24).toString('hex');

  const operationState = {

    ...initialData,

    createdAt: new Date(),

  };
  await firestore.collection('mcp_handles').doc(handle).set(operationState);

  return handle;

}

Il client riceve l'handle e lo usa nelle richieste successive. Il server, a sua volta, avrà una funzione getOperationState(handle) che legge da Firestore e ricostruisce il contesto. Semplice, sicuro e scalabile.

Logica e Autorizzazione in un'Architettura MCP Stateless

L'abbandono delle sessioni costringe a ripensare due aree fondamentali: la logica di business condizionale e, soprattutto, l'autorizzazione.

Le liste di tool non cambiano più per connessione: l'impatto su `tools/list`

Prima si usavano le sessioni per personalizzare la risposta di tools/list in base all'utente. Con il nuovo paradigma MCP stateless, la risposta di tools/list deve essere deterministica e "cacheable".

La personalizzazione ora deriva da informazioni esplicite passate in ogni richiesta. Invece di leggere un ID utente dalla sessione, il nostro server ispeziona l'header Authorization, decodifica un token JWT e determina i permessi dai "claim" del token. Il vantaggio è una maggiore chiarezza: il perché un utente veda un certo tool è scritto nel token, non nascosto in uno stato server-side.

Il nuovo framework opt-in e i Client ID Metadata Documents

Senza sessioni, ogni chiamata è un incontro con uno sconosciuto. Per standardizzare l'autorizzazione, la nuova specifica introduce un framework "opt-in" più robusto.

Un elemento chiave sono i Client ID Metadata Documents. Si tratta di un documento JSON, ospitato su un URL pubblico, che contiene metadati sul client (chi è, chiavi pubbliche, etc.). Questo meccanismo permette al server di verificare l'identità del client in modo sicuro e decentralizzato, un passo fondamentale per l'adozione in contesti enterprise.

Stabilità del Protocollo MCP: La Nuova Garanzia per il Futuro

Questo cambiamento, sebbene impegnativo, porta con sé una promessa fondamentale per chiunque investa su MCP a lungo termine.

Dodici mesi minimi tra deprecazione e rimozione

Il team di MCP ha introdotto una nuova policy di deprecazione ferrea, come delineato nel nuovo roadmap del protocollo. Qualsiasi funzionalità, prima di essere rimossa, sarà marcata come "deprecated" per un periodo minimo di dodici mesi.

Questo non è un dettaglio tecnico, è un segnale di maturità. Significa che il protocollo è entrato in un'era di stabilità e prevedibilità, dando ai team di sviluppo un anno di preavviso per pianificare le modifiche.

Un segnale di stabilità per chi investe su MCP

Tradotto in valore di business, questa policy significa: prevedibilità e riduzione dei costi di manutenzione. La storia dei protocolli, come mostra una dettagliata timeline delle versioni di MCP, è spesso costellata di cambiamenti rapidi. Questa nuova garanzia protegge l'investimento tecnologico.

Questo cambiamento verso un'architettura stateless è probabilmente l'ultimo di questa portata. Il futuro sarà fatto di evoluzioni incrementali. Per chi era in attesa del momento giusto per adottare MCP seriamente, quel momento è arrivato.

Checklist di Migrazione a MCP Stateless: La Nostra Esperienza

Dalla teoria alla pratica. Ecco la checklist che abbiamo seguito per aggiornare il nostro server di produzione con oltre 150 tool.

1. Step 1: Cerca e distruggi il codice di handshake e sessione
   
   Il primo passo è stato una ricerca globale per Mcp-Session-Id e per la logica dell'endpoint di inizializzazione, rimuovendo tutto il codice obsoleto relativo alla gestione delle sessioni.

2. Step 2: Rendi tools/list stateless e basato su token
   
   Abbiamo modificato la funzione per basare la sua logica esclusivamente sui parametri della richiesta e sull'header Authorization: Bearer <token>, rafforzando la nostra gestione dei token JWT.

3. Step 3: Implementa la logica degli handle (con Firestore)
   
   Successivamente, abbiamo identificato i flussi multi-step e creato le funzioni per generare, salvare e recuperare lo stato associato a un handle, usando Firestore come backend, come mostrato nel codice di esempio.

4. Step 4: Rivedi tutta la logica di autorizzazione per-richiesta
   
   Abbiamo implementato un middleware per tutte le rotte sensibili. Questo middleware estrae e valida il token dall'header `Authorization`, allegando i "claim" dell'utente alla richiesta per la logica a valle.

5. Step 5: Aggiorna i test di integrazione per flussi stateless
   
   Abbiamo riscritto la nostra suite di test per simulare il nuovo flusso: una prima chiamata ottiene un handle, e le chiamate successive lo includono esplicitamente nei parametri.

La transizione a un MCP stateless è un'evoluzione architetturale. Richiede di abbracciare la filosofia di interazioni atomiche e autosufficienti, ma il risultato è un sistema più robusto, scalabile e moderno.

Questa migrazione può sembrare un sentiero impervio, ma non devi affrontarlo da solo. In Orma Digital abbiamo già percorso questa strada e possiamo aiutarti a partire con il piede giusto. Il nostro team di esperti in sviluppo web a Roma è qui per guidarti: contattaci per una consulenza e costruiamo insieme la tua prossima applicazione agentica.