Anthropic, Simon Willison e il ribaltamento dell'MCP stateless

Anthropic ha introdotto MCP nel 2024, ma Simon Willison ha successivamente ritenuto gli strumenti da terminale più flessibili. La specifica del 28 luglio 2026 ha ora ribaltato in parte quel giudizio. Elimina le sessioni di protocollo e trasforma le chiamate MCP remote in richieste autonome.

Questo cambiamento ha riacceso l'interesse di Willison e ispirato due progetti, mcp-explorer e datasette-mcp. Ancora più importante, affronta la debolezza architetturale che rendeva i server MCP remoti più difficili da distribuire rispetto ai normali servizi HTTP.

La vicenda Anthropic-Simon Willison non è quindi un semplice aggiornamento del protocollo. È una verifica per capire se MCP possa smettere di competere con gli strumenti da riga di comando e trovare un ruolo più sostenibile. Le Skills restano interessanti per insegnare agli agenti a usare software esistente, mentre l'MCP stateless offre strumenti remoti strutturati, discovery, autorizzazione e infrastruttura condivisa.

L'MCP stateless elimina la sessione da ogni percorso di richiesta

La nuova specifica trasforma MCP da un protocollo incentrato sulla connessione a uno incentrato sulla richiesta.

Il Model Context Protocol definisce un'interfaccia standard attraverso cui gli agenti AI possono scoprire e richiamare strumenti esterni. Anthropic lo ha introdotto nel novembre 2024 e gli sviluppatori hanno rapidamente creato server per database, browser, piattaforme di comunicazione e applicazioni aziendali.

Le versioni precedenti imponevano un processo di inizializzazione prima delle normali chiamate agli strumenti. Client e server si scambiavano versioni del protocollo, capacità e informazioni identificative. Questa negoziazione stabiliva un contesto che i messaggi successivi dovevano preservare.

I server HTTP potevano inoltre emettere un Mcp-Session-Id. I client restituivano poi tale identificativo nelle richieste successive. Questo meccanismo faceva sì che una sequenza di chiamate si comportasse come una conversazione continua tra uno specifico client e una specifica istanza del server.

Quel design generava conseguenze infrastrutturali. Un load balancer doveva indirizzare le chiamate correlate verso l'istanza corretta oppure collocare i dati di sessione in uno storage condiviso. Gli operatori dovevano inoltre definire policy per scadenza, riconnessione, ripristino e pulizia.

La revisione finale 2026-07-28 elimina l'handshake initialize obbligatorio. Elimina anche la sessione a livello di protocollo e il relativo header. Ogni richiesta ora include le informazioni necessarie per interpretarla in modo indipendente.

Il rilascio MCP ufficiale descrive la revisione come il più grande cambiamento dal lancio del protocollo. Al suo nucleo stateless si aggiungono estensioni, supporto Tasks rivisto, modifiche all'autorizzazione e un ciclo di vita formale delle funzionalità.

Un client può ora inviare direttamente una chiamata a uno strumento. La richiesta include versione del protocollo, metodo, nome dello strumento, informazioni sul client e capacità rilevanti. Qualsiasi istanza server compatibile può elaborarla senza dipendere da uno scambio precedente.

Il cambiamento aggiunge anche server/discover, che consente ai client di richiedere le capacità del server quando necessario. La discovery non obbliga più ogni chiamante a creare e mantenere una sessione di protocollo.

Questo non significa che ogni applicazione debba abbandonare lo stato. Un servizio di automazione del browser, un carrello degli acquisti, una transazione di database o un flusso di ricerca possono comunque conservare informazioni tra chiamate diverse.

La differenza sta nel punto in cui tali informazioni risiedono e nel modo in cui vengono indirizzate. Anziché nasconderle dietro una sessione, il server può restituire un identificativo esplicito. Il modello fornisce poi quell'identificativo nelle chiamate successive.

Un server browser potrebbe restituire un browser_id dopo aver avviato un'istanza. Gli strumenti successivi possono accettare quel valore durante la navigazione, l'acquisizione di una pagina o la chiusura del browser. Uno strumento di database può applicare lo stesso schema a un identificativo di transazione.

