Como o AgentCore Gateway suporta a especificação MCP 2026-07-28

A maior revisão do MCP desde o lançamento

O Protocolo de Contexto de Modelo (MCP, na sigla em inglês) publicou sua especificação 2026-07-28 — a revisão mais abrangente e significativa desde o lançamento do protocolo. Com essa versão, o MCP passa a ser um protocolo sem estado (stateless), capaz de escalar em infraestruturas HTTP convencionais. Além da mudança no transporte, a nova versão introduz um sistema de extensões com governança formal, reforça a autorização com alinhamento mais próximo às práticas corporativas de OAuth 2.0 e OpenID Connect (OIDC), e estabelece garantias de ciclo de vida que reduzem rupturas futuras.

Para quem já utiliza o AgentCore Gateway, funcionalidade do Amazon Bedrock AgentCore, a adoção da nova versão é uma simples mudança de configuração via chamada UpdateGateway. Clientes existentes continuam funcionando exatamente como antes — não há nenhuma etapa por alvo. Se você já conhece as mudanças da especificação, pode ir direto para a seção Atualizando seu AgentCore Gateway.

O que muda com a nova especificação e por que isso importa

Esta versão contém mudanças incompatíveis com versões anteriores do protocolo MCP. A transição para o modelo sem estado é uma mudança estrutural que os mantenedores do protocolo consideram necessária para resolver desafios de escala em implantações corporativas. No entanto, a introdução de mudanças que quebram compatibilidade com novas versões não deve ser a norma daqui em diante. Para facilitar atualizações compatíveis com versões anteriores em revisões futuras, os mantenedores introduziram melhorias de governança na especificação: uma política de ciclo de vida de funcionalidades, um framework de extensões e um requisito de suíte de conformidade.

A atualização é opcional. Nada muda até que você e seus clientes ajam. O AgentCore Gateway anuncia as versões do protocolo que suporta por meio de um único campo de configuração. Clientes selecionam uma versão em cada requisição. Adicionar a versão 2026-07-28 a um gateway que também anuncia 2025-11-25 não altera nada para clientes que solicitam a versão mais antiga. Apenas um cliente que requisitar 2026-07-28 receberá o novo comportamento.

1. MCP agora é sem estado (stateless)

Nas versões anteriores do protocolo, toda interação HTTP com fluxo contínuo (Streamable HTTP) com um servidor MCP começava com um handshake de inicialização, no qual cliente e servidor trocavam versões do protocolo e capacidades. O servidor então emitia um cabeçalho Mcp-Session-Id que todas as requisições subsequentes precisavam carregar. Isso vinculava o cliente ao servidor que emitiu o identificador de sessão, exigindo sessões persistentes no balanceador de carga ou um armazenamento de sessão compartilhado para escalar horizontalmente.

Ao remover as sessões, servidores MCP remotos passam a se comportar como endpoints HTTPS padrão, escalando de forma limpa em cargas de trabalho corporativas. Os documentos de proposta de evolução do protocolo SEP-2575 e SEP-2567 removem esses requisitos da nova versão do protocolo. Com a versão 2026-07-28, cada requisição passa a carregar versão do protocolo, informações do cliente e capacidades do cliente dentro do parâmetro _meta, eliminando a necessidade do handshake de inicialização. Clientes que precisam descobrir o que um servidor suporta podem chamar o novo método server/discover a qualquer momento.

O resultado prático é que uma única chamada de ferramenta é completamente autocontida — não requer nenhum contexto de sessão anterior e pode ser roteada para qualquer instância de servidor.

A remoção da sessão de protocolo não impede suporte a aplicações com estado. Quando servidores precisam de continuidade entre chamadas, é possível seguir padrões estabelecidos para requisições HTTP, passando um ID explícito como parâmetro de ferramenta. Veja o exemplo abaixo de como criar um carrinho e adicionar itens a ele:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_basket
Content-Type: application/json
Accept: application/json,text/event-stream

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

