Analisi di MCP 2026-07-28: il protocollo diventa stateless per una maggiore scalabilità

Introduzione

Il Model Context Protocol ha subito la più grande revisione architetturale dalla sua nascita.

Quando MCP è stato introdotto inizialmente, era un modo universale per consentire alle applicazioni AI di connettere modelli con strumenti, API, origini dati, file e sistemi esterni. In meno di due anni, si è evoluto da un progetto di integrazione guidato da Anthropic a un protocollo open source più ampio, con il proprio processo di governance, ecosistema SDK, gruppi di lavoro, estensioni e implementazioni in numerosi prodotti AI.

La revisione 2026-07-28 si concentra sui problemi emersi quando MCP ha lasciato i laptop degli sviluppatori ed è entrato in ambienti di produzione su larga scala.

Il cambiamento principale può essere riassunto come:

MCP sta diventando stateless a livello di protocollo.

Questa modifica rimuove l'handshake di sessione e inizializzazione a livello di protocollo dal nuovo formato wire, consentendo ai server MCP remoti di essere distribuiti più facilmente dietro bilanciatori di carico ordinari, infrastruttura serverless, nodi edge computing e architetture di scalabilità orizzontale.

Ma il trasporto stateless è solo una parte di questo aggiornamento.

La revisione formalizza anche un framework di estensione, ridefinisce le attività a lunga esecuzione, introduce richieste multi-round trip, aggiunge header HTTP instradabili e suggerimenti di cache, rafforza i meccanismi di autorizzazione, espande il supporto JSON Schema e stabilisce una politica formale di deprecazione delle funzionalità.

Oltre al protocollo stesso, l'ecosistema MCP sta aggiungendo applicazioni interattive, autorizzazione gestita a livello enterprise, tunneling di rete privata e strumenti per sviluppatori più potenti.

È a questo punto che MCP inizia a non sembrare più un semplice connettore per agenti, ma infrastruttura di livello produttivo.

L'adozione di MCP sta crescendo rapidamente

Il rapporto sorgente evidenzia la velocità di crescita dell'utilizzo di MCP.

Secondo l'annuncio per sviluppatori di Claude citato nell'articolo sorgente:

• I download mensili degli SDK MCP hanno superato i 400 milioni.
• L'utilizzo mensile degli SDK è circa quadruplicato nell'arco dell'anno.
• Gli SDK TypeScript e Python hanno entrambi superato traguardi cumulativi molto significativi.
• Centinaia di integrazioni MCP sono disponibili attraverso l'ecosistema di connettori di Claude.

Questi dati specifici di fine luglio appartengono alle metriche dell'annuncio di rilascio, non ai numeri pubblicati nel nucleo della specifica.

Un annuncio ufficiale precedente di Anthropic fornisce un utile punto di riferimento: a gennaio 2026, Anthropic ha dichiarato che MCP aveva raggiunto 100 milioni di download mensili.

Ciò significa che l'ecosistema era già piuttosto vasto prima della riprogettazione del protocollo di luglio.

Pertanto, il significato di questo aggiornamento non è che MCP stia cercando di diventare utile in futuro, ma che i manutentori stanno riprogettando il protocollo attorno a problemi che si sono già manifestati a scala produttiva.

Questi problemi includono:

• Sessioni sticky.
• Archiviazione di sessione condivisa.
• Scalabilità orizzontale.
• Distribuzioni serverless.
• Routing tramite gateway.
• Complessità dell'autenticazione.
• Operazioni degli agenti a lunga esecuzione.
• Interfacce interattive.
• Compatibilità all'indietro.
• Evoluzione del protocollo.

Perché il design stateful precedente era un problema per la scalabilità

Le prime distribuzioni remote di MCP potevano mantenere stato di sessione a livello di protocollo.

Il client tipicamente inizializzava una connessione e otteneva un identificatore di sessione. Le richieste successive dovevano rimanere associate a quella sessione.

Un flusso semplificato di 2025-11-25 appariva come segue:

POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "my-app",
      "version": "1.0"
    }
  }
}

Dopo l'inizializzazione, le chiamate successive potevano includere:

Mcp-Session-Id: 1868a90c-3a3f-4f5b

Questo approccio funzionava per molte applicazioni, ma introduceva alcuni requisiti a livello di infrastruttura.

Le distribuzioni in produzione potevano richiedere:

• Routing con bilanciamento del carico sticky.
• Archiviazione di sessione condivisa.
• Replica delle sessioni.
• Logica di scadenza delle sessioni.
• Gestione del failover.
• Osservabilità sensibile alle connessioni.
• Gestione speciale dei riavvii del server.

I manutentori di MCP hanno concluso che questi requisiti erano troppo accoppiati al protocollo stesso.

La nuova revisione rimuove questa ipotesi.

MCP ora è stateless a livello di protocollo

Nel design del protocollo 2026-07-28, ogni richiesta trasporta le informazioni necessarie al server per elaborarla.