La proposta sessionless accettata descrive questi valori come handle di stato espliciti. Non sono un nuovo tipo di dati MCP. Sono normali input e output degli strumenti che rendono visibile lo stato dell'applicazione.

Questa visibilità è importante per gli agenti. Un orchestratore può condividere un handle con un subagente mantenendone isolato un altro. Può inoltre registrare l'identificativo per attività future o passarlo a un altro processo autorizzato.

Le operazioni di elenco ottengono un vantaggio distinto. Quando strumenti e risorse non possono più cambiare in base a una sessione ambigua, i client possono memorizzare nella cache i risultati della discovery in modo più sicuro. Ciò riduce le chiamate ripetute tra agenti di breve durata.

L'MCP stateless si adatta inoltre più naturalmente alle comuni operazioni HTTP. I server remoti possono utilizzare il bilanciamento round-robin standard, il routing ordinario dei gateway, l'autenticazione per richiesta e sistemi consolidati di osservabilità.

È questa combinazione ad aver rinnovato l'attenzione di Willison. L'aggiornamento non si limita ad accorciare l'handshake. Elimina un vincolo architetturale che in precedenza si rifletteva in ogni deployment e in ogni implementazione client.

Perché conta il ribaltamento Anthropic-Simon Willison

Il rinnovato interesse di Willison è rilevante perché la sua precedente critica coglieva un reale allontanamento da MCP tra gli utenti degli agenti di coding.

MCP ha attirato grande attenzione per buona parte del 2025. La sua proposta di valore era facile da comprendere: implementare un'unica interfaccia server e poi esporre gli stessi strumenti a diversi client AI compatibili.

Nel frattempo, però, gli agenti di coding miglioravano. Hanno acquisito accesso affidabile al terminale, un uso più efficace della shell e maggiori capacità di esaminare la documentazione. Molti potevano installare una libreria o chiamare un'API convenzionale con curl.

Questo ha creato una sfida diretta. Un programma da riga di comando ben documentato offre già un'interfaccia di strumenti componibile. L'agente può combinare comandi, reindirizzare l'output, scrivere piccoli script e ispezionare gli errori senza un adattatore di protocollo.

Le Skills hanno rafforzato questa strada. Una skill è un pacchetto di istruzioni, script e riferimenti che insegna a un agente come svolgere un compito. Può spiegare un'API esistente senza richiedere al suo proprietario di gestire un server MCP.

Willison ha riassunto il suo scetticismo nella sua analisi del 2025. Per gli agenti di coding, preferiva utility da riga di comando e librerie rispetto a MCP. Queste opzioni offrivano al modello maggiore libertà evitando al contempo un ulteriore livello di servizio.

La critica non sosteneva mai che le chiamate strutturate agli strumenti fossero prive di valore. La questione più difficile riguardava se MCP offrisse sufficiente valore aggiuntivo da giustificare sessioni, gestione del trasporto, lavoro sulla compatibilità client e overhead di contesto.

L'MCP stateless riduce questa distanza. Un piccolo strumento remoto può ora comportarsi più come un endpoint web convenzionale, preservando al contempo un contratto leggibile dalle macchine per i client degli agenti.

L'analisi di Willison sull'MCP stateless collega questo cambiamento a due esperimenti. Il primo è mcp-explorer, pensato per rendere i server MCP più facili da ispezionare e comprendere. Il secondo è datasette-mcp, che applica il nuovo approccio a Datasette.

Datasette è il sistema open source di Willison per esplorare e pubblicare dati strutturati. Espone già i database tramite interfacce web e API. MCP offre un'altra superficie progettata specificamente per modelli linguistici che usano strumenti.

L'abbinamento è istruttivo. Un deployment Datasette è per natura remoto, strutturato e condiviso tra utenti. Non si adatta al modello locale da riga di comando con la stessa naturalezza di un'utility per sviluppatori installata accanto a un agente.

Un server MCP può pubblicizzare gli strumenti di database tramite schemi che i client comprendono. Gli agenti possono ispezionare le operazioni disponibili prima di inviare query. Gli operatori del server mantengono il controllo su autenticazione, permessi, limiti e dettagli di implementazione.

Questo rende il confronto Anthropic-Simon più sfumato di MCP contro Skills. Una skill può insegnare a un agente come interrogare un'API. MCP può offrire a molti client un contratto condiviso per scoprire e invocare quell'API.

