MCP 2026-07-28 Guida alla migrazione: server senza stato

TL;DR: MCP 2026-07-28 rimuove le sessioni a livello di protocollo e l’handshake di inizializzazione obbligatorio. I team di produzione dovrebbero individuare le dipendenze nascoste dalle sessioni, adottare metadati di protocollo per richiesta, implementare le Richieste Multi Round-Trip (MRTR), aggiornare le policy del gateway e introdurre il nuovo protocollo in canary prima di ritirare il comportamento legacy.

La specifica Model Context Protocol rilasciata il 28 luglio 2026 introduce il più grande cambiamento architetturale a MCP dall’aggiunta del supporto al trasporto remoto.

Il protocollo ora utilizza un nucleo stateless di richiesta e risposta. Lo scambio obbligatorio initialize e notifications/initialized è stato rimosso, Mcp-Session-Id è stato eliminato e ogni richiesta trasporta le informazioni di protocollo necessarie per elaborarla.

Il rilascio introduce anche le Multi Round-Trip Requests, le intestazioni di instradamento HTTP, le risposte di elenco cacheabili, un comportamento di autorizzazione più rigoroso, un framework per le estensioni e un ciclo di vita formale di deprecazione. Vedi l’annuncio ufficiale del rilascio MCP 2026-07-28 e il changelog completo della specifica per i dettagli a livello di protocollo.

Questi cambiamenti rendono più semplice scalare i server MCP remoti dietro l’infrastruttura HTTP standard. Non rendono automaticamente stateless un’applicazione esistente.

Un server in produzione può ancora basarsi su workspace in memoria, instradamento sticky, credenziali legate alla sessione, stream di lunga durata o interazioni avviate dal server. Questa guida si concentra sull’individuazione e sulla sostituzione di tali dipendenze.

Per una spiegazione introduttiva all’implementazione, leggi How to Create an MCP Server for Claude Code prima di iniziare la migrazione.

Chi deve migrare?

Il livello di sforzo dipende da come MCP è utilizzato nel tuo sistema.

Un server locale che non conserva stato tra le richieste può richiedere solo un aggiornamento dell’SDK e test di compatibilità.

Un deployment remoto che usa sessioni, OAuth, streaming o richieste avviate dal server richiede una migrazione graduale.

Cosa è cambiato in MCP 2026-07-28?

1. Verificare l’implementazione esistente

Prima dell’upgrade, cerca nel client, server, gateway e configurazione di deployment ipotesi legate al protocollo più vecchio.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Poi rispondi alle seguenti domande:

1. Il server rifiuta le chiamate finché l’inizializzazione non è completa?
2. Un session ID seleziona un utente, credenziale, workspace o conversazione?
3. Un’altra istanza di server può proseguire un workflow iniziato dalla prima?
4. Il load balancer richiede affinità di sessione?
5. Uno strumento esegue un effetto collaterale prima di richiedere conferma?
6. Il gateway analizza il body per identificare metodo o tool?
7. Le credenziali OAuth sono archiviate senza il relativo authorization server emittente?
8. Il client dipende dalla riconnessione SSE o dalla riconsgna dei messaggi?
9. Gli elenchi di tool o risorse variano in base alla connessione?
10. Quali funzionalità deprecate ricevono ancora traffico in produzione?

Non rimuovere Mcp-Session-Id finché non capisci cosa l’applicazione memorizza dietro di esso.

Un server che rimuove l’intestazione ma mantiene lo stato in memoria locale può funzionare in sviluppo e fallire in modo intermittente quando le richieste vengono distribuite su più istanze.

2. Sostituire lo stato di sessione nascosto

MCP 2026-07-28 rimuove le sessioni a livello di protocollo, non lo stato dell’applicazione.

Lo stato necessario tra le chiamate dovrebbe usare uno di tre pattern.

Handle espliciti

Restituisci un handle generato dal server da uno strumento e richiedilo nelle chiamate successive.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace creato."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Una richiesta successiva passa l’handle come argomento ordinario:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Questo rende la dipendenza visibile nel contratto dello strumento e consente a qualsiasi istanza di server compatibile di elaborare la richiesta.