Response:
{"jsonrpc":"2.0","id":1,
 "result":{"resultType":"complete","content":[{"type":"text","text":"Created basket bsk_a1b2c3"}],"structuredContent":{"basket_id":"bsk_a1b2c3"},"isError": false}}

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: add_item
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"add_item","arguments":{"basket_id": "bsk_a1b2c3", "sku": "shoes"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

O AgentCore Gateway sempre protegeu os agentes da maior parte da mecânica de sessão do MCP. Com a versão 2026-07-28, isso fica mais simples em ambos os lados: a primeira chamada de ferramenta de um agente é uma requisição autocontida, em vez de um handshake seguido de uma chamada. Cada requisição carrega um cabeçalho Mcp-Protocol-Version. O gateway serve a requisição nessa versão quando ela estiver em supportedVersions, ou a rejeita com HTTP 400 (código -32022) e lista as versões suportadas quando não estiver.

2. Roteamento, cache e rastreamento sem precisar analisar o corpo da requisição

Nas versões anteriores, a operação executada por uma requisição era opaca para qualquer intermediário entre cliente e servidor. Balanceadores de carga, API gateways e limitadores de taxa precisavam analisar o corpo JSON-RPC para determinar qual método estava sendo chamado.

A versão 2026-07-28 resolve isso de três formas:

• Cabeçalhos de intenção: Toda requisição HTTP com fluxo contínuo agora expõe sua intenção em cabeçalhos padrão: Mcp-Method e Mcp-Name (SEP-2243) viajam fora do corpo, dando aos intermediários informações suficientes para rotear, limitar e monitorar apenas na camada HTTP.
• Metadados de frescor para cache: Respostas a operações de listagem e leitura de recursos agora incluem metadados explícitos de validade, ttlMs e cacheScope, inspirados na semântica do HTTP Cache-Control (SEP-2549). Clientes podem armazenar em cache uma resposta de tools/list por uma duração conhecida sem manter uma conexão persistente.
• Rastreamento distribuído formal: A especificação agora reserva as chaves de Contexto de Rastreamento W3C (traceparent, tracestate, baggage) dentro de _meta (SEP-414), formalizando o que vários SDKs já haviam adotado na prática. Um rastreamento distribuído originado em sua aplicação pode agora se propagar por toda a cadeia de chamadas e ser renderizado como uma árvore de spans unificada em qualquer coletor compatível com OpenTelemetry.

3. Interações servidor-para-cliente sem conexões persistentes

Um protocolo sem estado ainda precisa de uma forma para o servidor se comunicar de volta com o cliente durante uma chamada. O MCP tem três dessas interações: elicitação (o servidor pede input ao usuário final), roots (o servidor solicita diretórios e arquivos disponíveis no sistema de arquivos) e sampling (o servidor pede ao modelo do cliente para gerar uma resposta).

Nas versões anteriores, entregar essas requisições significava que o servidor mantinha um fluxo SSE (Server-Sent Events) aberto de volta para o cliente. Com a nova versão, requisições iniciadas pelo servidor só são permitidas enquanto o servidor está ativamente processando uma requisição do cliente (SEP-2260). Cada prompt que um usuário vê remonta a algo que ele ou seu agente iniciou.

As Requisições de Múltiplas Rodadas (SEP-2322) substituem o fluxo de longa duração anterior. O servidor embute perguntas em um InputRequiredResult e externaliza o estado por meio de um token opaco requestState, em vez de enviar uma pergunta via SSE. Veja o exemplo:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Delete 3 files?",
        "requestedSchema": {
          "type": "object",
          "properties": {
            "confirm": {
              "type": "boolean"
            },
            "required": ["confirm"]
          }
        }
      }
    },
    "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
  }
}

Os clientes coletam as respostas do usuário e reemitem a chamada original com as respostas e o requestState. Tudo que o servidor precisa está no payload, então qualquer instância de servidor pode retomar a operação.

4. Desacoplando extensões da especificação principal

Até agora, extensões do MCP eram um conceito informal sem governança. O documento SEP-2133 introduz um sistema formal. Cada extensão carrega um ID em formato DNS reverso, é negociada por meio de um mapa de extensões nas capacidades de cliente e servidor, vive em um repositório dedicado com mantenedores delegados e segue seu próprio ciclo de lançamento independente da especificação principal.

Uma nova Trilha de Extensões dentro do processo SEP define como uma extensão avança de experimental para status oficial. Em vez de cada nova ideia competir por espaço na especificação principal e forçar uma versão com quebra de compatibilidade, capacidades agora podem amadurecer como extensões opcionais em seus próprios cronogramas.

5. Endurecimento da autorização

