Amazon AWS sostiene MCP stateless, ma la compatibilità è ora il vero banco di prova

Amazon AWS ha aggiunto il supporto a MCP 2026-07-28 in AgentCore Gateway due giorni dopo che la più ampia revisione architetturale della specifica è arrivata alla release stabile. Una chiamata UpdateGateway può abilitare la nuova versione del protocollo su un gateway esistente. Tuttavia, questo semplice cambiamento del control plane nasconde una transizione più complessa per client, server e team di sicurezza aziendale.

La nuova revisione del Model Context Protocol elimina le sessioni a livello di protocollo e fa sì che ogni richiesta descriva la propria versione e le capacità del client. MCP è uno standard aperto per connettere applicazioni AI a strumenti, fonti dati e altri servizi. Il suo design stateless dovrebbe rendere i gateway più facili da scalare, instradare e ripristinare.

Questo vantaggio comporta una verifica di compatibilità. I client devono adottare nuovi metadati di richiesta, i server devono implementare il discovery e le vecchie assunzioni sulle sessioni non sono più valide. Amazon Bedrock AgentCore Gateway si colloca ora tra queste due ere del protocollo, traducendo servizi aziendali in strumenti MCP e applicando controlli di accesso su un endpoint gestito.

La vera storia è quindi più ampia di una casella di selezione della versione. Amazon AWS scommette che un gateway gestito possa assorbire l'evoluzione del protocollo prima che raggiunga ogni team applicativo. Il successo dipende dalla negoziazione della versione, dalla correttezza delle autorizzazioni e dal comportamento di parchi client eterogenei.

Amazon AWS trasforma un'importante riscrittura di MCP in un singolo aggiornamento del gateway

AWS ha ridotto il passaggio infrastrutturale a una sola operazione API, ma le applicazioni devono comunque parlare correttamente il protocollo rivisto.

I responsabili di MCP hanno rilasciato la specifica stabile 2026-07-28 il 28 luglio, dopo un periodo di release candidate iniziato a maggio. La release stabile di MCP sostituisce diverse assunzioni consolidate durante la crescita iniziale del protocollo.

AWS ha seguito con il supporto in Amazon Bedrock AgentCore Gateway. Secondo l'aggiornamento di AgentCore dell'azienda, i proprietari dei gateway possono aggiungere la nuova revisione tramite UpdateGateway. La richiesta aggiorna la configurazione del protocollo MCP del gateway e l'elenco delle versioni supportate.

L'oggetto rilevante del control plane è protocolConfiguration.mcp.supportedVersions. AWS documenta quel campo come un array di versioni MCP che il gateway può utilizzare. UpdateGateway restituisce lo stato HTTP 202 quando il servizio accetta un aggiornamento, dopodiché il gateway passa attraverso uno stato di aggiornamento.

Questa distinzione conta dal punto di vista operativo. Una chiamata accettata non significa che ogni client connesso abbia completato con successo una richiesta. I team dovrebbero attendere che il gateway torni allo stato ready, quindi eseguire test di conformità e dei carichi di lavoro sull'endpoint effettivo.

La modifica non richiede alle organizzazioni di ricostruire ogni funzione Lambda, servizio OpenAPI o servizio Smithy dietro il proprio gateway. AgentCore Gateway converte già queste risorse in strumenti compatibili con MCP. Supporta inoltre target MCP remoti e altri servizi HTTP, a seconda della configurazione del target.

Questa architettura consente ad AWS di modificare il livello esposto al protocollo senza richiedere cambiamenti identici in ogni servizio aziendale downstream. Un'API di assistenza clienti può rimanere un'API, ad esempio, mentre il gateway espone le sue operazioni come strumenti ad agenti compatibili.

AgentCore Gateway gestisce anche l'autenticazione in ingresso, le credenziali in uscita, il discovery degli strumenti, il routing e l'applicazione delle policy. Questi controlli diventano più preziosi quando un endpoint serve servizi di proprietà di vari team interni.

