Amazon AWS Apoia MCP Sem Estado, mas Compatibilidade Agora É o Verdadeiro Teste

A Amazon AWS adicionou suporte ao MCP 2026-07-28 ao AgentCore Gateway dois dias depois de a maior revisão arquitetural da especificação chegar à versão estável. Uma chamada UpdateGateway pode habilitar a nova versão do protocolo em um gateway existente. No entanto, essa simples mudança no plano de controle esconde uma transição mais difícil para clientes, servidores e equipes de segurança empresarial.

A nova revisão do Model Context Protocol remove as sessões no nível do protocolo e faz com que cada solicitação descreva sua própria versão e capacidades do cliente. O MCP é um padrão aberto para conectar aplicações de IA a ferramentas, fontes de dados e outros serviços. Seu design sem estado deve facilitar o escalonamento, o roteamento e a recuperação dos gateways.

Esse benefício vem acompanhado de um teste de compatibilidade. Os clientes precisam adotar novos metadados de solicitação, os servidores devem implementar descoberta, e as antigas premissas de sessão deixam de valer. O Amazon Bedrock AgentCore Gateway agora se posiciona entre essas duas eras do protocolo, traduzindo serviços empresariais em ferramentas MCP enquanto aplica controles de acesso em um endpoint gerenciado.

A história real, portanto, é maior do que uma caixa de seleção de versão. A Amazon AWS aposta que um gateway gerenciado pode absorver a evolução do protocolo antes que ela alcance cada equipe de aplicações. Se isso funcionará depende da negociação de versões, da correção da autorização e do comportamento de frotas mistas de clientes.

Amazon AWS Transforma uma Grande Reescrita do MCP em Uma Atualização de Gateway

A AWS reduziu a etapa de infraestrutura a uma operação de API, mas as aplicações ainda precisam falar corretamente o protocolo revisado.

Os mantenedores do MCP lançaram a especificação estável 2026-07-28 em 28 de julho, após um período de release candidate que começou em maio. A versão estável do MCP substitui diversas premissas estabelecidas durante o crescimento inicial do protocolo.

A AWS seguiu com suporte no Amazon Bedrock AgentCore Gateway. Segundo a atualização do AgentCore da empresa, os proprietários de gateways podem adicionar a nova revisão por meio do UpdateGateway. A solicitação atualiza a configuração do protocolo MCP do gateway e sua lista de versões compatíveis.

O objeto relevante do plano de controle é protocolConfiguration.mcp.supportedVersions. A AWS documenta esse campo como uma matriz de versões do MCP que o gateway pode usar. O UpdateGateway retorna o status HTTP 202 quando o serviço aceita uma atualização, após o qual o gateway passa por um estado de atualização.

Essa distinção importa do ponto de vista operacional. Uma chamada aceita não significa que todos os clientes conectados concluíram uma solicitação com sucesso. As equipes devem esperar até que o gateway retorne ao estado pronto e, então, executar testes de conformidade e de carga de trabalho no endpoint real.

A mudança não exige que as organizações reconstruam todas as funções Lambda, serviços OpenAPI ou serviços Smithy por trás do gateway. O AgentCore Gateway já converte esses recursos em ferramentas compatíveis com MCP. Ele também oferece suporte a destinos MCP remotos e a outros serviços HTTP, dependendo da configuração do destino.

Essa arquitetura permite que a AWS altere a camada voltada ao protocolo sem exigir mudanças idênticas em cada serviço empresarial downstream. Uma API de atendimento ao cliente pode continuar sendo uma API, por exemplo, enquanto o gateway expõe suas operações como ferramentas para agentes compatíveis.

O AgentCore Gateway também lida com autenticação de entrada, credenciais de saída, descoberta de ferramentas, roteamento e aplicação de políticas. Esses controles se tornam mais valiosos quando um único endpoint atende serviços de várias equipes internas.

Ainda assim, a chamada UpdateGateway altera apenas o suporte declarado do gateway. Um cliente que usa a revisão de 2026 ainda precisa enviar os metadados e cabeçalhos exigidos. Um cliente mais antigo precisa negociar uma revisão mutuamente compatível ou usar um caminho de fallback compatível.

Essa é a primeira limitação por trás da mensagem simples de atualização da AWS. O serviço gerenciado pode reduzir o trabalho de plataforma, mas não pode fazer um SDK desatualizado emitir um novo formato de comunicação.

