Il Model Context Protocol ha raggiunto un importante traguardo infrastrutturale: la sua revisione del 28-07-2026 sposta il protocollo verso un nucleo stateless. Per i team che creano sistemi di agenti, server di strumenti, integrazioni IDE o livelli di orchestrazione multi-modello, questo non è un aggiornamento cosmetico delle specifiche. Cambia i presupposti su sessioni, inizializzazione, scalabilità, compatibilità e governance.
La release candidate di MCP ha descritto la specifica del 28 luglio come l'aggiunta di un core del protocollo stateless, un framework di estensioni, attività, app MCP, rafforzamento delle autorizzazioni e una politica di deprecazione formale. Il blog ufficiale di MCP ha inoltre avvertito che il rilascio contiene modifiche sostanziali. GitHub, che gestisce una delle implementazioni del server MCP più visibili, ha dichiarato prima del rilascio finale che il suo server MCP supportava già la nuova specifica e ha descritto il protocollo come "diventato senza stato" il 28 luglio.
Il significato pratico è semplice: MCP è stato modellato meno come un livello di integrazione locale con sessioni pesanti e più come un protocollo su scala Internet per l'accesso a strumenti remoti. Ciò è importante perché i sistemi di agenti non sono più limitati agli strumenti di sviluppo desktop. Vengono sempre più eseguiti all'interno di servizi cloud, sistemi CI, flussi di lavoro dell'assistenza clienti, tracker dei problemi e piattaforme di automazione aziendale.
Cosa è cambiato in MCP
Il cambiamento principale è il passaggio a un core del protocollo stateless. Il registro delle modifiche di GitHub afferma che il nuovo core rimuove le sessioni e inizializza, con l'obiettivo di rendere più semplice la scalabilità delle distribuzioni MCP remote. Questo è un cambiamento architettonico significativo. I protocolli stateful possono funzionare bene per strumenti locali e ambienti controllati, ma complicano la scalabilità orizzontale, l'esecuzione serverless, il failover, l'implementazione edge e il bilanciamento del carico.
Un core stateless offre agli implementatori maggiore libertà di eseguire server MCP dietro la normale infrastruttura web. Le richieste possono essere distribuite tra istanze senza preservare una sessione di lunga durata su un backend specifico. Per le grandi organizzazioni, ciò può ridurre la complessità operativa. Per i team più piccoli, potrebbe rendere più semplice l'implementazione dei server MCP ospitati utilizzando l'elaborazione gestita anziché un'infrastruttura personalizzata a lungo termine.
La versione più ampia del 28-07-2026 introduce anche un framework di estensioni e attività, secondo i materiali del candidato al rilascio. Queste aggiunte suggeriscono che MCP sta diventando più modulare e più esplicito riguardo al lavoro a lungo termine. Le app MCP e il rafforzamento delle autorizzazioni puntano nella stessa direzione: il protocollo sta maturando da collante dell'ecosistema iniziale a un livello più formale per l'interazione tra agente e strumento.
Il costo di tale maturazione è il lavoro di compatibilità. Il blog MCP ha caratterizzato il rilascio come un rilascio contenente modifiche sostanziali e i materiali TypeScript e C# SDK pubblicati attorno alla revisione si concentrano sul supporto della migrazione e sui concetti di stateless. Qualsiasi team che utilizza un server MCP, incorpora MCP in un'estensione IDE o instrada chiamate di agenti attraverso l'infrastruttura interna dovrebbe considerare la revisione come un evento tecnico piuttosto che un aggiornamento degli standard in background.
Perché MCP stateless è importante per sviluppatori e operatori
Gli strumenti degli agenti presentano un problema di ridimensionamento che sembra diverso dal normale ridimensionamento delle API. Una singola richiesta utente può attivare numerose chiamate a strumenti, trasformazioni di modelli, nuovi tentativi, letture di file, query di ricerca e passaggi di approvazione. Quando il protocollo dello strumento presuppone sessioni durevoli, gli operatori di produzione devono preservare lo stato durante tali interazioni o creare soluzioni alternative attorno al protocollo.
Rimuovendo le sessioni dal core, MCP si adatta meglio agli ambienti in cui i carichi di lavoro degli agenti sono rapidi, distribuiti e asincroni. Le funzioni serverless, i lavoratori periferici, le distribuzioni Kubernetes e i sistemi multi-regione traggono tutti vantaggio quando le richieste possono essere gestite in modo indipendente. Ciò non elimina lo stato dalle applicazioni dell'agente; sposta lo stato nei database delle applicazioni, nelle code di attività, nei sistemi di identità o nei livelli di flusso di lavoro espliciti anziché incorporarlo nel nucleo del protocollo.
Per gli sviluppatori, la modifica dovrebbe infine rendere più semplice l'utilizzo dei server degli strumenti remoti. Per i team della piattaforma, può semplificare l'osservabilità e la pianificazione della capacità. Invece di eseguire il debug del comportamento opaco dell'affinità di sessione, gli operatori possono concentrarsi sulle tracce a livello di richiesta, sulla latenza delle chiamate agli strumenti, sulle decisioni di autorizzazione e sui modelli di errore.
Esiste anche un aspetto di governance. Man mano che MCP diventa più comune negli assistenti di codifica e negli agenti aziendali, le aziende avranno bisogno di policy su quali strumenti gli agenti possono chiamare, a quali dati possono accedere e a quali utenti o servizi è consentito invocarli. Il rafforzamento delle autorizzazioni nella nuova revisione non è quindi casuale.Riflette la realtà che l'accesso agli strumenti è ora un limite di sicurezza, non solo una comodità per gli sviluppatori.
Chi è interessato
I gruppi più direttamente interessati sono i manutentori dei server MCP, gli utenti dell'SDK, i team della piattaforma agente e le organizzazioni che espongono strumenti interni agli agenti IA. Se un server dipende dal comportamento della sessione o dai flussi di inizializzazione precedenti, sarà necessario testarlo rispetto alla nuova specifica. Se un'applicazione supporta più versioni MCP, potrebbe richiedere la negoziazione della versione, livelli di compatibilità o un piano di migrazione graduale.
Sono inclusi anche i fornitori di IDE e strumenti di sviluppo. MCP appare sempre più insieme ad agenti di codifica, agenti personalizzati e funzionalità di gestione dei modelli. Un core del protocollo stateless rende più semplice per questi prodotti chiamare strumenti remoti in modo affidabile, ma solo se le loro integrazioni tengono il passo con le specifiche.
Le aziende che utilizzano l'automazione degli agenti dovrebbero prestare attenzione anche se non leggono mai le specifiche MCP. La modifica potrebbe influire sull'affidabilità degli agenti che si connettono a repository, sistemi di ticketing, database, knowledge base interne o strumenti di distribuzione. Durante le finestre di migrazione, le probabili modalità di errore non sono solo interruzioni evidenti. Potrebbero includere funzionalità dello strumento mancanti, comportamento di autenticazione modificato o agenti che seguono percorsi diversi perché un server dello strumento non si comporta più come previsto.
Per un gateway API AI come Model Gate, la connessione è pratica. Un'API AI unificata si colloca sempre più vicino al routing dei modelli, alla gestione delle chiavi API, all'analisi dell'utilizzo e alla governance delle API del team. Poiché i sistemi ad agenti aggiungono chiamate agli strumenti MCP accanto alle chiamate ai modelli ordinari, i livelli gateway e osservabilità dovranno tenere conto di entrambi i lati del flusso di lavoro: quale modello è stato utilizzato, quali strumenti sono stati invocati, quanto costano, chi li ha autorizzati e dove si sono verificati gli errori.
Priorità di migrazione e domande aperte
La prima priorità di migrazione è il test di compatibilità. I team devono eseguire l'inventario dei client e dei server MCP, identificare le dipendenze sulle sessioni o inizializzare il comportamento ed eseguire test rispetto agli SDK del 2026-07-28 o ai materiali di conformità, ove disponibili. I sistemi di produzione dovrebbero organizzare l'aggiornamento in fasi, soprattutto se gli agenti eseguono azioni con effetti collaterali come la creazione di richieste pull, la modifica di problemi, l'interrogazione dei dati dei clienti o l'esecuzione di flussi di lavoro di distribuzione.
La seconda priorità è l'osservabilità. L'infrastruttura stateless può essere più semplice da scalare, ma i sistemi ad agenti distribuiti necessitano comunque di ID di correlazione, acquisizione di tracce, registri di richieste ed eventi di policy. Senza questi, i team potrebbero scambiare la complessità della sessione con la complessità del debug. L'analisi dell'utilizzo dovrebbe distinguere tra chiamate modello e chiamate strumento, soprattutto quando i flussi di lavoro degli agenti sono fatturati, con tariffe limitate o controllati dal team.
La terza priorità è la revisione dell'autorizzazione. Se la nuova specifica rafforza la semantica dell'autorizzazione, gli implementatori non dovrebbero semplicemente trasferire i vecchi presupposti di accesso nella nuova versione. Dovrebbero ricontrollare gli ambiti dei token, la delega degli utenti, gli account di servizio, i log di controllo e il comportamento di rifiuto. Per impostazione predefinita, l'accesso agli strumenti dovrebbe avere i privilegi minimi, in particolare per le distribuzioni MCP remote.
Alcuni dettagli meritano di essere controllati prima che le organizzazioni prendano decisioni di progettazione irreversibili. La ricerca disponibile per questo articolo includeva la release candidate, la pagina delle specifiche, i materiali per la migrazione dell'SDK e la nota di implementazione di GitHub. La formulazione normativa finale della specifica del 28-07-2026 dovrebbe essere rivista direttamente prima di citare i requisiti esatti del protocollo negli standard interni o nella documentazione del cliente.
Anche con questo avvertimento, la direzione è chiara. MCP sta diventando un protocollo più orientato alla produzione per l'infrastruttura degli agenti. Il core senza stato dovrebbe rendere le implementazioni remote più facili da scalare, ma costringe anche l’ecosistema a ripulire i presupposti delle implementazioni precedenti. Per i team che creano team con agenti, questo è il tipo di modifica del protocollo che merita un biglietto sprint, non solo un segnalibro.