I due approcci possono anche lavorare insieme. Una skill può descrivere quando usare un server MCP, spiegare i suoi concetti di dominio o fornire un flusso di lavoro che attraversa più strumenti. MCP può gestire il confine dell'esecuzione remota.

Questa divisione riduce la pressione su MCP affinché diventi la risposta universale a ogni azione dell'agente. I comandi locali possono restare locali. Le librerie possono servire compiti di coding flessibili. Le Skills possono confezionare conoscenza operativa.

MCP acquisisce un ruolo più chiaro quando il server controlla l'esecuzione e più client necessitano della stessa interfaccia individuabile. Dati aziendali, ricerca ospitata, servizi condivisi e sistemi aziendali autenticati rientrano in questo schema.

La semplicità del protocollo modifica quindi la questione competitiva. Gli sviluppatori non devono più chiedersi se ogni strumento meriti un wrapper MCP. Possono chiedersi se una capacità remota tragga vantaggio da discovery e invocazione standardizzate.

È una promessa più limitata delle interpretazioni iniziali più ambiziose di MCP. È anche più credibile. Gli standard spesso diventano utili dopo che i loro confini si sono chiariti.

Le richieste stateless fanno sì che MCP si adatti alla normale infrastruttura cloud

MCP 2.0 è importante perché elimina il coordinamento specializzato dal percorso di deployment più comune.

La proposta stateless accettata identifica tre problemi del vecchio modello di inizializzazione. Le sessioni complicavano la scalabilità, indebolivano il ripristino dagli errori e aumentavano il lavoro di implementazione su entrambi i lati.

Si consideri uno strumento di ricerca remoto eseguito su tre istanze server. Con un design orientato alla sessione, le chiamate successive potrebbero richiedere la stessa istanza che ha elaborato l'inizializzazione. Un semplice load balancer round-robin non può garantire questo risultato.

Gli operatori possono risolvere il problema con il routing sticky. Possono anche memorizzare i dati di sessione in un servizio condiviso. Entrambi gli approcci introducono stato operativo, ulteriori modalità di errore e nuovi requisiti di monitoraggio.

Le sessioni sticky possono distribuire il lavoro in modo diseguale. Gli archivi condivisi creano un'altra dipendenza. I riavvii del server possono invalidare lo stato locale, mentre i client devono rilevare gli errori e ripetere l'inizializzazione.

Con il nuovo modello di richiesta, qualsiasi istanza integra può elaborare una chiamata a uno strumento compatibile. Il gateway può instradare in base al metodo e ai metadati dello strumento anziché alla cronologia della connessione.

Questo cambiamento rende inoltre più plausibile il deployment serverless. Le piattaforme che avviano e arrestano istanze in base alla domanda funzionano meglio quando le richieste non dipendono dalla memoria lasciata da una richiesta precedente.

Il server necessita comunque di storage durevole per lo stato dell'applicazione realmente persistente. L'MCP stateless non elimina database, object store, worker browser o code di job. Elimina l'assunto che lo stato del protocollo debba accompagnarli.

Le operazioni di lunga durata rientrano ora in un modello basato su estensioni. Un server può restituire un handle di task, mentre il client può in seguito controllare, aggiornare o annullare quel task tramite operazioni esplicite.

La distinzione è importante. Lo stato nascosto della sessione accoppia un flusso di lavoro a una relazione di trasporto. Un handle di task trasforma il flusso di lavoro in una risorsa indirizzabile che altri componenti autorizzati possono gestire.

Le Multi Round-Trip Requests affrontano un altro caso difficile. Alcuni strumenti necessitano di maggiori informazioni da un utente o da un client prima di completare l'operazione. Le implementazioni precedenti associavano questo scambio a una sessione stabilita.

Il nuovo design consente una richiesta avviata dal server soltanto mentre sta elaborando una richiesta del client. I dati di correlazione viaggiano nel ciclo di richiesta e risposta, evitando una sessione di protocollo permanente.

Questo limita alcuni comportamenti. Un server non può contattare inaspettatamente un client molto tempo dopo la chiamata iniziale. Questo limite riduce la flessibilità, ma assegna ai prompt dell'utente un'origine e un ciclo di vita più chiari.