Tuttavia, la chiamata UpdateGateway modifica soltanto il supporto dichiarato dal gateway. Un client che utilizza la revisione 2026 deve comunque inviare i metadati e gli header richiesti. Un client meno recente deve negoziare una revisione supportata da entrambe le parti o utilizzare un percorso di fallback compatibile.

Questo è il primo vincolo dietro il semplice messaggio di aggiornamento di AWS. Il servizio gestito può ridurre il lavoro della piattaforma, ma non può far sì che un SDK obsoleto emetta un nuovo formato wire.

Il secondo vincolo riguarda i test. I proprietari dei gateway devono verificare l'elenco degli strumenti, le chiamate agli strumenti, gli errori di autenticazione, il comportamento dello streaming e i controlli della cache per ogni versione supportata. Il successo con un moderno client non dimostra la compatibilità nell'intero parco aziendale.

Un rollout pratico parte quindi dall'inventario. I team devono identificare quali applicazioni agent si connettono al gateway, quali versioni di SDK utilizzano e se tali SDK supportano MCP 2026-07-28.

Le organizzazioni che mantengono decisioni tecniche e prove dei test in una knowledge base ingegneristica ricercabile possono registrare i risultati per client e versione del protocollo. Questo archivio diventa importante quando un errore compare solo in un framework o canale di distribuzione.

AWS ha reso piccola l'azione sul control plane. La verifica a livello applicativo rimane il vero progetto di migrazione.

Perché MCP stateless cambia l'equazione del gateway

MCP stateless sposta le informazioni sulla compatibilità in ogni richiesta, semplificando il routing orizzontale e imponendo al tempo stesso che ogni messaggio sia autosufficiente.

Le precedenti revisioni di MCP utilizzavano uno scambio di inizializzazione per stabilire dettagli e capacità del protocollo. Un client inviava initialize, il server rispondeva e il client completava la sequenza con notifications/initialized. Streamable HTTP poteva inoltre utilizzare un header Mcp-Session-Id per associare il traffico successivo a una sessione a livello di protocollo.

Le principali modifiche di MCP eliminano questo ciclo di vita nella nuova revisione. Eliminano inoltre l'identificatore di sessione a livello di protocollo. I server che necessitano di stato tra le chiamate devono emettere handle espliciti, che i client passano come normali argomenti degli strumenti.

Ogni richiesta nel nuovo stile include la versione del protocollo e le capacità del client all'interno di _meta. I client dovrebbero inoltre identificarsi in quella sede. I server restituiscono la propria identità nei metadati del risultato, rendendo ogni scambio più autoesplicativo.

Un nuovo metodo server/discover consente a un client di ispezionare versioni supportate, capacità e identità del server prima di iniziare altre attività. Un server che utilizza la revisione 2026-07-28 deve implementare questa chiamata di procedura remota.

Questo design cambia ciò che un gateway deve ricordare. Non deve più dipendere da uno scambio di inizializzazione completato tramite una connessione né associare il traffico successivo del protocollo a una sessione MCP opaca.

Un bilanciatore di carico può instradare richieste separate senza preservare l'affinità a livello di protocollo. Un'istanza del gateway che riceve la decima chiamata può ispezionare le stesse informazioni essenziali sulla compatibilità ricevute dalla prima istanza.

Questo modello si adatta a un gateway cloud gestito. I servizi stateless possono scalare tra worker, sostituire capacità non sana e distribuire il traffico senza ripristinare un record di sessione MCP prima di interpretare ogni richiesta.

Riduce inoltre un'incompatibilità scomoda tra infrastrutture cloud a breve durata e comportamento dei protocolli orientato alla connessione. Le funzioni serverless e i gateway distribuiti funzionano generalmente meglio quando le richieste contengono le informazioni necessarie per un'elaborazione indipendente.