Storage condiviso

Usa un database, cache distribuita, object store o sistema di task durevoli quando:

• più worker necessitano dello stesso stato;
• il workflow deve sopravvivere a un riavvio;
• lo stato è troppo grande per un handle;
• il workflow dura più di una singola richiesta;
• è richiesto comportamento transazionale o monouso.

requestState protetto

MRTR può restituire un valore requestState opaco che il client riecheggia quando ritenta la richiesta originale.

Poiché il valore passa attraverso il client, proteggilo con un HMAC o cifratura autenticata. Vincolalo al principal autenticato, all’operazione originale, a parametri importanti, al tempo di scadenza e a un nonce quando è richiesta la protezione dal replay.

Non fidarti di un valore requestState non firmato solo perché il client lo ha restituito invariato.

3. Adottare richieste autosufficienti e discovery

Le richieste MCP moderne includono il contesto di protocollo in _meta.

Una chiamata di tool Streamable HTTP può apparire così:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "migrazione MCP senza stato"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

I server che prendono di mira il nuovo protocollo devono implementare server/discover, che pubblicizza versioni supportate, capacità e identità del server. I client possono chiamarlo prima di un’altra operazione o usarlo per determinare se è richiesto un fallback legacy.

Leggi la server/discover documentation ufficiale per il contratto di risposta.

Negoziazione di versione nell’SDK TypeScript

Aggiornare il solo SDK TypeScript non commuta automaticamente un client al nuovo protocollo.

Un client che usa l’SDK v2 deve optare esplicitamente:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

In modalità automatica, l’SDK effettua un probe con server/discover e può eseguire il fallback al flusso di inizializzazione precedente quando raggiunge un server legacy.

I team che usano ancora @modelcontextprotocol/sdk v1 dovrebbero prima seguire la guida di migrazione da v1 a v2 dell’SDK TypeScript. I team che già usano v2 dovrebbero usare la guida al supporto del protocollo 2026-07-28.

4. Sostituire le richieste avviate dal server con MRTR

Le implementazioni MCP precedenti potevano inviare richieste come elicitation/create, sampling/createMessage o roots/list dal server al client.

Il nuovo protocollo sostituisce quel modello con le Multi Round-Trip Requests.

Il flusso è:

1. Il client invia la richiesta originale.
2. Il server restituisce resultType: "input_required".
3. Il client raccoglie le informazioni o l’approvazione richiesta.
4. Il client ritenta l’operazione originale usando un nuovo ID JSON-RPC.
5. Il retry include inputResponses e il requestState originale.
6. Il server completa la richiesta o avvia un altro round.

Risposta di esempio:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Eliminare il progetto project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Il client ritenta l’operazione originale:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Un’implementazione MRTR in produzione dovrebbe definire:

• numero massimo di round;
• scadenza del request-state;
• comportamento di cancellazione e rifiuto;
• validazione dello schema di risposta;
• controlli di autorizzazione su ogni retry;
• protezione dal replay;
• idempotenza per gli effetti collaterali;
• comportamento quando un client non supporta la capacità richiesta.

Evita di completare un acquisto, una cancellazione, una detrazione di credito o una scrittura esterna prima di restituire input_required.

Usa un’operazione a fasi o una chiave di idempotenza affinché i retry non possano duplicare l’azione. Vedi la specifica MRTR ufficiale per il modello di interazione completo.

5. Aggiornare gateway, caching e autorizzazione

I cambiamenti infrastrutturali sono strettamente correlati e dovrebbero essere testati insieme.

Convalidare le intestazioni di instradamento MCP

Le richieste POST Streamable HTTP ora includono:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Queste intestazioni permettono ai gateway di instradare, misurare, autorizzare e applicare rate limit al traffico senza analizzare ogni corpo JSON.

Possono supportare controlli come:

• rate limit specifici per tool;
• policy separate per metodi di elenco ed esecuzione;
• pool di worker dedicati per strumenti costosi;
• accesso ristretto a operazioni ad alto rischio;
• metriche di latenza ed errori per tool;
• attribuzione dei costi infrastrutturali.

I valori sono comunque forniti dal client. Confrontali con il body JSON-RPC prima di applicare la policy.

Una richiesta non deve poter dichiarare un tool a basso rischio in Mcp-Name pur invocando un tool diverso nel body. Le discrepanze tra intestazioni e body dovrebbero essere rifiutate e loggate.

Usare cache key consapevoli dell’autorizzazione

Il nuovo protocollo aggiunge ttlMs e cacheScope ai risultati cacheabili inclusi:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Una cache key dovrebbe normalmente includere:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Non riutilizzare una voce di cache privata tra utenti o tenant solo perché il TTL non è scaduto.

Anche l’ordinamento deterministico degli strumenti è importante. Un catalogo stabile evita miss di cache non necessari e può migliorare il riuso della prompt-cache del modello quando le definizioni degli strumenti sono inserite nei prompt.

Rafforzare la gestione dell’issuer OAuth

Durante la migrazione dell’autorizzazione:

• valida un valore iss restituito rispetto all’issuer registrato per il flusso;
• indicizza le credenziali client archiviate per issuer;
• non riutilizzare credenziali con un altro authorization server;
• imposta un application_type appropriato durante la DCR;
• prepara le nuove integrazioni ai Client ID Metadata Documents.

La Dynamic Client Registration resta disponibile per compatibilità retroattiva, ma è deprecata come approccio preferito alla registrazione.

6. Migrare notifiche, Tasks e funzionalità deprecate

Il vecchio percorso di notifica HTTP GET e il flusso resources/subscribe o resources/unsubscribe sono stati sostituiti da subscriptions/listen.

I client aprono uno stream di risposta POST di lunga durata e optano nelle categorie di notifica di cui hanno bisogno. Le notifiche di avanzamento e log specifiche della richiesta rimangono associate allo stream di risposta per la richiesta che descrivono.

Per deployment multi-istanza, usa un bus eventi condiviso quando le notifiche generate su una istanza di server devono raggiungere una sottoscrizione connessa a un’altra.

Estensione Tasks

Il lavoro di lunga durata è stato spostato dal protocollo core sperimentale a:

io.modelcontextprotocol/tasks

L’estensione usa:

• tasks/get per il polling;
• tasks/update per gli aggiornamenti client-to-server;
• handle di task durevoli;
• subscriptions/listen per aggiornamenti opt-in.

I vecchi pattern tasks/result e tasks/list non dovrebbero essere trasportati in una nuova implementazione.

Funzionalità deprecate

Le seguenti funzionalità sono deprecate:

La funzionalità deprecata rimane disponibile durante la finestra di deprecazione, ma le nuove implementazioni non dovrebbero adottarla. La policy di ciclo di vita MCP fornisce un periodo minimo di deprecazione di dodici mesi; non significa che ogni funzionalità abbia la stessa data confermata di rimozione.

Consulta il registro delle funzionalità deprecate ufficiale prima di impostare una data di ritiro.

7. Distribuire la migrazione in sicurezza

Non cambiare client, server, gateway, caching e autorizzazione in un’unica release non osservata.

Ordine di migrazione consigliato

1. Inventaria versioni di protocollo, SDK, sessioni, traffico SSE, client DCR e metodi deprecati.
2. Aggiorna gli SDK non di produzione.
3. Aggiungi server/discover e la negoziazione di versione.
4. Sostituisci le dipendenze nascoste dalle sessioni.
5. Implementa e metti in sicurezza MRTR.
6. Aggiungi intestazioni di instradamento convalidate e cache con scope.
7. Verifica i confini degli issuer per l’autorizzazione.
8. Esegui un canary del protocollo moderno affiancato al percorso legacy.
9. Ritira il comportamento più vecchio solo dopo aver rivisto la telemetria.

Compatibilità durante il canary

Client moderno + server moderno
→ Usa MCP 2026-07-28