Anche la scoperta degli strumenti diventa più facile da instradare e memorizzare nella cache. La specifica aggiunge metadati su metodi e strumenti agli header HTTP. I gateway possono ispezionare tali metadati senza analizzare ogni corpo della richiesta.

I server possono associare un valore di time-to-live alle risposte delle liste. I client possono quindi riutilizzare le informazioni sugli strumenti entro il periodo consentito, invece di richiedere lo stesso elenco per ogni subagente di breve durata.

La proposta sessionless avverte che il comportamento precedente poteva generare traffico di scoperta ripetuto, proporzionale al numero di subagenti moltiplicato per il numero di server. Le liste stateless offrono agli orchestratori una base migliore per evitare questo costo.

Questo aspetto conta sempre di più man mano che i sistemi di agenti diventano più distribuiti. Una singola richiesta utente può attivare un pianificatore, diversi worker specializzati e un verificatore. Ripetere inizializzazione e scoperta per ogni ramo aggiunge latenza e traffico.

Il protocollo rivisto adotta inoltre il supporto completo a JSON Schema 2020-12 per le definizioni degli strumenti. JSON Schema è un vocabolario standard per descrivere dati strutturati, inclusi campi obbligatori, tipi e regole di validazione.

Schemi più ricchi possono descrivere input e output con maggiore precisione. Questo offre ai client informazioni migliori per validare le chiamate e costruire interfacce. Riduce inoltre la dipendenza da descrizioni degli strumenti formulate in modo approssimativo.

Le estensioni offrono un'altra forma di separazione architetturale. MCP Apps può fornire interfacce renderizzate dal server, mentre Tasks gestisce operazioni più lunghe. Queste funzionalità possono evolversi senza imporre ogni capacità nel nucleo del protocollo.

Un ciclo di vita formale introduce almeno 12 mesi tra la deprecazione di una funzionalità e la sua possibile rimozione più anticipata. Questo non elimina il lavoro di migrazione, ma offre agli implementatori una finestra di pianificazione più chiara dopo questa netta discontinuità.

La guida ufficiale TypeScript mostra che la migrazione richiede comunque un lavoro intenzionale. La guida alla migrazione dell'SDK afferma che il nuovo formato wire richiede un'adozione esplicita, anziché modificare silenziosamente ogni applicazione esistente.

Questa cautela è appropriata. Una nuova specifica non può creare interoperabilità con la sola pubblicazione. Client, server, gateway e SDK devono implementare gli stessi dettagli e testarli su carichi di lavoro reali.

Ciononostante, il meccanismo affronta una debolezza concreta. Sostituisce la gestione delle sessioni specifica di MCP con schemi che i team cloud usano già per normali servizi HTTP.

Lo stato esplicito introduce nuove questioni di sicurezza e affidabilità

MCP stateless elimina attriti infrastrutturali, ma trasferisce più responsabilità alla progettazione degli strumenti, all'autorizzazione e alla memoria dell'agente.

Gli handle espliciti rendono lo stato visibile e portabile. Questi vantaggi ampliano anche i punti in cui possono comparire identificatori sensibili. Un handle può finire nelle cronologie delle chat, nei prompt, nei log, nelle tracce, nel contenuto degli appunti o nei messaggi dei subagenti.

Un server non deve considerare la conoscenza di un identificatore un'autorizzazione sufficiente. Dovrebbe convalidare sia l'handle sia l'identità autenticata a ogni chiamata.

Questo richiama il modello adottato da molti servizi per documenti e progetti. Un ID di risorsa identifica un oggetto, mentre il contesto di autorizzazione corrente determina se un chiamante può leggerlo o modificarlo.

I servizi non autenticati affrontano un problema più difficile. In tale contesto, un handle imprevedibile può funzionare come un bearer token. Chiunque lo ottenga può accedere allo stato sottostante finché l'handle non scade.

La specifica sessionless raccomanda identificatori ad alta entropia e durate limitate per questi casi. Questa raccomandazione resta una linea guida di implementazione, perché MCP non definisce un tipo di handle a livello wire.

Ciò crea una lacuna nell'applicazione delle regole. I client non possono riconoscere automaticamente quali stringhe restituite rappresentino stato attivo. Un browser_id appare come qualsiasi altro valore, salvo che nomi e descrizioni degli strumenti ne comunichino il ruolo.