Tuttavia, stateless non significa che il lavoro dell'agente non abbia stato. Un flusso di acquisto potrebbe comunque richiedere informazioni di approvazione, un riferimento di transazione o dati raccolti durante uno scambio precedente. La specifica sposta questo stato in handle espliciti a livello applicativo invece di nasconderlo nella sessione di trasporto.

Questo cambiamento può migliorare la visibilità. Gli argomenti degli strumenti e gli handle emessi dal server creano confini di responsabilità più chiari rispetto allo stato dedotto da una connessione. Richiedono inoltre una progettazione attenta, poiché i client potrebbero ritentare le richieste o presentare handle obsoleti.

La nuova revisione elimina la ripresa di Streamable HTTP tramite Last-Event-ID e gli identificatori di eventi inviati dal server. Se uno stream di risposta si interrompe durante una richiesta, il client deve inviare una nuova richiesta con un nuovo ID richiesta.

Questa regola crea un'importante domanda operativa. Se uno strumento esegue un effetto collaterale prima che lo stream fallisca, un nuovo tentativo alla cieca potrebbe ripetere l'azione, a meno che l'applicazione non implementi l'idempotenza.

Si consideri un agente che crea un ticket di assistenza. Il servizio di ticket potrebbe archiviare correttamente il record mentre lo stream di risposta scompare. Un nuovo tentativo dovrebbe includere una chiave di idempotenza a livello applicativo oppure interrogare l'operazione precedente prima di creare un altro ticket.

AWS non può risolvere ogni problema di idempotenza downstream al confine del protocollo. I log e le tracce del gateway possono mostrare le chiamate ripetute, ma il servizio target deve definire un comportamento sicuro per i nuovi tentativi.

La revisione sostituisce inoltre le chiamate separate avviate dal server con Multi Round-Trip Requests. In questo schema, un server restituisce un risultato input_required che descrive le informazioni di cui ha ancora bisogno. Il client ritenta la richiesta originale con le risposte richieste.

Questo approccio mantiene il controllo all'interno di una sequenza di richiesta e tentativo. Evita che una richiesta indipendente dal server al client arrivi tramite una connessione che potrebbe non appartenere a un'altra istanza del gateway.

Tutti i risultati ora includono un resultType, normalmente complete oppure input_required. I client che comunicano con server meno recenti devono trattare un valore omesso come risultato completato, preservando un ponte di compatibilità limitato.

Il meccanismo favorisce chiaramente l'infrastruttura distribuita. Il compromesso è che SDK e applicazioni devono adottare metadati, logica di retry e gestione dello stato più espliciti.

La pressione ricade su SDK e parchi client eterogenei

AgentCore Gateway può supportare due ere del protocollo, ma ogni organizzazione deve dimostrare che i propri client negoziano quella corretta.

L'obiettivo immediato della pressione non è un'API nascosta dietro il gateway. È il software client che si connette all'endpoint MCP.

Un client che dichiara la revisione 2026-07-28 deve inviare la versione del protocollo e le proprie capacità in ogni richiesta. Deve comprendere server/discover, i tipi di risultato richiesti e la gestione rivista delle interazioni in più passaggi.

I client HTTP devono inoltre utilizzare gli header standard delle richieste MCP, inclusi Mcp-Method e Mcp-Name. Questi header consentono all'infrastruttura di ispezionare e instradare il traffico senza analizzare ogni corpo JSON-RPC.

Questa modifica è utile per gateway, sistemi di osservabilità e controlli di sicurezza. Crea inoltre un ulteriore punto di convalida in cui client incompleti possono fallire prima che uno strumento venga eseguito.

MCP definisce errori specifici per questo nuovo confine. Le incongruenze degli header utilizzano il codice -32020, le capacità client richieste mancanti utilizzano -32021 e le versioni del protocollo non supportate utilizzano -32022.

Questi codici offrono ai team della piattaforma una tassonomia degli errori più chiara. Un aumento delle risposte -32022 indica problemi di negoziazione della versione, mentre -32020 segnala un disaccordo tra gli header HTTP e la richiesta inclusa.

