MCP diventa stateless: perché è giusto e cosa mi costa

La specifica MCP 2026-07-28 fa una cosa che a me costa lavoro e che, nonostante questo, penso sia giusta: smonta il modello bidirezionale stateful e lo riporta a un onesto request/response. Niente più assunzione che client e server restino agganciati per tutta la durata di una conversazione. Ogni chiamata arriva, viene servita, finisce lì.

Ho costruito due MCP server su misura, uno per Adobe Commerce e uno per Adobe Experience Manager, progettati quando lo stato di sessione era un dato di fatto su cui appoggiarsi. Non ho ancora messo mano alla migrazione: quello che segue è il ragionamento di chi guarda la specifica e prova a capire dove verrà colpito, non il resoconto di chi è già passato dall’altra parte.

Perché lo stateless è la mossa giusta, senza girarci intorno

Il modello stateful ha un difetto che nel giro di poche settimane di lavoro reale diventa evidente: presuppone che ci sia una macchina, da qualche parte, che tiene viva una sessione. Sul laptop di uno sviluppatore è banale. In un’infrastruttura aziendale è il punto esatto in cui la conversazione con l’IT si blocca.

Un server che pretende connessioni persistenti non gira su una funzione serverless, non gira bene sull’edge, non scala orizzontalmente senza uno store di sessione condiviso che diventa a sua volta un componente da gestire e mettere in sicurezza. Ogni volta che ho dovuto spiegare a un reparto IT come sarebbe stato ospitato un MCP server, la risposta implicita era la stessa: questa cosa non assomiglia a niente di quello che sappiamo già far girare.

Il request/response invece assomiglia a qualcosa di familiare. È un endpoint HTTP. Sta dietro un load balancer, sta dietro un WAF, si autentica con OAuth, si logga, si scala. Aggiungici l’autorizzazione OAuth e OIDC più solida e i tunnel di rete privati per gli enterprise, e la specifica comincia ad assomigliare a qualcosa che un architetto di sicurezza può approvare senza doversi inventare eccezioni. Le estensioni versionate per Apps e Tasks vanno nella stessa direzione: si versiona quello che cambia, invece di far crescere il core.

Il segnale di adozione conferma la traiettoria: MCP ha superato i 400 milioni di download SDK mensili, circa quattro volte in un anno. Un protocollo con quei numeri non può restare uno strumento da workstation. E l’infrastruttura è stateless quasi per definizione.

Il conto lo paga chi si era appoggiato alla sessione, e io sono tra quelli

Detto questo, non faccio finta che sia gratis. Il pezzo del mio MCP Commerce di cui vado più orgoglioso è anche quello che lo stateless mette più in discussione: il gate sulle azioni irreversibili.

Funziona così. I tool di scrittura non eseguono al primo colpo. Restituiscono un piano in chiaro, del tipo “sto per portare la quantità di SKU X da 12 a 0”, e aspettano una conferma. È anche, guardandola adesso, una macchina a stati travestita da tool: c’è un primo momento in cui il server ricorda cosa ha proposto, e un secondo in cui verifica che la conferma corrisponda a quella proposta.

Quel “ricorda” è esattamente ciò che il nuovo modello non mi regala più. Se ogni richiesta è isolata, la continuità me la devo costruire io, e devo costruirla bene, perché il fallimento non è un errore 500: è una conferma che si applica a un piano diverso da quello che l’utente aveva visto. Temo di aver progettato quel pezzo dando per scontata una proprietà del trasporto invece di renderla esplicita nel dominio.

Cosa penso mi aspetti, elencato onestamente

Quando ci metterò mano, questi sono i punti su cui mi aspetto di spendere il tempo. Sono deduzioni dal mio design, non misure.

La conferma in due tempi. Dovrà diventare un token di piano firmato e a scadenza, che il server emette insieme alla proposta e riverifica quando arriva la conferma: il piano viaggia con la richiesta invece di stare nella memoria del processo. Concettualmente è più pulito di adesso, e questo è il fastidio: la specifica mi sta costringendo a fare la cosa che avrei dovuto fare comunque.

Le sequenze di chiamate correlate. Ci sono flussi in cui una chiamata prepara il terreno alla successiva: recuperi lo stato di un prodotto, poi ne verifichi la visibilità sui website, poi tocchi le categorie. Senza sessione, ogni chiamata deve bastare a sé stessa o portarsi dietro un contesto esplicito. Sospetto che alcuni dei miei tool siano di fatto passi di un flusso e non intenzioni complete, e che la resa dei conti sia lì.