Client moderno + server legacy
→ Effettua probe e fallback quando supportato

Client legacy + server dual-version
→ Continua sul percorso legacy

Combinazione non supportata
→ Restituisce un errore chiaro di versione del protocollo

Il rilascio di una nuova specifica MCP non è un interruttore per tutto l’ecosistema. Client, server, SDK e piattaforme hosted migreranno a velocità diverse.

Telemetria da registrare

Le richieste tools/call one-shot riuscite non sono sufficienti a misurare la migrazione. Un workflow che scade ripetutamente, richiede input non necessari o duplica una scrittura esterna è comunque un fallimento in produzione.

Come si inserisce CometAPI in un’architettura MCP

MCP non sostituisce una model API. I due livelli risolvono problemi di integrazione diversi.

Un’architettura di produzione tipica appare così:

Applicazione o agente
        ↓
Client e server MCP
Strumenti, risorse, approvazioni, task
        ↓
API modello unificata
GPT, Claude, Gemini, DeepSeek e altri modelli

MCP standardizza come gli agenti interagiscono con strumenti e contesto. Non standardizza prezzi dei modelli, credenziali dei provider, endpoint di inference o failover dei provider.

Questa separazione diventa particolarmente utile quando si migra lontano dalla funzionalità Sampling deprecata. Se un server MCP o l’agente che lo consuma ha ancora bisogno dell’inferenza di un modello, l’applicazione può chiamare direttamente una model API invece di dipendere dal precedente flusso MCP Sampling.

Quando aiuta un gateway di modelli unificato

Un gateway di modelli unificato può ridurre il lavoro operativo quando:

• diversi server MCP necessitano di accesso a differenti provider di modelli;
• strumenti diversi richiedono modelli diversi;
• i team vogliono cambiare modello senza riscrivere integrazioni specifiche del provider;
• credenziali, uso e billing devono essere gestiti centralmente;
• l’accesso ai modelli dovrebbe rimanere indipendente dai cambiamenti di trasporto MCP.

CometAPI fornisce un endpoint compatibile con OpenAI che può essere usato come livello di accesso ai modelli dietro applicazioni MCP. Questo mantiene la logica del provider di modelli separata da strumenti, risorse e orchestrazione dei task MCP.

Per esempio, uno strumento MCP può chiamare un modello tramite lo stesso client compatibile OpenAI usato altrove nell’applicazione:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Riassumi la risorsa fornita in modo chiaro e conciso."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Il server MCP resta responsabile del contratto dello strumento, autorizzazione, stato e gestione del risultato. Il gateway di modelli gestisce selezione del modello, accesso al provider e risposte di inferenza.

Mantenere separati questi livelli fornisce due benefici pratici:

1. I client e i server MCP possono migrare al nuovo protocollo senza cambiare il livello di integrazione con i modelli.
2. I provider di modelli possono essere cambiati senza riprogettare gli strumenti MCP o il comportamento del trasporto.

Per ulteriori dettagli di implementazione, vedi la Quickstart di CometAPI, la documentazione API e la guida alle applicazioni AI multi-modello.

Checklist di migrazione MCP 2026-07-28

Client

• Aggiorna a un SDK compatibile.
• Abilita la negoziazione di versione moderna.
• Supporta server/discover.
• Includi metadati di protocollo su ogni richiesta.
• Gestisci resultType.
• Supporta o rifiuta esplicitamente MRTR.
• Usa un nuovo ID JSON-RPC per i retry.
• Conserva e restituisci requestState.
• Valida gli issuer OAuth.
• Archivia le credenziali per issuer.
• Rispetta gli hint di cache.
• Supporta subscriptions/listen quando necessario.

Server

• Rimuovi i gate di inizializzazione per richieste moderne.
• Rimuovi le dipendenze da Mcp-Session-Id.
• Implementa server/discover.
• Sostituisci lo stato nascosto con handle o storage condiviso.
• Restituisci resultType.
• Sostituisci le richieste avviate dal server con MRTR.
• Proteggi requestState.
• Convalida tutte le inputResponses.
• Aggiungi idempotenza per gli effetti collaterali.
• Restituisci elenchi deterministici.
• Pubblica hint di cache conservativi.
• Migra il lavoro di lunga durata all’estensione Tasks.