La transizione degli SDK non avverrà simultaneamente tra i vari linguaggi. Le implementazioni ufficiali possono adottare una specifica stabile secondo tempistiche diverse e le applicazioni spesso bloccano le versioni delle librerie molto tempo dopo l'arrivo di una nuova release.

Le aziende hanno inoltre client che non controllano completamente. Un dipendente potrebbe utilizzare un assistente desktop approvato, un agent da riga di comando interno e un'estensione IDE sviluppata da un altro team. Ognuno potrebbe negoziare MCP in modo diverso.

L'elenco delle versioni supportate da AgentCore offre un ponte per questo parco eterogeneo. Il gateway può pubblicizzare più di una revisione anziché costringere tutti i client ad adottare contemporaneamente il nuovo formato wire.

Quel supporto dovrebbe essere considerato un meccanismo di migrazione, non una prova di comportamento identico. Le funzionalità rimosse dal core 2026 esistono ancora nei flussi di protocollo più vecchi. Un test che passa dopo aver negoziato una revisione precedente dice poco sul percorso stateless.

Roots, Sampling e Logging sono ora deprecati anziché essere rimossi immediatamente dall'intera specifica. Le nuove implementazioni dovrebbero evitarne l'adozione, mentre quelle esistenti ricevono un periodo di transizione definito.

La nuova policy sul ciclo di vita delle funzionalità di MCP stabilisce una finestra minima di deprecazione di 12 mesi. Questo cambiamento di governance offre agli implementatori un preavviso più prevedibile rispetto a un linguaggio di deprecazione informale.

Il protocollo suggerisce alternative. Le applicazioni possono passare directory tramite parametri degli strumenti o identificatori di risorse anziché usare Roots. I server possono chiamare direttamente le API dei provider di modelli anziché fare affidamento su Sampling. Le implementazioni possono usare OpenTelemetry o flussi di errore standard anziché il Logging del protocollo.

Queste sostituzioni cambiano l'architettura, non soltanto la sintassi. Un server che in precedenza richiedeva il sampling del modello tramite il proprio client MCP potrebbe aver bisogno di un'integrazione diretta con il provider, credenziali separate e una nuova policy di controllo dei costi.

La pressione si estende quindi ai team di sicurezza e finanza. Spostare l'accesso al modello da una capacità del client al server cambia dove risiedono le credenziali e dove viene registrato l'utilizzo.

I responsabili dei gateway dovrebbero classificare i client in tre gruppi. Il primo supporta pienamente la revisione 2026. Il secondo funziona solo con una versione stabile precedente. Il terzo presenta un comportamento non chiaro e necessita di isolamento fino al completamento dei test.

I test dovrebbero coprire più di tools/list. Una matrice utile include individuazione, chiamate agli strumenti autenticate, scope rifiutati, streaming delle risposte, richieste interrotte, caching degli elenchi e applicazioni che richiedono ulteriori input dell'utente.

I team dovrebbero inoltre verificare la versione negoziata nella telemetria. Senza questo segnale, una richiesta riuscita potrebbe nascondere un downgrade inatteso al protocollo precedente.

La migrazione ha successo quando il nuovo percorso gestisce carichi di lavoro di produzione rappresentativi. Non ha successo semplicemente perché il gateway accetta un campo supportedVersions aggiornato.

L'autorizzazione diventa più rigorosa mentre le estensioni escono dal core

MCP 2026-07-28 riduce l'ambiguità delle credenziali, trasferendo al contempo le capacità opzionali in un sistema di estensioni governato e negoziato.

Le regole di autorizzazione riviste si concentrano sui confini di identità che diventano rischiosi quando gli agenti si connettono a molti server. Un client MCP può ottenere credenziali da diversi server di autorizzazione, ciascuno a protezione di strumenti e dati differenti.

La specifica ora afferma che i client devono associare le credenziali archiviate all'emittente che le ha create. Un client non deve riutilizzare le credenziali con un altro server di autorizzazione e deve registrarsi nuovamente quando cambia l'emittente.