L'esempio ufficiale è il seguente:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "q": "otters"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

Non esiste più un Mcp-Session-Id a livello di protocollo.

Non esiste più una sessione di connessione obbligatoria che vincola le richieste a una singola istanza del server.

Qualsiasi istanza compatibile del server può elaborare la richiesta.

Questo è un miglioramento significativo per le distribuzioni cloud.

I server MCP remoti ora possono adattarsi alle architetture tradizionali:

Client
  ↓
API Gateway / Bilanciatore di carico
  ↓
Istanza server MCP A
Istanza server MCP B
Istanza server MCP C

Le richieste non devono più tornare a un'istanza specifica perché una richiesta precedente era stata gestita da essa.

Il nuovo formato wire rimuove l'handshake initialize

La riprogettazione stateless rimuove anche il vecchio ciclo di vita initialize / initialized dal formato wire 2026-07-28.

Le informazioni che venivano trasmesse una sola volta durante l'inizializzazione ora viaggiano con ogni richiesta tramite metadati.

Quando un client desidera scoprire in anticipo le capacità del server, può utilizzare il nuovo metodo server/discover.

Questo non significa che i vecchi client smetteranno immediatamente di funzionare.

La documentazione SDK attuale include note sul comportamento di compatibilità con le versioni precedenti del protocollo. Ad esempio, l'SDK C# può supportare il nuovo percorso stateless

2026-07-28:
Modello di richiesta senza stato, nessuna sessione a livello di protocollo.

Versioni precedenti:
L'handshake di inizializzazione e il comportamento basato su sessione potrebbero essere ancora supportati
tramite negoziazione di versione e percorsi di compatibilità SDK.

Gli sviluppatori dovrebbero testare entrambe le estremità dell'integrazione, invece di aggiornare solo il server e presupporre che tutti i client comprendano la nuova versione.

## Un protocollo senza stato non significa un'applicazione senza stato

Uno degli errori più facili da commettere è interpretare questa modifica come:

> Le applicazioni MCP non possono più mantenere stato.

Non è questo il significato della specifica.

**Il livello di protocollo** è senza stato.

Le applicazioni possono comunque mantenere stato dove è utile.

Supponiamo che uno strumento di shopping crei un carrello.

Il server può restituire:

```JSON
{
  "basket_id": "basket_8472"
}

Il modello può passare questo valore nelle chiamate successive:

{
  "basket_id": "basket_8472",
  "item_id": "item_123"
}

Ciò rende lo stato applicativo visibile come normale dato di strumento, invece di nasconderlo nei metadati di trasporto.

Lo stesso modello può essere usato per sessioni browser, attività di report, carrelli della spesa, ID di flussi di lavoro, ID di distribuzione, stato di modifica di documenti e attività di analisi a lunga esecuzione.

Perché gli handle espliciti possono essere migliori

Gli handle visibili offrono diversi vantaggi.

Il modello può:

• Passarli tra strumenti correlati.
• Ragionare su quale handle appartiene a quale attività.
• Includerli nei log.
• Ripristinarli dopo un nuovo tentativo.
• Consegnarli a un altro passaggio del flusso di lavoro.

Il server può:

• Validare l'handle.
• Farne scadere la validità.
• Associarlo a un utente o tenant.
• Rifiutare stato scaduto.
• Archiviare lo stato effettivo in un database.

Pertanto, MCP senza stato sposta la gestione dello stato dal livello di trasporto a una progettazione applicativa esplicita.

Serverless e scalabilità orizzontale diventano molto più semplici

L'articolo originale ha evidenziato le distribuzioni serverless, uno dei risultati più concreti del nuovo protocollo.

Quando le richieste sono autocontenute, i server MCP possono essere eseguiti più facilmente in ambienti come:

• AWS Lambda.
• Cloudflare Workers.
• Vercel.
• Altre funzioni serverless.
• Piattaforme di auto-scaling per container.
• Distribuzioni Kubernetes ordinarie senza stato.
• Ambienti edge.

Questo non significa che ogni carico di lavoro MCP possa essere eseguito automaticamente su ogni piattaforma serverless.

Gli sviluppatori devono comunque considerare durata di esecuzione, supporto dello streaming, avvii a freddo, stato applicativo persistente, segreti, rete in uscita, attività a lunga esecuzione, requisiti del file system e connessioni al database.

Il protocollo non impone più un'architettura di sessione, eliminandone così un ostacolo principale.

Il bilanciamento round-robin diventa la scelta predefinita naturale

I server scalati orizzontalmente non devono più vincolare un singolo client a una singola istanza a livello di protocollo.

Ciò significa che un semplice bilanciatore round-robin può distribuire le richieste tra più istanze.

Questo migliora:

• L'auto-scaling.
• La sostituzione delle istanze.
• Il ripristino dai guasti.
• Le distribuzioni progressive.
• Il routing multi-regione.
• La semplicità dell'infrastruttura.

Questo cambia anche il modo di pensare degli autori di server quando considerano lo stato in memoria nascosto.

Se uno strumento funziona solo perché una richiesta precedente ha popolato un dizionario in un processo, l'implementazione potrebbe fallire quando la richiesta successiva arriva a un'altra istanza.

Un buon test di migrazione è:

Se ogni chiamata a uno strumento cadesse su un processo server diverso, lo stesso flusso di lavoro funzionerebbe ancora?

Se la risposta è no, il server contiene una dipendenza dallo stato applicativo che deve diventare esplicita o essere migrata verso un archivio condiviso persistente.

Le richieste multi-round sostituiscono le connessioni persistenti durante la chiamata

Il design senza stato richiede comunque un modo per il server di chiedere ulteriori informazioni al client.

Gli esempi includono conferme dell'utente, parametri aggiuntivi, domande guidate, risposte generate dal modello o valori legati all'area di lavoro.

Il nuovo meccanismo è la richiesta multi-round (Multi Round-Trip Requests, MRTR).

Uno strumento può restituire un risultato incompleto:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Eliminare 3 file?",
      "schema": {
        "type": "boolean"
      }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

Il client raccoglie le risposte richieste.

Quindi ripete la chiamata originale usando inputResponses e il requestState restituito.

Poiché lo stato viene trasportato nel flusso della richiesta, un'altra istanza del server può gestire il round successivo.

Questo è molto più in linea con l'architettura senza stato rispetto a richiedere connessioni persistenti di lunga durata dal server al client.

Il routing basato su header rende MCP più adatto ai gateway

Il nuovo formato Streamable HTTP aggiunge direttamente i metadati dell'operazione negli header HTTP.

Gli header importanti includono:

Mcp-Method: tools/call
Mcp-Name: search

Questo è importante per l'infrastruttura di produzione.

I gateway API, i Web application firewall, i rate limiter o i livelli di osservabilità possono identificare l'operazione senza analizzare il corpo JSON.

Gli usi possibili includono:

• Instradare tutti gli strumenti di ricerca allo stesso pool.
• Applicare restrizioni più severe alle operazioni distruttive.
• Registrare la latenza per nome dello strumento.
• Misurare l'uso per metodo.
• Bloccare strumenti non consentiti a livello di gateway.
• Creare policy di affidabilità indipendenti.

La specifica del protocollo richiede anche coerenza tra gli header e il corpo JSON-RPC.

Il server deve rifiutare le richieste in cui i due non coincidono.

I risultati di elenco e lettura supportano la consapevolezza della cache

I client MCP richiedono spesso metadati relativamente stabili, come elenchi di strumenti, risorse, elenchi di prompt e letture di risorse.

Recuperare ripetutamente le stesse informazioni spreca traffico di rete e capacità del server.

La nuova revisione introduce metadati di cache, ad esempio:

ttlMs
cacheScope

Questi valori consentono al server di indicare per quanto tempo il risultato deve rimanere fresco e se può essere condiviso tra utenti o contesti.

Questo è simile al principio della cache HTTP ordinaria.

Per i proxy ad alta intensità di strumenti, ciò può ridurre i caricamenti ripetuti di metadati.

Il tracing distribuito è standardizzato

La revisione documenta anche la propagazione del contesto W3C Trace Context.

Chiavi come:

• traceparent
• tracestate
• baggage

possono essere propagate tramite i metadati MCP.

Ciò consente a una singola traccia distribuita di seguire il lavoro attraverso la catena:

Applicazione host
→ Client MCP
→ Gateway MCP
→ Server MCP
→ API a valle
→ Database

Questo è importante per le distribuzioni a livello enterprise, perché quando i team possono vedere dove si verifica effettivamente la latenza, le chiamate lente agli strumenti diventano molto più facili da debuggare.

Le estensioni diventano una funzionalità di protocollo di prima classe

Il protocollo sta cambiando anche il modo in cui si evolvono le funzionalità opzionali.

Il framework attuale offre alle estensioni:

• Identificatori DNS inversi.
• Negoziazione delle capacità.
• Versionamento indipendente.
• Repository di codice dedicati.
• Manutentori delegati.
• Un percorso formale di estensione nel processo SEP.

Questo è importante perché il protocollo core non deve assorbire ogni nuova idea.

Una funzionalità può prima maturare come estensione, e le capacità comprovate possono successivamente avvicinarsi al core.

App MCP: UI interattive nelle conversazioni

Una delle estensioni MCP più visibili è MCP Apps.

Gli strumenti MCP tradizionalmente restituiscono testo, JSON strutturato o risorse.

Alcune attività richiedono interfacce.

Gli esempi includono dashboard, grafici, mappe, moduli, board Kanban, pannelli di configurazione, canvas di design e lettori video.

MCP Apps consente al server di dichiarare una risorsa UI, che l'host renderizza in un iframe sandboxizzato.

L'utente interagisce con l'app, l'app richiede una chiamata allo strumento, il Server restituisce dati aggiornati e l'app si aggiorna con i nuovi dati. Questa immagine è strettamente correlata al contesto e illustra visivamente l'intero processo di interazione di MCP Apps, dall'istruzione dell'utente all'aggiornamento dell'app.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)

Il flusso semplificato è il seguente:

1. Lo strumento dichiara una risorsa UI.
2. Il modello chiama lo strumento.
3. L'host carica la UI nella sandbox.
4. I dati dello strumento vengono passati all'interfaccia.
5. L'utente interagisce con l'app.
6. L'app può richiedere chiamate aggiuntive allo strumento tramite l'host.
7. L'host mantiene il controllo di autorizzazione e audit su queste operazioni.

MCP Apps è supportato da diversi host compatibili, inclusi Claude e altri prodotti di sviluppo che supportano MCP.

Installazione base di MCP Apps

Il pacchetto di estensione ufficiale può essere installato con il seguente comando:

npm install -S @modelcontextprotocol/ext-apps

Il repository ufficiale degli esempi può essere eseguito localmente:

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start

Questi comandi provengono dalla documentazione ufficiale di MCP Apps e possono variare con l'evoluzione dell'estensione.

Tasks: Lavori a lunga esecuzione che non bloccano la connessione

Gli strumenti degli Agent avviano sempre più spesso lavori che non possono essere completati durante una singola richiesta HTTP ordinaria.

Esempi includono pipeline CI, attività di elaborazione dati su larga scala, distribuzioni cloud, attività di ricerca di lunga durata, rendering video e processi di approvazione umana.

L'estensione MCP Tasks consente al server di restituire un handle di attività persistente, invece di bloccare in attesa del completamento dell'operazione.

I metodi definiti dall'estensione ufficiale includono:

tasks/get
tasks/update
tasks/cancel

Le attività possono passare tra i seguenti stati:

working
input_required
completed
cancelled
failed

Il client può effettuare polling su tasks/get.

Se il server necessita di input dall'utente, l'attività può entrare nello stato input_required.

Il client può inviare l'input tramite tasks/update.

Questo design funziona correttamente anche in caso di disconnessione e non richiede una connessione persistente a lungo termine.

Nota importante sulla compatibilità

La funzionalità Tasks era presente come funzionalità sperimentale nella specifica core 2025-11-25.

La nuova estensione Tasks non è una semplice copia rinominata della vecchia API.

La documentazione ufficiale dell'SDK avverte che la nuova estensione Tasks non è compatibile a livello di protocollo di rete con le precedenti implementazioni sperimentali.

Le applicazioni che utilizzano la vecchia funzionalità Tasks dovrebbero migrare, senza aspettarsi una compatibilità automatica.

Autorizzazione gestita a livello aziendale

Le distribuzioni aziendali affrontano problemi di autorizzazione diversi rispetto alle integrazioni consumer.

Un'azienda può avere migliaia di dipendenti e decine di server MCP approvati.

Non vuole che ogni dipendente autorizzi indipendentemente ogni connettore.

L'estensione Enterprise-Managed Authorization consente alle organizzazioni di gestire centralmente il controllo degli accessi tramite un identity provider.

I modelli IdP aziendali supportati possono includere prodotti come Microsoft Entra ID, Okta e sistemi SSO aziendali.

L'organizzazione può decidere quali dipendenti possono accedere a quali server MCP e quando l'accesso deve essere revocato.

I dipendenti si autenticano con la loro identità aziendale, senza dover completare singole approvazioni OAuth per ogni server MCP.

La documentazione ufficiale di MCP descrive l'autorizzazione gestita a livello aziendale come un'estensione, non come una funzionalità abilitata di default per ogni client.

Sia il client che l'infrastruttura di identità dell'organizzazione devono supportare questa estensione.

Il meccanismo di autorizzazione è stato ulteriormente rafforzato

Il lavoro di autorizzazione core ha ricevuto anche diversi miglioramenti di sicurezza.

Verifica dell'emittente RFC 9207

Le risposte di autorizzazione possono includere il parametro emittente iss.

Il client verifica l'emittente prima di scambiare il codice di autorizzazione.

Questo aiuta a prevenire attacchi di confusione del server di autorizzazione.

Le credenziali del client restano legate al loro emittente

Le credenziali del client registrate non dovrebbero essere riutilizzate tra server di autorizzazione non correlati.

Quando le risorse vengono trasferite ad altri emittenti, il client dovrebbe registrarsi correttamente presso quell'emittente.

Registrazione migliorata per desktop e CLI

Questa revisione chiarisce il comportamento di application_type durante la registrazione dinamica del client.

Questo aiuta a evitare che il server di autorizzazione tratti le applicazioni CLI native o desktop come client web e rifiuti gli URI di reindirizzamento locali.

CIMD è la nuova guida per la registrazione dei client

Il progetto di autorizzazione MCP ha continuato a muoversi verso i Client ID Metadata Documents (CIMD) per le nuove implementazioni, mantenendo la compatibilità DCR dove necessario.

Il consiglio pratico è di seguire la documentazione di autorizzazione attuale, invece di implementare la registrazione dei client basandosi su vecchi tutorial MCP.

JSON Schema 2020-12 completo per gli strumenti

Anche gli schemi degli strumenti sono diventati più espressivi.

inputSchema e outputSchema supportano le funzionalità complete di JSON Schema 2020-12.

Gli schemi di input possono utilizzare:

oneOf
anyOf
allOf
$ref
$defs
dichiarazioni condizionali

Gli schemi di output non sono più limitati a una singola forma ristretta di oggetto.

structuredContent può rappresentare qualsiasi valore JSON supportato dallo schema.

Ciò consente agli strumenti MCP di descrivere in modo più accurato quando l'API presenta tipi union, campi condizionali, definizioni riutilizzabili annidate, forme di output multiple, risultati array o scalari.

Roots, Sampling e Logging sono deprecati

Tre capacità core più vecchie sono state formalmente deprecate:

Funzionalità	Direzione consigliata
Roots	Parametri degli strumenti, URI delle risorse o configurazione del server
Sampling	Integrazione diretta con il provider LLM
Logging	stderr per stdio; OpenTelemetry per osservabilità strutturata

La deprecazione non implica la rimozione immediata.

La nuova policy del ciclo di vita stabilisce che le funzionalità deprecate abbiano un periodo di transizione di almeno dodici mesi prima di poter essere rimosse.

Gli SDK attuali potrebbero continuare a supportare queste capacità per mantenere la compatibilità.

La policy di deprecazione formale cambia il rischio di aggiornamento di MCP

Il redesign stateless include modifiche sostanziali.

I maintainer hanno dichiarato di non volere che questo livello di interruzione diventi la norma.

Il nuovo ciclo di vita delle funzionalità definisce le seguenti fasi:

Attivo (Active)
Deprecato (Deprecated)
Rimosso (Removed)

Le funzionalità deprecate ricevono un periodo minimo di supporto prima della rimozione.

Le estensioni possono anche evolversi in modo indipendente dal core.

Ciò offre ai team una pianificazione della migrazione più prevedibile.

I tunnel MCP risolvono un diverso problema aziendale

La revisione del protocollo rende più facile scalare i server MCP remoti pubblici.

Le aziende spesso affrontano il problema opposto: non vogliono affatto esporre i server pubblicamente.

La funzionalità MCP Tunnel di Anthropic affronta questo caso d'uso per agenti gestiti da Claude e workflow supportati dalla piattaforma Claude.

Un gateway leggero viene eseguito all'interno della rete aziendale e stabilisce connessioni in uscita.

Anthropic descrive questo modello come:

• Nessun endpoint MCP pubblico.
• Nessuna regola firewall in ingresso.
• Nessun IP pubblico richiesto.
• Traffico crittografato end-to-end.

Database interni, sistemi ERP, API private, knowledge base e sistemi di ticketing possono rimanere all'interno del perimetro della rete aziendale.

Il tunnel MCP rimane una funzionalità di prodotto di Claude, non un requisito del protocollo MCP core.

Anthropic attualmente lo descrive come anteprima di ricerca.

App MCP e tunnel non devono essere confusi

Entrambe le funzionalità migliorano MCP in produzione, ma risolvono problemi diversi.

Funzionalità	Problema risolto
App MCP	Interfacce ricche all'interno degli host MCP
Attività	Operazioni strumentali persistenti di lunga durata
Autorizzazione di hosting aziendale	Policy di accesso centralizzate

dell'azienda |
| Tunnel MCP | Accesso a server MCP privati senza esposizione pubblica |
| Core MCP stateless | Trasporto del protocollo scalabile |
| MRTR | Input client durante la chiamata senza sessioni di protocollo a lungo termine |

I server possono utilizzare una, più o tutte queste funzionalità.

Cosa devono cambiare gli sviluppatori di server MCP esistenti?

Se il server funziona già con client MCP precedenti, gli sviluppatori non devono riscrivere immediatamente tutto.

Devono eseguire una migrazione strutturata.

Passaggio 1: Inventario delle dipendenze di sessione nascoste

Cercare codice che dipende da:

• Mcp-Session-Id
• Dizionari in memoria per sessione
• Routing sticky
• Stato client locale alla connessione
• Archiviazione di capacità solo in fase di inizializzazione
• Affinità dell'istanza del server

Determinare se ogni dipendenza è stato del protocollo, stato dell'applicazione, stato di autenticazione o stato di esecuzione temporanea.

Spostare lo stato dell'applicazione in handle espliciti o in archiviazione persistente appropriata.

Passaggio 2: Testare la gestione delle richieste stateless

Utilizzare versioni SDK che supportano la revisione 2026-07-28.

Quindi testare con più istanze del server.

Una configurazione di test utile è:

Client
  ↓
Bilanciatore di carico round-robin
  ↓
Server A / Server B / Server C

Inviare un workflow multipasso e confermare che le richieste consecutive possano raggiungere istanze diverse senza interrompere l'attività.

Passaggio 3: Aggiungere handle di stato espliciti

Per i workflow che richiedono stato, restituire un identificatore stabile:

{
  "job_id": "job_7f18c9"
}

Richiedere che le chiamate successive includano tale identificatore:

{
  "job_id": "job_7f18c9",
  "action": "continue"
}

Validare ogni handle lato server.

Un buon handle deve avere entropia elevata, binding del tenant, controlli di autorizzazione, scadenza, meccanismo di revoca e gestione degli errori chiara.

Passaggio 4: Aggiornare le regole del gateway

Se si utilizza Streamable HTTP, sfruttare le seguenti intestazioni:

Mcp-Method
Mcp-Name

Aggiungere routing, limiti di frequenza, metriche, policy WAF e log di accesso.

Passaggio 5: Aggiungere supporto alla cache

Per risposte di elenco e lettura appropriate, rispettare o generare:

ttlMs
cacheScope

Non condividere tra utenti contenuti sensibili in cache specifici per i dati utente.

Passaggio 6: Migrare le attività precedenti

Se l'applicazione ha utilizzato l'API Tasks sperimentale 2025-11-25, aggiornarla al ciclo di vita esteso.

Testare:

tasks/get
tasks/update
tasks/cancel

e lo stato input_required.

Passaggio 7: Rivedere le funzionalità deprecate

Cercare Roots, Sampling e MCP Logging.

Pianificare la migrazione verso parametri espliciti degli strumenti o URI delle risorse, chiamate dirette al provider di modelli e stderr o OpenTelemetry.

Passaggio 8: Ritestare l'autorizzazione

Verificare la validazione dell'emittente, gli URI di reindirizzamento, la registrazione del client, i token di aggiornamento, la gestione degli scope e la compatibilità con il provider di identità.

Le implementazioni aziendali dovrebbero valutare se EMA è applicabile.

Passaggio 9: Testare i client precedenti

La retrocompatibilità è un problema dell'ecosistema, non solo del server.

Mantenere una matrice di test:

Client	Revisione del protocollo	Risultato
Client attuale	2026-07-28	Percorso stateless previsto
Client precedente	2025-11-25	Percorso di compatibilità
Client non supportato	Versione precedente/sconosciuta	Errore di negoziazione esplicito

Non presupporre silenziosamente che ogni

client venga aggiornato contemporaneamente.

Passaggio 10: Aggiungere osservabilità prima della produzione

Come minimo, misurare:

• Numero di richieste.
• Nomi degli strumenti.
• Latenza.
• Tasso di errore.
• Durata delle attività.
• Frequenza di richieste di input.
• Tasso di hit della cache.
• Numero di errori di autenticazione.
• Latenza delle API a valle.
• ID di tracciamento.

I sistemi stateless sono più facili da scalare, ma i sistemi distribuiti richiedono comunque una buona osservabilità.

Esempio: Prima e dopo la migrazione

Prima della migrazione

Il server memorizza l'oggetto report in memoria:

sessions[session_id]["report"] = report

La chiamata strumento successiva prevede di raggiungere lo stesso processo.

Dopo la migrazione

Il server memorizza lo stato persistente:

report_id = save_report(report)
return {"report_id": report_id}

Lo strumento successivo riceve:

{
  "report_id": "report_123"
}

Qualsiasi istanza del server può caricare il report.

Il cambiamento importante è a livello architetturale:

Stato di sessione di trasporto nascosto
→ Stato applicativo esplicito

MCP stateless significa costi inferiori?

Possibilmente, ma non automaticamente.

Le implementazioni stateless possono ridurre la complessità dell'infrastruttura:

• Nessuna archiviazione di sessione MCP condivisa.
• Minore necessità di routing sticky.
• Più facile implementare l'auto-scaling.
• Più facile fare implementazioni serverless.
• Failover semplificato.

La cache può anche ridurre le chiamate di metadati ripetute.

Tuttavia, lo stato dell'applicazione ha ancora un costo.

Se i workflow richiedono stato persistente, gli sviluppatori potrebbero comunque aver bisogno di Redis, database SQL, archiviazione di oggetti, code di attività o motori di workflow.

Il nuovo design consente agli sviluppatori di scegliere l'architettura di archiviazione, invece di imporre un'unica modalità imposta dalla sessione del protocollo.

MCP sta diventando "l'HTTP del mondo AI"?

L'articolo originale utilizza questa analogia.

L'analogia è utile, ma non va interpretata alla lettera.

HTTP è lo standard di trasporto Web fondamentale, utilizzato in quasi tutti i sistemi Internet.

MCP è un protocollo specializzato per connettere client e agenti AI a strumenti, risorse, prompt, interfacce e servizi esterni.

Ciò che l'analogia cattura è la direzione dello sviluppo:

• Un'interfaccia standard.
• Molti server indipendenti.
• Molti client compatibili.
• Convenzioni condivise.
• Infrastruttura in grado di instradare e osservare le richieste in modo universale.

Il ridisegno del 2026-07-28 rafforza questa analogia, poiché il traffico MCP ora si adatta più naturalmente alla tradizionale infrastruttura HTTP stateless.

Se MCP raggiungerà una diffusione simile a quella di HTTP rimane una questione aperta.

L'ecosistema è più ampio di Claude

MCP ha avuto origine da Anthropic, ma ora è governato come un progetto di protocollo open source più ampio.

L'ecosistema include mantenitori indipendenti, gruppi di lavoro, proposte di miglioramento delle specifiche, SDK in più lingue, app MCP, attività, estensioni di autorizzazione aziendale, registry e implementazioni in diversi prodotti AI.

Ad esempio, le app MCP sono sviluppate con i contributori della community MCP e con i partecipanti di Anthropic, OpenAI e MCP-UI.

Questo è importante perché il valore di un protocollo aumenta quando sia client che server possono implementarlo senza dipendere da un unico fornitore.

Panorama attuale degli SDK

Il progetto MCP ufficiale mantiene o riconosce implementazioni SDK in più linguaggi.

I repository principali includono SDK per TypeScript, Python, Go, C# e altri ecosistemi.

Giugno 2026

L'annuncio della release candidate ha evidenziato in particolare il supporto beta per quattro SDK di primo livello:

• TypeScript.
• Python.
• Go.
• C#.

Entro fine luglio, la documentazione SDK corrente include il comportamento del 2026-07-28.

Poiché l'adozione degli SDK avviene in modo indipendente, consultare sempre le note di rilascio della versione e del linguaggio specifici in uso.

Strategia di migrazione più sicura

Per i sistemi in produzione, evitare migrazioni "a giorno di commutazione".

Il processo più sicuro è:

1. Aggiornare l'ambiente di sviluppo.
2. Eseguire test di coerenza.
3. Testare i client 2026-07-28.
4. Testare i client legacy.
5. Abilitare la distribuzione stateless nell'ambiente di pre-rilascio.
6. Aggiungere più istanze del server.
7. Forzare la distribuzione delle richieste tra le istanze.
8. Testare l'autenticazione.
9. Testare le attività a lunga esecuzione.
10. Testare gli handle di stato dell'applicazione.
11. Monitorare latenza ed errori.
12. Implementare gradualmente.

Questo è particolarmente importante perché la nuova revisione modifica intenzionalmente il comportamento fondamentale del ciclo di vita.

Cosa non si deve dare per scontato

Non dare per scontato che ogni server sia automaticamente serverless

Il protocollo supporta più naturalmente distribuzioni serverless.

La tua applicazione potrebbe comunque richiedere database, esecutori di attività persistenti, archiviazione file o tempi di esecuzione più lunghi.

Non dare per scontato che tutto lo stato scompaia

Solo lo stato di sessione a livello di protocollo viene rimosso dal nuovo modello online.

Lo stato dell'applicazione rimane una questione dell'applicazione stessa.

Non dare per scontato che le app MCP funzionino in ogni client

Le estensioni sono negoziate e il supporto degli host varia.

Non dare per scontato che le attività siano retrocompatibili

L'estensione Tasks attuale è diversa dalle implementazioni sperimentali precedenti.

Non dare per scontato che la deprecazione significhi inutilizzabilità

Roots, Sampling e Logging rimangono disponibili durante il periodo di deprecazione.

Non dare per scontato che tutti i client supportino già 2026-07-28

L'adozione da parte di SDK e prodotti procede a ritmi diversi.

Non dare per scontato che "protocollo aperto" significhi "nessun lavoro di sicurezza"

MCP può eseguire strumenti potenti.

Autorizzazione, consenso dell'utente, sandboxing, progettazione degli strumenti, gestione dei segreti e audit rimangono fondamentali.

Domande frequenti

Cos'è MCP 2026-07-28?

MCP 2026-07-28 è la più grande revisione architetturale del Model Context Protocol dal suo lancio. I cambiamenti principali includono un nucleo di protocollo stateless, la rimozione dell'handshake di sessione nel nuovo formato online, estensioni di primo livello, applicazioni MCP, Tasks ridisegnati, MRTR, autorizzazione più forte, metadati di cache e una politica di deprecazione formale.

MCP è ora completamente stateless?

Il livello di protocollo 2026-07-28 è progettato per essere stateless. Le applicazioni possono comunque mantenere stato tramite handle espliciti, database, sistemi di workflow o altre forme di archiviazione persistente.

Cosa è cambiato con Mcp-Session-Id?

Il formato online 2026-07-28 rimuove il meccanismo Mcp-Session-Id a livello di protocollo. Gli SDK attuali possono ancora supportare il comportamento basato su sessione durante la negoziazione di revisioni di protocollo precedenti per garantire la retrocompatibilità.

Posso distribuire server MCP su AWS Lambda o Cloudflare Workers?

Il protocollo stateless rende più semplice la distribuzione serverless ed edge, poiché le richieste non richiedono più affinità di sessione a livello di protocollo. Il tuo server deve comunque soddisfare i limiti di esecuzione, rete, archiviazione e durata del runtime.

Cosa sono le app MCP?

Le app MCP sono un'estensione ufficiale

che consente agli strumenti di restituire interfacce interattive, come dashboard, moduli, grafici e altre esperienze HTML, all'interno di host MCP compatibili. L'interfaccia viene eseguita in un iframe in sandbox e comunica tramite l'host MCP.

Cosa sono le attività MCP?

La funzionalità Tasks consente ai server di restituire handle di attività asincrone persistenti per lavori a lunga esecuzione. I client possono interrogare lo stato con tasks/get, fornire input richiesti con tasks/update o annullare l'operazione con tasks/cancel.

Cos'è l'autorizzazione aziendale gestita?

L'autorizzazione aziendale gestita è un'estensione di MCP che implementa il controllo degli accessi centralizzato tramite il provider di identità dell'organizzazione. Consente agli amministratori IT di gestire l'accesso ai server MCP in base alle policy di identità aziendali, senza che ogni utente debba autorizzare singolarmente ciascun server.

Devo migrare immediatamente dal vecchio MCP?

Non necessariamente. Gli SDK supportano revisioni di protocollo precedenti tramite negoziazione di versione, e le funzionalità deprecate ricevono una finestra di supporto chiara. I team di produzione dovrebbero comunque iniziare i test, poiché il design stateless cambia le ipotesi su sessioni, operazioni a lunga esecuzione e infrastruttura.

Strumenti correlati

• Model Context Protocol: Documentazione ufficiale su specifica, architettura, SDK, estensioni e guida per sviluppatori di MCP.
• MCP TypeScript SDK: Implementazione TypeScript ufficiale per client e server MCP.
• MCP Python SDK: SDK Python ufficiale ed esempi per lo sviluppo MCP.
• MCP Go SDK: Implementazione Go ufficiale, attualmente con supporto per il percorso protocollo stateless.
• MCP C# SDK: SDK .NET ufficiale con documentazione dettagliata su modalità stateless, attività e compatibilità.
• MCP Apps: Documentazione ufficiale dell'estensione e SDK per interfacce interattive negli host MCP.
• MCP Tasks: Documentazione ufficiale per le operazioni MCP asincrone a lunga esecuzione.
• [MCP Registry](https://registry.modelcontextprotocol.

io/): infrastruttura di registro ufficiale per scoprire server MCP pubblicati.

Link correlati

• Panoramica della release candidate MCP 2026-07-28: spiegazioni ufficiali dei manutentori su refactoring stateless, estensioni, modifiche all'autenticazione, caching e contenuti deprecati.
• Release del repository delle specifiche MCP: cronologia ufficiale delle release GitHub per le revisioni del protocollo.
• Roadmap MCP 2026: roadmap ufficiale che copre estensibilità dei trasporti, comunicazione tra agenti, governance e preparazione aziendale.
• Documentazione ufficiale MCP Apps: specifiche, SDK, esempi e guide per sviluppatori per applicazioni MCP interattive.
• Estensione MCP Tasks:

Specifiche ufficiali delle attività, ciclo di vita, modello di sicurezza e metodi supportati.

• Autorizzazione gestita a livello aziendale: documentazione ufficiale sull'accesso MCP basato su provider di identità centralizzati.
• Tunnel MCP Anthropic: documentazione Anthropic sulle connessioni MCP a reti private negli agenti gestiti da Claude.

Riepilogo

La revisione MCP 2026-07-28 spinge il protocollo verso modelli infrastrutturali già ampiamente adottati nei grandi sistemi web. Le richieste diventano autocontenute, le sessioni a livello di protocollo scompaiono dal nuovo formato online, il routing dei gateway diventa più semplice e la scalabilità orizzontale ordinaria non richiede più sessioni MCP sticky.

Nel frattempo, l'ecosistema si sta evolvendo verso l'alto. Le applicazioni MCP aggiungono UI interattive, le attività supportano lavoro asincrono persistente, l'autorizzazione gestita a livello aziendale centralizza gli accessi aziendali e i tunnel MCP forniscono percorsi per server privati interni agli utenti della piattaforma Claude.

La migrazione non consiste semplicemente nel "rimuovere gli ID di sessione". I team devono identificare le dipendenze di stato nascoste, migrare lo stato dell'applicazione verso handle espliciti o storage persistente, testare MRTR e attività, aggiornare l'autorizzazione, mantenere la compatibilità con i client meno recenti e aggiungere un'osservabilità adeguata.

Il cambiamento più importante è a livello architetturale: MCP sta passando da un modello di integrazione degli agenti orientato alla connessione a un protocollo stateless e scalabile che si adatta in modo più naturale alle moderne infrastrutture cloud.