A segunda limitação envolve testes. Os proprietários de gateways precisam verificar listagem de ferramentas, chamadas de ferramentas, falhas de autenticação, comportamento de streaming e controles de cache em cada versão compatível. O sucesso com um cliente moderno não comprova compatibilidade em toda uma frota empresarial.

Portanto, uma implementação prática começa com um inventário. As equipes precisam identificar quais aplicações de agentes se conectam ao gateway, quais versões de SDK usam e se esses SDKs oferecem suporte ao MCP 2026-07-28.

Organizações que mantêm decisões técnicas e evidências de testes em uma base de conhecimento de engenharia pesquisável podem registrar resultados por cliente e versão de protocolo. Esse registro se torna importante quando uma falha aparece apenas em um framework ou canal de implantação.

A AWS tornou pequena a ação no plano de controle. A verificação no nível da aplicação continua sendo o verdadeiro projeto de migração.

Por Que o MCP Sem Estado Muda a Equação do Gateway

O MCP sem estado leva as informações de compatibilidade para cada solicitação, simplificando o roteamento horizontal enquanto obriga cada mensagem a se sustentar por si só.

Revisões anteriores do MCP usavam uma troca de inicialização para estabelecer detalhes e capacidades do protocolo. Um cliente enviava initialize, o servidor respondia, e o cliente concluía a sequência com notifications/initialized. O HTTP com streaming também podia usar um cabeçalho Mcp-Session-Id para associar o tráfego posterior a uma sessão no nível do protocolo.

As principais mudanças do MCP removem esse ciclo de vida na nova revisão. Elas também removem o identificador de sessão no nível do protocolo. Servidores que precisam manter estado entre chamadas devem emitir identificadores explícitos que os clientes passam como argumentos regulares de ferramentas.

Cada nova solicitação no estilo revisado carrega sua versão de protocolo e capacidades do cliente dentro de _meta. Os clientes também devem se identificar ali. Os servidores retornam sua identidade nos metadados do resultado, tornando cada troca mais autodescritiva.

Um novo método server/discover permite que um cliente inspecione versões compatíveis, capacidades e a identidade do servidor antes de iniciar outras tarefas. Um servidor que usa a revisão 2026-07-28 deve implementar essa chamada de procedimento remoto.

Esse design muda o que um gateway precisa lembrar. Ele não precisa mais depender de uma troca de inicialização concluída por meio de uma conexão nem associar o tráfego posterior do protocolo a uma sessão MCP opaca.

Um balanceador de carga pode rotear solicitações separadas sem preservar afinidade no nível do protocolo. Uma instância do gateway que recebe a décima chamada pode inspecionar as mesmas informações essenciais de compatibilidade que a primeira instância recebeu.

Esse modelo combina com um gateway de nuvem gerenciado. Serviços sem estado podem escalar entre workers, substituir capacidade não saudável e distribuir tráfego sem restaurar um registro de sessão MCP antes de interpretar cada solicitação.

Ele também reduz uma incompatibilidade desconfortável entre infraestrutura de nuvem de curta duração e comportamento de protocolo orientado à conexão. Funções serverless e gateways distribuídos geralmente funcionam melhor quando as solicitações contêm as informações necessárias para processamento independente.

No entanto, sem estado não significa que o trabalho do agente não tenha estado. Um fluxo de compras ainda pode exigir informações de aprovação, uma referência de transação ou dados coletados durante uma interação anterior. A especificação transfere esse estado para identificadores explícitos no nível da aplicação, em vez de ocultá-lo na sessão de transporte.

Essa mudança pode melhorar a visibilidade. Argumentos de ferramentas e identificadores emitidos pelo servidor criam limites de propriedade mais claros do que o estado inferido a partir de uma conexão. Eles também exigem um projeto cuidadoso porque os clientes podem repetir solicitações ou apresentar identificadores antigos.

A nova revisão elimina a retomada do HTTP com streaming por meio de Last-Event-ID e identificadores de eventos enviados pelo servidor. Se um fluxo de resposta for interrompido durante uma solicitação, o cliente deverá enviar uma nova solicitação com um novo ID de solicitação.

Essa regra cria uma questão operacional importante. Se uma ferramenta executar um efeito colateral antes de o fluxo falhar, uma nova tentativa cega poderá repetir a ação, a menos que a aplicação implemente idempotência.