Questa regola affronta la confusione delle credenziali. Nomi di server simili, reindirizzamenti o metadati in cambiamento non dovrebbero far sì che le credenziali client di un servizio vengano trasferite a un altro confine di autorizzazione.

I server di autorizzazione dovrebbero inoltre includere un valore iss nelle loro risposte di autorizzazione. Quando questo campo è presente, i client devono convalidarlo rispetto all'emittente registrato prima di scambiare il codice di autorizzazione.

Questa convalida segue RFC 9207, uno standard dell'Internet Engineering Task Force progettato per prevenire attacchi di mix-up dei server di autorizzazione. Il controllo è importante quando un client interagisce con più emittenti o rileva dinamicamente i metadati di autorizzazione.

Anche la registrazione dinamica dei client riceve indicazioni più rigorose. I client MCP devono specificare un tipo di applicazione appropriato, riducendo i conflitti relativi alle regole sugli URI di reindirizzamento per applicazioni native e web.

Questi requisiti non rendono automaticamente sicura ogni distribuzione. Le opzioni degli SDK richiedono comunque una configurazione corretta, i record delle credenziali archiviate necessitano di una corretta gestione delle chiavi e i provider di identità devono restituire informazioni coerenti sull'emittente.

AgentCore Gateway offre un utile punto di applicazione perché può autenticare i chiamanti in ingresso e gestire separatamente le credenziali in uscita. La documentazione AWS afferma che il servizio supporta l'autorizzazione personalizzata tramite JSON Web Token, AWS Identity and Access Management e altre modalità di autorizzazione configurate.

Questa separazione è essenziale. L'identità autorizzata a invocare un gateway non dovrebbe ricevere automaticamente credenziali senza restrizioni per ogni destinazione dietro di esso.

AgentCore può inoltre associare un motore di policy a un gateway. Il motore valuta le chiamate agli strumenti dell'agente e decide se ciascuna azione è consentita o negata in base alle policy configurate.

Il modello di gateway non elimina la necessità del privilegio minimo. Una credenziale di destinazione con scope ampio rimane tale anche quando è archiviata in un servizio di identità gestito.

I team dovrebbero testare i casi negativi con la stessa attenzione riservata alle chiamate riuscite. Un client con scope insufficiente dovrebbe ricevere una risposta di autorizzazione controllata, non un errore di protocollo non correlato o accesso a uno strumento adiacente.

Il sistema di estensioni introduce un cambiamento parallelo nella governance. Le funzionalità opzionali possono ora svilupparsi al di fuori del protocollo core, utilizzando al contempo identificatori standardizzati, dichiarazioni di capacità e negoziazione.

Nel framework delle estensioni, gli identificatori ufficiali usano il prefisso io.modelcontextprotocol. Le terze parti dovrebbero usare un dominio inverso di loro proprietà, riducendo le collisioni tra funzionalità non correlate.

I client dichiarano le estensioni supportate nelle proprie capacità per richiesta. I server dichiarano le proprie tramite server/discover. Entrambe le parti devono aderire esplicitamente e le estensioni restano disabilitate per impostazione predefinita.

Le estensioni ufficiali includono Tasks asincroni, MCP Apps interattive, credenziali client OAuth e autorizzazione gestita a livello aziendale. Il core non deve più assorbire ogni funzionalità specializzata prima che gli implementatori possano utilizzarla.

Questa struttura può limitare la complessità del core. Crea inoltre una matrice di supporto che i team di piattaforma devono monitorare tra client, server, gateway e versioni degli SDK.

Un client che supporta un'estensione di interfaccia interattiva dovrebbe comunque gestire una risposta testuale significativa quando il server può degradare in modo corretto. Un server che richiede una particolare estensione di autorizzazione può invece rifiutare un client incompatibile.

Il primo obbligo di AgentCore Gateway è un comportamento corretto del protocollo core. Il supporto per la revisione 2026 non dovrebbe essere interpretato come supporto universale per ogni estensione presente o futura.