Di conseguenza, un orchestratore non può sempre sapere quali identificatori debbano sopravvivere alla compressione del contesto. Può inoltre faticare a determinare quali valori richiedano pulizia o non debbano mai essere passati a un altro subagente.

I modelli gestiscono abitualmente percorsi di file, hash di commit, URL e identificatori di transazione. Possono comunque copiare un handle in modo errato, ometterlo o perderlo quando una conversazione lunga viene riassunta.

Lo stato di sessione presentava debolezze analoghe. I client usavano durate incoerenti e molti non ripristinavano le sessioni dopo le disconnessioni. Eliminare le sessioni rende questi problemi espliciti, ma non automatizza la gestione dello stato.

La pulizia presenta un altro dettaglio irrisolto. La fine di una sessione offriva un tempo un segnale teorico per rilasciare risorse. Nella pratica, i client spesso terminavano le sessioni troppo frequentemente, troppo raramente o dopo il ricaricamento di una pagina non correlato.

I flussi di lavoro espliciti necessitano di proprie politiche di scadenza e distruzione. Un servizio browser potrebbe offrire close_browser, applicando al contempo un timeout per inattività. Un servizio di task potrebbe conservare i risultati completati per un periodo definito.

La compatibilità con le versioni precedenti aggiunge complessità operativa durante l'adozione. I server esistenti che dipendono da ID di sessione non possono semplicemente accettare la nuova revisione del protocollo senza modificare il proprio modello di stato.

Quando necessario, client e SDK possono negoziare una revisione precedente. Questo consente una migrazione graduale, ma crea anche due percorsi di comportamento che gli sviluppatori devono testare.

Alcune capacità diventano meno immediate con HTTP stateless. Le notifiche non richieste e le interazioni server-driven di lunga durata non si adattano alle richieste indipendenti con la stessa naturalezza. Estensioni e meccanismi di ascolto devono farsi carico di questo lavoro.

Non vi è inoltre alcuna garanzia che ogni integrazione MCP diventi efficiente solo perché le sessioni scompaiono. Schemi progettati male possono consumare contesto. Cataloghi di strumenti estesi possono confondere i modelli. Descrizioni poco chiare possono ancora attivare chiamate errate.

Skills e strumenti da riga di comando conservano qui i propri vantaggi. Un agente di coding può spesso esaminare l'output di help di un programma e scrivere un breve script senza caricare un grande catalogo di strumenti remoti.

Gli strumenti locali possono inoltre mantenere i dati sensibili sulla macchina dell'utente. Un deployment MCP remoto introduce problematiche di autenticazione, esposizione di rete, logging e disponibilità del servizio che l'esecuzione locale evita.

MCP non risolve neppure il prompt injection. Un agente abilitato agli strumenti può combinare informazioni private, input non attendibili e comunicazioni esterne, indipendentemente dal fatto che il trasporto sia stateful.

Gli operatori dei server devono limitare permessi e output. I costruttori di agenti devono controllare quali strumenti compaiano insieme. Gli utenti hanno bisogno di confini di approvazione chiari per le azioni con conseguenze rilevanti.

Questi vincoli mettono in discussione l'interpretazione più forte della svolta di Anthropic Simon. Il rinnovato interesse di Willison convalida il cambiamento architetturale, non ogni implementazione MCP o ogni server proposto.

mcp-explorer e datasette-mcp sono utili esperimenti iniziali perché espongono questioni pratiche. I client possono scoprire gli strumenti in modo coerente? Gli schemi sono comprensibili? Autenticazione e handle di stato resistono nei flussi di lavoro reali?

L'argomento più solido a favore di MCP stateless deriverà dalle prove di interoperabilità. Client indipendenti dovrebbero collegarsi a server indipendenti senza patch personalizzate, mentre gli operatori dovrebbero poterli distribuire usando infrastrutture ordinarie.

Finché queste prove non aumenteranno, MCP 2.0 resterà una base migliore piuttosto che una vittoria compiuta. Il protocollo ha rimosso una fonte importante di attrito. Gli implementatori determinano ancora se i sistemi risultanti rimarranno sicuri e comprensibili.

Cosa dovrebbero osservare gli sviluppatori dopo MCP 2.0