Considere um agente que cria um ticket de suporte. O serviço de tickets pode armazenar o registro com sucesso enquanto o fluxo de resposta desaparece. Uma nova tentativa deve incluir uma chave de idempotência no nível da aplicação ou consultar a operação anterior antes de criar outro ticket.

A AWS não pode resolver todos os problemas de idempotência downstream no limite do protocolo. Logs e rastreamentos do gateway podem mostrar as chamadas repetidas, mas o serviço de destino deve definir um comportamento seguro para novas tentativas.

A revisão também substitui chamadas separadas iniciadas pelo servidor por solicitações de múltiplas idas e voltas. Nesse padrão, um servidor retorna um resultado input_required descrevendo as informações de que ainda precisa. O cliente repete a solicitação original com as respostas solicitadas.

Essa abordagem mantém o controle dentro de uma sequência de solicitação e nova tentativa. Ela evita que uma solicitação independente do servidor para o cliente chegue por uma conexão que outra instância do gateway talvez não possua.

Todos os resultados agora incluem um resultType, normalmente complete ou input_required. Clientes que se comunicam com servidores mais antigos devem tratar um valor omitido como resultado concluído, preservando uma ponte limitada de compatibilidade.

O mecanismo claramente favorece infraestrutura distribuída. A contrapartida é que SDKs e aplicações precisam adotar metadados, lógica de novas tentativas e tratamento de estado mais explícitos.

A Pressão Recai sobre SDKs e Frotas Mistas de Clientes

O AgentCore Gateway pode oferecer suporte a duas eras do protocolo, mas cada organização precisa comprovar que seus clientes negociam a versão correta.

O alvo imediato da pressão não é uma API oculta por trás do gateway. É o software cliente que se conecta ao endpoint MCP.

Um cliente que declara a revisão 2026-07-28 deve enviar a versão do protocolo e suas capacidades em cada solicitação. Ele deve entender server/discover, os tipos de resultado exigidos e o tratamento revisado de interações em múltiplas etapas.

Os clientes HTTP também devem usar cabeçalhos de solicitação MCP padrão, incluindo Mcp-Method e Mcp-Name. Esses cabeçalhos permitem que a infraestrutura inspecione e roteie o tráfego sem analisar cada corpo JSON-RPC.

Essa mudança é útil para gateways, sistemas de observabilidade e controles de segurança. Ela também cria outro ponto de validação no qual clientes incompletos podem falhar antes de uma ferramenta ser executada.

O MCP define erros específicos para essa nova fronteira. Incompatibilidades de cabeçalho usam o código -32020, capacidades obrigatórias ausentes do cliente usam -32021, e versões de protocolo não compatíveis usam -32022.

Esses códigos oferecem às equipes de plataforma uma taxonomia de falhas mais clara. Um aumento nas respostas -32022 indica problemas de negociação de versão, enquanto -32020 aponta para divergência entre cabeçalhos HTTP e a solicitação incluída.

A transição dos SDKs não acontecerá simultaneamente em todas as linguagens. Implementações oficiais podem adotar uma especificação estável em cronogramas diferentes, e as aplicações frequentemente fixam versões de bibliotecas muito tempo depois de uma nova versão surgir.

As empresas também possuem clientes que não controlam totalmente. Um funcionário pode usar um assistente de desktop aprovado, um agente interno de linha de comando e uma extensão de IDE criada por outra equipe. Cada um pode negociar o MCP de maneira diferente.

A lista de versões compatíveis do AgentCore oferece uma ponte para essa frota mista. O gateway pode anunciar mais de uma revisão, em vez de forçar todos os clientes a adotar de uma vez o novo formato de comunicação.

Esse suporte deve ser tratado como um mecanismo de migração, não como prova de comportamento idêntico. Recursos removidos do núcleo de 2026 ainda existem em fluxos de protocolo mais antigos. Um teste que passa após negociar uma revisão anterior diz pouco sobre o caminho sem estado.

Roots, Sampling e Logging agora estão obsoletos, em vez de serem removidos imediatamente de toda a especificação. Novas implementações devem evitar adotá-los, enquanto as implementações existentes recebem um período de transição definido.

A nova política de ciclo de vida de recursos do MCP estabelece uma janela mínima de 12 meses para descontinuação. Essa mudança de governança dá aos implementadores um aviso mais previsível do que uma linguagem informal de descontinuação.