L’autenticazione. Oggi uso un integration token di Adobe Commerce, con un utente dedicato e permessi ritagliati per risorsa, tenuto in variabili d’ambiente o in un secret manager. Funziona, ed è molto meglio dell’accesso pieno “per comodità” a cui avevo ceduto all’inizio in sviluppo, prima di tornare indietro. Ma resta un segreto statico e condiviso: chiunque parli con il server agisce come quell’unica utenza. Con OAuth e OIDC di mezzo, l’identità di chi ha chiesto può arrivare fino al backend, e la mia scusa per non farlo si assottiglia.

L’ambiente di esecuzione. Un server che può girare serverless è un server che può partire a freddo, morire dopo la risposta, essere replicato. Tutto quello che avevo dato per scontato perché “tanto è lo stesso processo” va riesaminato: cache locali, connessioni riusate, contatori. Immagino ce ne sia più di quanto mi faccia piacere.

Il contro-argomento che mi faccio da solo

La replica ovvia è: stai solo spostando lo stato altrove. Se il piano di conferma diventa un token firmato, lo stato è nel token; se serve un idempotency key, lo stato è nello store che lo ricorda. Il protocollo si dichiara stateless e la complessità scivola nell’applicazione.

È vero solo a metà, e la metà che manca è quella che conta. Lo stato non sparisce, ma smette di essere implicito. Prima viveva nel fatto che una connessione era rimasta aperta, e nessuno lo dichiarava o lo metteva in sicurezza: era un effetto collaterale del trasporto. Adesso, se lo voglio, devo nominarlo, dargli una scadenza, decidere chi può leggerlo e come si invalida. È lo stesso passaggio che il web ha fatto anni fa muovendosi dalle sessioni server-side ai token: non meno stato, ma stato che compare nel design invece di nascondersi nell’infrastruttura.

C’è un secondo contro-argomento, più concreto: lo stateless costa più chiamate e più payload, perché il contesto va rispedito. Qui sono meno tranquillo. La mia posizione da sempre è che la qualità di un MCP server si misura da quanto poco context spreca, e per questo normalizzo e ripulisco tutti gli output prima di darli all’agente. Il rischio è che il contesto che tolgo dalle risposte rientri dalla finestra sotto forma di parametri di richiesta. Non ho misure, solo il sospetto.

Cosa cambia per chi sta valutando adesso

Se stai decidendo oggi se costruirti un MCP server o adottarne uno esistente, considera l’aderenza al modello stateless un criterio di selezione, non un dettaglio implementativo. È la differenza tra qualcosa che resterà un esperimento e qualcosa che potrà finire in produzione con l’approvazione di chi la produzione la deve gestire.

Ne ho confrontati due sullo stesso terreno e la domanda giusta non è mai quale abbia più tool, ma quali assunzioni faccia su come verrà ospitato. Vale anche per i contratti dati che stanno emergendo intorno al commerce: prima si sperimenta, poi si versiona.

La domanda che mi porto dietro è un’altra, e non ho ancora una risposta: quanto della sicurezza che sentivo nei miei gate veniva da un vero controllo del dominio, e quanto veniva dal fatto che tanto stavo girando in un ambiente che controllavo io? Lo scoprirò quando ci metterò mano. Sospetto che la risposta non mi farà fare bella figura.

Mini-FAQ

Cosa cambia concretamente con la specifica MCP 2026-07-28?
Il protocollo passa da un modello bidirezionale stateful a request/response stateless, con autorizzazione OAuth e OIDC più solida, estensioni versionate per Apps e Tasks, e supporto ai tunnel di rete privati per gli scenari enterprise.

Perché lo stateless è un vantaggio se sembra togliere funzionalità?
Perché rende ospitabile un MCP server dove l’IT aziendale sa già lavorare: serverless, edge, dietro load balancer e WAF, con autenticazione standard. È il passaggio da strumento locale a componente di infrastruttura.

I server MCP esistenti vanno riscritti?
Non necessariamente riscritti, ma vanno riesaminati nei punti in cui si appoggiano alla continuità di sessione: conferme in due tempi, sequenze di chiamate correlate, cache locali, autenticazione basata su token statici. Quanto costi dipende da quante di queste assunzioni sono implicite nel codice.

Lo stateless significa che non c’è più stato?
No. Significa che lo stato non è più implicito nel trasporto. Se serve, va reso esplicito nell’applicazione: token firmati con scadenza, idempotency key, contesto passato nella richiesta. Più lavoro, ma stato dichiarato e verificabile invece che presunto.

Chi sono. Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco integrazioni AI agentiche basate su MCP per il mondo Adobe, e scrivo di quello che imparo mentre le realizzo.