Seis SEPs alinham a especificação de autorização do MCP com implantações de produção de OAuth 2.0 e OpenID Connect (OIDC). A autorização de entrada do gateway — seja IAM (SigV4) ou OAuth/JWT — não é alterada pela versão do protocolo. O mesmo vale para os provedores de credenciais de saída. Atualizar a versão do protocolo não requer alteração de credenciais ou configuração de autorizador.

6. Tratamento de erros e depreciações

Nas versões anteriores do protocolo, quase tudo retornava como HTTP 200 com um erro dentro do corpo JSON-RPC, incluindo falhas de transporte. Com a versão 2026-07-28, as camadas de transporte e aplicação são separadas de forma limpa. Falhas de transporte retornam códigos de status HTTP reais. Resultados no nível de aplicação permanecem no corpo:

• Método desconhecido: Versões 2025-* retornam erro JSON-RPC no corpo com HTTP 200; versão 2026-07-28 retorna HTTP 404.
• Versão de protocolo não suportada: Versões 2025-* variam; versão 2026-07-28 retorna HTTP 400, código -32022, com lista de versões suportadas no corpo.
• Campo vinculado a cabeçalho ausente ou inconsistente: Versões 2025-* variam; versão 2026-07-28 retorna HTTP 400, código -32020.
• Capacidade de cliente obrigatória ausente: Não aplicável nas versões 2025-*; versão 2026-07-28 retorna código -32021.

A especificação também reatribui o código de erro “recurso não encontrado” do MCP-específico -32002 para o padrão JSON-RPC -32602 Invalid Params (SEP-2164). Se seu cliente corresponder ao código -32002 em algum lugar, audite esses caminhos de código.

Além disso, na versão 2026-07-28: logging/setLevel é descontinuado, e um cliente que o chama é rejeitado. Para optar pela entrega de logs, defina o campo de metadados por requisição io.modelcontextprotocol/logLevel.

Três funcionalidades principais são depreciadas sob a nova política de ciclo de vida de funcionalidades do protocolo (SEP-2577):

• Roots — substituído por parâmetros de ferramenta, URIs de recurso ou configuração de servidor
• Sampling — substituído por integração direta com APIs de provedores de LLM
• Logging — substituído por stderr para transportes stdio e OpenTelemetry para observabilidade estruturada

Essas depreciações são consultivas. Os métodos, tipos e flags de capacidade permanecem funcionais nesta versão e em qualquer versão da especificação publicada dentro de doze meses a partir dela. No entanto, novas implementações não devem depender dessas funcionalidades.

7. Suporte a esquemas JSON Schema 2020-12

Os campos inputSchema e outputSchema de ferramentas agora suportam o vocabulário completo do JSON Schema 2020-12 (SEP-2106). Esquemas de entrada mantêm o requisito de raiz type: "object", mas ganham palavras-chave de composição (oneOf, anyOf, allOf), condicionais e referências internas ($ref, $defs). Esquemas de saída não têm restrição de tipo raiz, e structuredContent pode ser qualquer valor JSON válido. Implementações não devem seguir URIs $ref externos automaticamente e devem impor limites de profundidade e tempo durante a validação.

Como decidir se você está pronto para atualizar

Antes de habilitar a nova versão, responda três perguntas:

• Seus clientes estão prontos? Seus agentes alcançam o Gateway por meio de SDKs de cliente MCP. Verifique se os SDKs que seus frameworks de agente e aplicações host usam já enviaram suporte para 2026-07-28. Os SDKs de Nível 1 (Tier 1) já deveriam ter enviado suporte durante a janela de dez semanas do candidato a lançamento. Consulte a documentação do MCP SDK para a lista atual de níveis.
• Algo que você executa depende de comportamento removido ou alterado? Audite: sessões de protocolo usadas para carregar estado de aplicação, logging/setLevel, código de cliente que corresponde ao código de erro literal -32002, e qualquer dependência de Roots, Sampling ou Logging.
• Você controla ambos os lados? Não é necessário. A seleção de versão acontece por requisição, então um gateway com duas versões serve clientes antigos e novos simultaneamente. Você pode atualizar clientes e o gateway em cronogramas independentes, em qualquer ordem.

Atualizando seu AgentCore Gateway

Para clientes do AgentCore Gateway, adotar a versão 2026-07-28 é uma mudança de configuração. Seu AgentCore Gateway pode suportar múltiplas versões do protocolo simultaneamente. Você pode adicionar 2026-07-28 à lista de supportedVersions do gateway com uma única chamada UpdateGateway. Não é necessário recriar o gateway ou fazer alterações nas configurações individuais de alvos do gateway.