O protocolo sugere alternativas. As aplicações podem passar diretórios por parâmetros de ferramentas ou identificadores de recursos em vez de Roots. Os servidores podem chamar APIs de provedores de modelos diretamente em vez de depender de Sampling. As implementações podem usar OpenTelemetry ou fluxos de erro padrão em vez de Logging do protocolo.

Essas substituições mudam a arquitetura, não apenas a sintaxe. Um servidor que antes solicitava amostragem de modelo por meio de seu cliente MCP pode precisar de uma integração direta com o provedor, credenciais separadas e uma nova política de controle de custos.

A pressão, portanto, se estende às equipes de segurança e finanças. Transferir o acesso ao modelo de uma capacidade do cliente para o servidor muda onde as credenciais ficam e onde o uso é registrado.

Os responsáveis pelos gateways devem classificar os clientes em três grupos. O primeiro oferece suporte completo à revisão de 2026. O segundo funciona apenas com uma versão estável anterior. O terceiro tem comportamento incerto e precisa ser isolado até que os testes sejam concluídos.

Os testes devem cobrir mais do que tools/list. Uma matriz útil inclui descoberta, chamadas de ferramentas autenticadas, escopos rejeitados, streaming de respostas, solicitações interrompidas, cache de listas e aplicações que exigem entrada adicional do usuário.

As equipes também devem verificar a versão negociada na telemetria. Sem esse sinal, uma solicitação bem-sucedida pode esconder um downgrade inesperado para o protocolo anterior.

A migração é bem-sucedida quando o novo caminho suporta cargas de trabalho de produção representativas. Ela não é bem-sucedida apenas porque o gateway aceita um campo supportedVersions atualizado.

A Autorização se Torna Mais Rigorosa à Medida que as Extensões Saem do Núcleo

MCP 2026-07-28 reduz a ambiguidade das credenciais enquanto move recursos opcionais para um sistema de extensões governado e negociado.

As regras de autorização revisadas se concentram em limites de identidade que se tornam arriscados quando agentes se conectam a muitos servidores. Um cliente MCP pode obter credenciais de vários servidores de autorização, cada um protegendo ferramentas e dados diferentes.

A especificação agora determina que os clientes devem vincular as credenciais armazenadas ao emissor que as criou. Um cliente não deve reutilizar credenciais com outro servidor de autorização e deve se registrar novamente quando o emissor mudar.

Essa regra aborda a confusão de credenciais. Nomes de servidor semelhantes, redirecionamentos ou metadados em mudança não devem fazer com que as credenciais de cliente de um serviço atravessem para outro limite de autorização.

Os servidores de autorização também devem incluir um valor iss em suas respostas de autorização. Quando esse campo estiver presente, os clientes deverão validá-lo em relação ao emissor registrado antes de trocar o código de autorização.

Essa validação segue a RFC 9207, um padrão da Internet Engineering Task Force projetado para evitar ataques de confusão de servidores de autorização. A verificação é importante quando um cliente interage com vários emissores ou descobre metadados de autorização dinamicamente.

O registro dinâmico de clientes também recebe orientações mais rigorosas. Os clientes MCP devem especificar um tipo de aplicação apropriado, reduzindo conflitos em torno das regras de URI de redirecionamento para aplicações nativas e web.

Esses requisitos não tornam automaticamente segura toda implantação. As opções dos SDKs ainda precisam da configuração correta, os registros de credenciais armazenadas exigem indexação adequada e os provedores de identidade precisam retornar informações consistentes sobre o emissor.

O AgentCore Gateway oferece um ponto de aplicação útil porque pode autenticar chamadores de entrada e gerenciar credenciais de saída separadamente. A documentação da AWS afirma que o serviço oferece suporte à autorização personalizada por JSON Web Token, AWS Identity and Access Management e outros modos de autorização configurados.

Essa separação é essencial. A identidade autorizada a invocar um gateway não deve receber automaticamente credenciais irrestritas para todos os destinos por trás dele.

O AgentCore também pode associar um mecanismo de políticas a um gateway. O mecanismo avalia chamadas de ferramentas feitas por agentes e decide se cada ação é permitida ou negada de acordo com as políticas configuradas.

O modelo de gateway não elimina a necessidade do princípio do menor privilégio. Uma credencial de destino com escopo amplo continua tendo escopo amplo, mesmo quando armazenada em um serviço de identidade gerenciado.

As equipes devem testar casos negativos com o mesmo cuidado dedicado às chamadas bem-sucedidas. Um cliente com escopo insuficiente deve receber uma resposta de autorização controlada, não um erro de protocolo não relacionado nem acesso a uma ferramenta vizinha.