Gateway e infrastruttura

• Convalida le intestazioni di richiesta MCP.
• Confronta le intestazioni con il body della richiesta.
• Rimuovi l’instradamento sticky non necessario.
• Testa le richieste su più istanze.
• Partiziona le cache per confine di autorizzazione.
• Aggiungi un bus di notifica condiviso quando richiesto.
• Traccia traffico legacy e deprecato.
• Mantieni un percorso di rollback durante il canary.

FAQ

Che cos’è MCP 2026-07-28?

MCP 2026-07-28 è la specifica Model Context Protocol rilasciata il 28 luglio 2026. Introduce un core di protocollo stateless, le Multi Round-Trip Requests, intestazioni di instradamento HTTP, risultati cacheabili, cambiamenti di autorizzazione, estensioni e un ciclo di vita formale di deprecazione.

Mcp-Session-Id è stato rimosso?

Sì. Il nuovo protocollo Streamable HTTP non usa più Mcp-Session-Id.

Le applicazioni possono ancora preservare lo stato tramite handle espliciti, storage condiviso, task durevoli o valori di request-state protetti.

L’handshake di inizializzazione MCP è stato rimosso?

Sì. Le richieste moderne non richiedono più lo scambio initialize e notifications/initialized.

I server devono implementare server/discover, sebbene i client non debbano chiamarlo prima di ogni operazione.

MCP stateless significa che gli strumenti non possono preservare lo stato?

No. Stateless si riferisce al livello di protocollo.

Uno strumento può ancora archiviare stato, ma l’elaborazione della richiesta non dovrebbe dipendere da affinità di trasporto nascoste o da un processo server specifico.

Che cos’è MRTR?

Le Multi Round-Trip Requests permettono a un server di richiedere input aggiuntivo al client o all’utente senza inviare una richiesta avviata dal server su una connessione bidirezionale continuamente aperta.

Il server restituisce input_required e il client ritenta l’operazione originale con le risposte richieste.

HTTP+SSE viene rimosso immediatamente?

No. È deprecato, non rimosso immediatamente.

I nuovi server dovrebbero usare Streamable HTTP, mentre i sistemi esistenti dovrebbero misurare e migrare il traffico HTTP+SSE rimanente.

I client SDK TypeScript v2 usano MCP 2026-07-28 automaticamente?

No. L’SDK v2 TypeScript richiede una configurazione esplicita di negoziazione delle versioni per usare il protocollo moderno.

Usa la negoziazione automatica quando il client deve funzionare sia con server moderni sia legacy.

Raccomandazioni finali

MCP 2026-07-28 rende più semplice scalare, instradare, mettere in cache e osservare l’infrastruttura MCP remota. Il principale rischio di migrazione non è semplicemente la rimozione di un’intestazione o di un handshake. Sono lo stato applicativo nascosto e la logica di interazione che potrebbero ancora dipendere da essi.

Prima di distribuire il nuovo protocollo:

Trova ogni dipendenza da inizializzazione e Mcp-Session-Id.

1. Sposta lo stato necessario in handle espliciti o storage condiviso.
2. Implementa MRTR con scadenza, protezione dal replay e idempotenza.
3. Convalida le intestazioni MCP rispetto al body JSON-RPC.
4. Partiziona le cache per tenant e scope di autorizzazione.
5. Rafforza la validazione dell’issuer OAuth.
6. Misura metodi deprecati e traffico di trasporto legacy.
7. Esegui un canary dei percorsi di protocollo moderni e legacy prima del ritiro.

Tratta la migrazione come un cambiamento d’infrastruttura, non come un semplice upgrade dell’SDK.

Una volta che il livello MCP è stateless e osservabile, mantieni l’accesso al modello dietro un’interfaccia separata. Ciò consente al protocollo degli strumenti e al livello dei provider di modelli di evolvere in modo indipendente.