O comando UpdateGateway substitui o supportedVersions pelo conjunto que você envia — ele não acrescenta. Leia a configuração atual primeiro, depois envie a lista completa que você deseja que o gateway anuncie:

# 1. Read the current configuration.
aws bedrock-agentcore-control get-gateway \
    --gateway-identifier <gateway-id>

# 2. Advertise 2026-07-28 alongside the existing version.
aws bedrock-agentcore-control update-gateway \
    --name <gateway-name> \
    --role-arn <gateway-role-arn> \
    --protocol-type MCP \
    --authorizer-type <gateway-authorizer-type> \
    --gateway-identifier <gateway-id> \
    --protocol-configuration '{
      "mcp": {
        "supportedVersions": ["2025-11-25", "2026-07-28"]
      }
    }'

O AgentCore Gateway funciona com qualquer uma das seguintes versões do protocolo: 2025-03-26, 2025-06-18, 2025-11-25 e 2026-07-28.

Confirme que a nova versão está ativa chamando seu gateway com os novos cabeçalhos:

curl -s https://<your-gateway-endpoint>/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json,text/event-stream" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/list" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Uma resposta bem-sucedida confirma que o gateway serviu a requisição na versão 2026-07-28. Uma rejeição com código -32022 significa que a versão ainda não está no supportedVersions do gateway, e o corpo da resposta lista o que o gateway atualmente anuncia.

Para reverter, basta enviar a lista sem 2026-07-28. Requisições especificando a versão removida serão rejeitadas com um corpo de resposta listando as versões que o gateway ainda suporta. Certifique-se de que os clientes que você já migrou possam fazer fallback antes de remover a versão que eles estão solicitando.

Como funciona a seleção de versão

Clientes selecionam uma versão em cada requisição, não por meio de um handshake único. Cada requisição MCP declara sua versão no cabeçalho MCP-Protocol-Version, e o gateway a honra quando está em supportedVersions:

• Uma requisição nomeando uma versão que o gateway anuncia é servida nessa versão.
• Em um gateway com duas versões (por exemplo, 2026-07-28 e 2025-11-25), uma requisição 2026-07-28 recebe o novo comportamento e uma requisição 2025-11-25 recebe o comportamento anterior.
• Uma requisição nomeando uma versão que o gateway não anuncia é rejeitada com HTTP 400 e código -32022. O corpo da resposta lista as versões que o gateway suporta.
• Uma requisição que omite o cabeçalho recebe a versão padrão, 2025-03-26. Se esse padrão não estiver no supportedVersions do gateway, a requisição é rejeitada.

Isso permite um rollout em três etapas: adicionar 2026-07-28 junto às versões existentes, migrar clientes no seu próprio ritmo e, somente após todos os clientes solicitarem a nova versão, reduzir a lista.

Se o seu gateway está na frente de um servidor MCP alvo que atualiza para 2026-07-28 antes dos seus clientes, ele traduz entre versões — um cliente 2025-* pode chamar ferramentas comuns em um alvo 2026-07-28 e receber resultados no formato esperado, sem precisar atualizar. No entanto, essa tradução não suporta atualmente chamadas de elicitação e sampling de servidores para clientes.

Conclusão

A versão MCP 2026-07-28 é a maior revisão do protocolo já feita, e foi projetada para ser a última revisão que quebra compatibilidade. O modelo sem estado dá ao MCP uma base que escala em infraestrutura HTTP comum, enquanto as Extensões MCP dão espaço para novas capacidades evoluírem em seus próprios cronogramas.

Com o Amazon Bedrock AgentCore Gateway, adicionar suporte à versão mais recente do protocolo é apenas uma chamada UpdateGateway. Para começar, consulte a documentação do AgentCore Gateway, revise a especificação MCP 2026-07-28 e seu changelog, e tente habilitar a nova versão em um gateway hoje. Para detalhes completos, veja também o changelog em relação à versão 2025-11-25 e o anúncio do candidato a lançamento no blog do MCP. Se você tiver feedback sobre a especificação, os mantenedores aceitam issues no repositório da especificação MCP. Para dúvidas sobre o AgentCore Gateway, entre em contato pelo AWS re:Post ou pelos canais habituais de suporte da AWS.

Fonte

How AgentCore Gateway supports the MCP 2026-07-28 spec (https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/)