O sistema de extensões cria uma mudança de governança paralela. Recursos opcionais agora podem evoluir fora do protocolo central, usando identificadores padronizados, declarações de capacidades e negociação.

No framework de extensões, os identificadores oficiais usam o prefixo io.modelcontextprotocol. Terceiros devem usar um domínio invertido que possuam, o que reduz colisões entre recursos não relacionados.

Os clientes anunciam extensões compatíveis dentro de suas capacidades por solicitação. Os servidores anunciam as suas por meio de server/discover. Ambos os lados devem aderir explicitamente, e as extensões permanecem desativadas por padrão.

As extensões oficiais incluem Tasks assíncronas, MCP Apps interativos, credenciais de cliente OAuth e autorização gerenciada pela empresa. O núcleo não precisa mais absorver cada recurso especializado antes que os implementadores possam usá-lo.

Essa estrutura pode limitar a complexidade do núcleo. Também cria uma matriz de suporte que as equipes de plataforma precisam acompanhar entre clientes, servidores, gateways e versões de SDKs.

Um cliente que oferece suporte a uma extensão de interface interativa ainda deve lidar com uma resposta de texto significativa quando o servidor puder degradar graciosamente. Um servidor que exige uma extensão de autorização específica pode, em vez disso, rejeitar um cliente incompatível.

A primeira obrigação do AgentCore Gateway é o comportamento correto do protocolo central. O suporte à revisão de 2026 não deve ser interpretado como suporte universal a toda extensão atual ou futura.

Essa é uma incerteza importante no anúncio da AWS. O gateway pode transportar informações sobre capacidades de extensões, mas os clientes precisam de documentação e testes explícitos para qualquer extensão da qual seu fluxo de trabalho dependa.

As mudanças de autorização e o framework de extensões compartilham um princípio. Suposições ocultas estão se tornando explícitas, sejam elas sobre emissores de credenciais, capacidades do cliente ou comportamento opcional.

Essa explicitação é positiva para o controle empresarial. Também significa que configurações incompletas falharão de forma mais visível do que em uma integração permissiva.

O Que os Clientes da Amazon AWS Ainda Precisam Comprovar

Os próximos três sinais são a telemetria de versão negociada, a qualidade das falhas de autorização e o suporte a extensões sob cargas de trabalho reais.

O primeiro sinal é se os clientes de produção realmente negociam MCP 2026-07-28. A configuração do gateway, por si só, não pode responder a essa pergunta.

As equipes devem monitorar metadados de solicitações e erros relacionados ao protocolo após uma implementação gradual. Elas devem comparar os resultados por nome do cliente, versão do cliente, framework e canal de implantação.

Uma queda na taxa de erros de versão não compatível e de incompatibilidade de cabeçalhos reforçaria o argumento de migração gerenciada da AWS. Erros persistentes mostrariam que a adoção de SDKs de cliente, e não a disponibilidade do gateway, continua sendo o gargalo.

Os downgrades merecem atenção equivalente. Um cliente que recua silenciosamente para uma revisão anterior pode manter um fluxo de trabalho em execução enquanto esconde um problema de migração não resolvido.

As organizações devem definir a revisão esperada para cada cliente testado. Os alertas podem então distinguir uma alternativa de compatibilidade aprovada de um downgrade não intencional.

O segundo sinal é como as falhas de autorização se comportam entre vários provedores de identidade e destinos. As equipes precisam testar mudanças de emissor, valores iss inválidos, tokens expirados, escopos insuficientes e tentativas de reutilização de credenciais.

O resultado mais seguro é uma negação precisa antes que o destino seja executado. Os logs devem identificar a política ou o limite de autorização envolvido sem expor segredos ao chamador.

Testes negativos claros apoiariam a alegação de que o AgentCore reduz o trabalho personalizado de segurança. Falhas confusas ou tratamento inconsistente do emissor a enfraqueceriam, especialmente para gateways que abrangem várias unidades de negócio.

O terceiro sinal é a interoperabilidade das extensões. Um fluxo de trabalho que usa Tasks, MCP Apps ou uma extensão de autorização deve verificar as capacidades antes de invocar comportamento específico de extensão.

Os testes devem incluir degradação graciosa. Um cliente sem suporte a UI ainda deve receber conteúdo central útil quando o servidor promete uma alternativa.