Questa è un'incertezza chiave nell'annuncio di AWS. Il gateway può trasportare informazioni sulle capacità delle estensioni, ma i clienti necessitano di documentazione esplicita e test per qualunque estensione da cui dipenda il loro flusso di lavoro.

Le modifiche all'autorizzazione e il framework delle estensioni condividono un principio. Le assunzioni nascoste stanno diventando esplicite, sia che riguardino gli emittenti delle credenziali, le capacità del client o il comportamento opzionale.

Questa esplicitazione è positiva per il controllo aziendale. Significa anche che una configurazione incompleta fallirà in modo più evidente rispetto a quanto avveniva con un'integrazione permissiva.

Cosa devono ancora dimostrare i clienti Amazon AWS

I prossimi tre segnali sono la telemetria della versione negoziata, la qualità dei fallimenti di autorizzazione e il supporto delle estensioni sotto carichi di lavoro reali.

Il primo segnale è se i client di produzione negoziano effettivamente MCP 2026-07-28. La sola configurazione del gateway non può rispondere a questa domanda.

I team dovrebbero monitorare i metadati delle richieste e gli errori relativi al protocollo dopo un rollout graduale. Dovrebbero confrontare i risultati per nome del client, versione del client, framework e canale di distribuzione.

Una diminuzione degli errori relativi a versioni non supportate e mancata corrispondenza degli header rafforzerebbe il caso della migrazione gestita da AWS. Errori persistenti mostrerebbero che l'adozione degli SDK client, non la disponibilità del gateway, rimane il collo di bottiglia.

I downgrade meritano la stessa attenzione. Un client che torna silenziosamente a una revisione precedente può mantenere operativo un flusso di lavoro nascondendo al contempo un problema di migrazione irrisolto.

Le organizzazioni dovrebbero definire la revisione prevista per ogni client testato. Gli avvisi possono quindi distinguere un fallback di compatibilità approvato da un downgrade involontario.

Il secondo segnale è il comportamento dei fallimenti di autorizzazione tra più provider di identità e destinazioni. I team devono testare cambiamenti dell'emittente, valori iss non validi, token scaduti, scope insufficienti e tentativi di riutilizzo delle credenziali.

L'esito più sicuro è un rifiuto preciso prima dell'esecuzione della destinazione. I log dovrebbero identificare la policy o il confine di autorizzazione coinvolto senza esporre segreti al chiamante.

Test negativi puliti sosterrebbero l'affermazione secondo cui AgentCore riduce il lavoro di sicurezza personalizzato. Fallimenti confusi o una gestione incoerente dell'emittente la indebolirebbero, soprattutto per i gateway che coprono diverse unità aziendali.

Il terzo segnale è l'interoperabilità delle estensioni. Un flusso di lavoro che usa Tasks, MCP Apps o un'estensione di autorizzazione dovrebbe verificare le capacità prima di invocare comportamenti specifici dell'estensione.

I test devono includere una degradazione corretta. Un client privo di supporto UI dovrebbe comunque ricevere contenuti core utili quando il server promette un fallback.

Anche il caso opposto è importante. Se un'estensione è obbligatoria per un funzionamento sicuro, il server dovrebbe rifiutare chiaramente la richiesta anziché tentare un flusso di lavoro parziale.

Sotto queste tre priorità vi sono segnali operativi più ampi. I team dovrebbero osservare le chiamate con effetti collaterali interrotte per rilevare azioni duplicate, poiché la nuova revisione rimuove la ripresa dello stream.

Dovrebbero inoltre esaminare il caching. I risultati degli elenchi e delle risorse ora includono ttlMs, un'indicazione di freschezza misurata in millisecondi, e cacheScope, che distingue la memorizzabilità nella cache pubblica da quella privata.