Il prossimo banco di prova è l'adozione negli SDK, nei server reali e nei client, non un'altra impennata nel numero di repository.

Il primo segnale è la copertura implementativa della revisione 2026-07-28. Gli SDK ufficiali devono offrire supporto coerente per scoperta, metadati per richiesta, capacità esplicite, Tasks e comportamento di autorizzazione.

Le sole etichette di versione non basteranno. Gli sviluppatori dovrebbero osservare i risultati di conformità e i test cross-language. Un server Python, un client TypeScript e un gateway gestito dovrebbero concordare sulle stesse richieste e sugli stessi errori.

Una forte compatibilità tra SDK rafforzerebbe l'idea che MCP offra ora un confine stabile per gli strumenti remoti. Disallineamenti persistenti la indebolirebbero, riportando gli sviluppatori ad adattatori specifici per client.

Il secondo segnale è il modo in cui i server di produzione migrano i flussi di lavoro stateful. Automazione dei browser, transazioni, carrelli della spesa e lavori di ricerca a lunga esecuzione offrono test impegnativi per gli handle espliciti.

Le migrazioni riuscite dovrebbero mostrare pulizia affidabile, autorizzazione per richiesta, passaggio degli handle e compressione del contesto. Dovrebbero anche documentare cosa accade quando un agente perde o ripete un identificatore.

Se questi schemi diventeranno riutilizzabili, lo stato esplicito apparirà come un'astrazione migliore delle sessioni ambigue. Se ogni server inventerà regole di ciclo di vita incompatibili, il protocollo avrà spostato la complessità anziché ridurla.

Il terzo segnale è il rapporto tra MCP e Skills. Le piattaforme per agenti dovrebbero dimostrare quando scelgono un comando locale, una chiamata API guidata da skill o un server MCP remoto.

Regole di selezione chiare rafforzerebbero la tesi più circoscritta. MCP servirebbe capacità remote condivise, mentre Skills impacchetterebbe istruzioni e flussi di lavoro locali.

Una sovrapposizione continua potrebbe creare manutenzione duplicata. I proprietari degli strumenti potrebbero aver bisogno, per la stessa capacità, di un'API, una CLI, un pacchetto skill, un server MCP e un'integrazione specifica per client.

Gli sviluppatori dovrebbero resistere alla tentazione di considerare inevitabile questa duplicazione. Una skill può fare riferimento a un server MCP e un server MCP può incapsulare un'API esistente. La domanda utile è quale interfaccia possieda il contratto durevole.

Per gli strumenti dati, gli esperimenti di Willison offrono un punto concreto da osservare. Datasette già fornisce informazioni strutturate tramite API web. datasette-mcp può verificare se un contratto incentrato sugli agenti migliori la scoperta e le query sicure.

I team che costruiscono flussi di lavoro basati sulla conoscenza affrontano una scelta analoga. Documenti e note locali spesso trovano posto in una knowledge base ingegneristica ricercabile e privata. I sistemi aziendali condivisi possono adattarsi meglio a strumenti remoti autenticati.

Il punto chiave è evitare di concedere a un singolo agente una raccolta illimitata di strumenti solo perché un protocollo comune rende semplice la connessione. La standardizzazione riduce il lavoro di integrazione, ma non sostituisce la progettazione dei permessi.

La svolta di Anthropic Simon Willison è preziosa perché segue un periodo di autentico scetticismo. MCP non ha recuperato attenzione grazie al branding. I suoi manutentori hanno rimosso un onere strutturale che i critici potevano indicare nei sistemi distribuiti.

È così che un protocollo dovrebbe evolvere. Dovrebbe assorbire le evidenze provenienti da assunzioni fallite, restringere le proprie responsabilità e rendere le operazioni comuni più facili da valutare.

Nei prossimi tre mesi, esaminate i client e i server che usate davvero. Verificate se supportano la revisione finale, come rappresentano lo stato dell'applicazione e se la loro autorizzazione segue ogni handle.

Poi confrontate il risultato con l'alternativa più semplice. Se un comando locale resta più chiaro, mantenetelo. Se molti agenti necessitano di una capacità remota governata, testate MCP stateless e annotate i punti in cui l'interoperabilità continua a fallire.