O caso oposto também importa. Se uma extensão for obrigatória para uma operação segura, o servidor deverá rejeitar a solicitação claramente, em vez de tentar um fluxo de trabalho parcial.

Há sinais operacionais mais amplos por trás dessas três prioridades. As equipes devem observar chamadas interrompidas com efeitos colaterais em busca de ações duplicadas, porque a nova revisão remove a capacidade de retomar streams.

Elas também devem examinar o cache. Os resultados de listas e recursos agora incluem ttlMs, uma indicação de atualização medida em milissegundos, e cacheScope, que separa a capacidade de cache pública da privada.

A ordenação determinística de ferramentas pode melhorar o cache no lado do cliente e em prompts de modelo. No entanto, descrições de ferramentas desatualizadas podem fazer um agente chamar um esquema ultrapassado, portanto o comportamento de cache precisa ser testado durante atualizações de destino.

A observabilidade deve incluir contexto de rastreamento distribuído. A especificação documenta convenções de _meta para traceparent, tracestate e baggage, ajudando as equipes a acompanhar o trabalho entre clientes, gateways e destinos.

Esse rastreamento se torna especialmente útil durante tentativas. Os operadores precisam conectar o stream original que falhou à solicitação recém-emitida sem tratá-los como um único ID de solicitação JSON-RPC.

O maior valor do gateway gerenciado aparece quando essas preocupações convergem. Um único endpoint pode autenticar chamadores, aplicar políticas, traduzir tráfego de protocolo, selecionar ferramentas, injetar credenciais de destino e produzir evidências de auditoria.

Seu principal risco também aparece nesse ponto. Um gateway se torna um ponto de controle de alto impacto, portanto um erro de configuração pode afetar muitos agentes e serviços simultaneamente.

Uma implementação cuidadosa deve começar com um gateway não crítico ou um grupo limitado de clientes. As equipes podem adicionar a nova versão compatível, aguardar o status de pronto e executar uma suíte de testes específica para a versão.

A etapa seguinte deve introduzir fluxos de trabalho com estado representativos usando handles explícitos. Ela deve incluir uma solicitação interrompida e um efeito colateral repetido com segurança.

Os testes de autorização devem seguir com chamadas bem-sucedidas e negadas. Fluxos de trabalho dependentes de extensões devem ser incluídos por último, após o comportamento do protocolo central estar estável.

O planejamento de reversão continua necessário. Manter a revisão estável anterior na lista de versões compatíveis oferece aos clientes compatíveis uma alternativa enquanto as equipes investigam defeitos.

No entanto, a alternativa não deve se tornar uma ambiguidade permanente. As organizações precisam de uma data para revisar os clientes antigos restantes e de um plano para os recursos obsoletos que ainda utilizam.

Os desenvolvedores devem se importar porque a revisão muda onde colocam o estado e como repetem tentativas. As equipes de plataforma devem se importar porque a compatibilidade se torna observável no limite do gateway.

Os compradores empresariais devem se importar porque o suporte gerenciado ao protocolo pode reduzir a infraestrutura duplicada. Ainda assim, devem perguntar quais extensões, SDKs, regiões, configurações de identidade e tipos de destino concluíram a validação em produção.

Os profissionais do conhecimento sentirão o resultado de forma indireta. Seus assistentes poderão se conectar a mais ferramentas com menos falhas de conexão, mas apenas se a identidade e o consentimento permanecerem claros em todas essas ferramentas.

A Amazon AWS tornou a primeira ação de migração excepcionalmente simples. A questão mais importante é se as equipes conseguem tornar cada solicitação autossuficiente sem perder segurança, compatibilidade ou visibilidade.

Nos próximos um a três meses, acompanhe os dados de versão negociada, a qualidade das recusas de autorização e a conformidade das extensões nos principais SDKs. Esses sinais mostrarão se o MCP sem estado se tornou um padrão de produção ou se continua sendo um recurso de gateway à espera de seus clientes.

Para as equipes que já usam o AgentCore Gateway, a próxima ação prática é uma auditoria controlada de compatibilidade. Atualize um gateway, teste todos os clientes compatíveis, registre a revisão negociada e force os casos de falha antes de ampliar o acesso.

Essas evidências importam mais do que a aparente simplicidade de uma chamada de API. A Amazon AWS agora fornece a ponte para o MCP 2026-07-28, mas cada organização precisa provar que seus agentes conseguem atravessá-la com segurança.