L'ordinamento deterministico degli strumenti può migliorare la cache lato client e quella dei prompt del modello. Tuttavia, descrizioni degli strumenti obsolete possono indurre un agente a chiamare uno schema non aggiornato, quindi il comportamento della cache deve essere testato durante gli aggiornamenti delle destinazioni.

L'osservabilità dovrebbe includere il contesto di tracing distribuito. La specifica documenta convenzioni _meta per traceparent, tracestate e baggage, aiutando i team a seguire il lavoro tra client, gateway e destinazioni.

Questo tracing diventa particolarmente utile durante i tentativi. Gli operatori devono collegare lo stream originale fallito alla richiesta emessa nuovamente senza trattarli come un unico ID di richiesta JSON-RPC.

Il valore più forte del gateway gestito emerge quando queste esigenze convergono. Un unico endpoint può autenticare i chiamanti, applicare policy, tradurre il traffico di protocollo, selezionare strumenti, inserire le credenziali di destinazione e produrre evidenze di audit.

Anche il suo rischio principale emerge in quel punto. Un gateway diventa un punto di controllo ad alta leva, quindi un errore di configurazione può influire contemporaneamente su molti agenti e servizi.

Un rollout accurato dovrebbe iniziare con un gateway non critico o una coorte limitata di client. I team possono aggiungere la nuova versione supportata, attendere lo stato pronto ed eseguire una suite di test specifica per versione.

La fase successiva dovrebbe introdurre flussi di lavoro stateful rappresentativi utilizzando handle espliciti. Dovrebbe includere una richiesta interrotta e un effetto collaterale ritentato in sicurezza.

I test di autorizzazione dovrebbero seguire con chiamate sia riuscite sia negate. I flussi di lavoro dipendenti dalle estensioni dovrebbero essere introdotti per ultimi, dopo che il comportamento del protocollo core è stabile.

La pianificazione del rollback resta necessaria. Mantenere la precedente revisione stabile nell'elenco delle versioni supportate offre ai client compatibili un fallback mentre i team analizzano i difetti.

Tuttavia, il fallback non dovrebbe diventare un'ambiguità permanente. Le organizzazioni hanno bisogno di una data per riesaminare i client più vecchi ancora presenti e di un piano per le funzionalità deprecate che utilizzano ancora.

Gli sviluppatori dovrebbero interessarsene perché la revisione cambia dove collocano lo stato e come eseguono i tentativi. I team di piattaforma dovrebbero interessarsene perché la compatibilità diventa osservabile al confine del gateway.

Gli acquirenti aziendali dovrebbero interessarsene perché il supporto gestito del protocollo può ridurre l'infrastruttura duplicata. Dovrebbero comunque chiedere quali estensioni, SDK, regioni, configurazioni di identità e tipi di destinazione hanno completato la convalida in produzione.

I knowledge worker sperimenteranno il risultato in modo indiretto. I loro assistenti potrebbero connettersi a più strumenti con un minor numero di errori di connessione, ma solo se identità e consenso restano chiari tra tali strumenti.

Amazon AWS ha reso insolitamente ridotta la prima azione di migrazione. La questione più importante è se i team possano rendere ogni richiesta autonoma senza perdere sicurezza, compatibilità o visibilità.

Nel corso dei prossimi uno-tre mesi, osservate i dati sulle versioni negoziate, la qualità dei rifiuti di autorizzazione e la conformità delle estensioni nei principali SDK. Questi segnali mostreranno se MCP stateless è diventato uno standard di produzione o resta una funzionalità del gateway in attesa dei suoi client.

Per i team che già utilizzano AgentCore Gateway, il prossimo passo pratico è un audit di compatibilità controllato. Aggiornate un gateway, testate ogni client supportato, registrate la revisione negoziata e forzate i casi di errore prima di ampliare l'accesso.

Queste evidenze contano più dell'apparente semplicità di una chiamata API. Amazon AWS ora fornisce il ponte verso MCP 2026-07-28, ma ogni organizzazione deve dimostrare che i propri agenti possano attraversarlo in sicurezza.