MCP Tornou-se Sem Estado: Migrando um Gateway AgentCore

MCP não precisa mais de uma sessão de protocolo para chamadas de ferramentas remotas. A especificação de 2026-07-28 remove o handshake de inicialização e Mcp-Session-Id, fazendo com que cada solicitação carregue informações suficientes para se sustentar sozinha.

Eu migrei um Amazon Bedrock AgentCore Gateway funcional que expõe o conector WebSearch gerenciado. A mudança foi menor do que a especificação faz parecer: uma atualização de configuração do gateway e uma alteração na solicitação do lado do cliente. O alvo do WebSearch, a autorização IAM, o esquema da ferramenta e a conexão local do Codex permaneceram intactos.

O resultado é a parte útil. O gateway agora atende clientes MCP antigos e novos no mesmo endpoint, e o novo caminho alcança o WebSearch sem um handshake ou sessão de protocolo.

O estado antes da migração

Minha configuração existente já usava o padrão do Web Search como um Conector Gerenciado:

Codex
  -> local stdio MCP shim
    -> Solicitação HTTPS assinada com SigV4
      -> AgentCore Gateway
        -> conector WebSearch gerenciado

O shim local apresentava uma ferramenta ao Codex, assinava a solicitação de saída com uma identidade AWS e chamava o WebSearch através do gateway. Funcionou, mas tanto o shim quanto o gateway estavam fixados no MCP 2025-06-18.

A solicitação carregava MCP-Protocol-Version: 2025-06-18 em um cabeçalho HTTP. Seu corpo JSON-RPC continha o nome da ferramenta e argumentos, mas nenhuma informação ou capacidades do cliente por solicitação.

O que muda no MCP sem estado

Versões remotas anteriores do MCP estabeleciam contexto de protocolo através de initialize, seguidas por notifications/initialized. Servidores HTTP transmitíveis poderiam então emitir um Mcp-Session-Id que os clientes retornavam em solicitações posteriores. Isso acoplava o tráfego subsequente ao estado estabelecido anteriormente.

SEP-2575 remove o handshake de inicialização, enquanto SEP-2567 remove sessões em nível de protocolo do HTTP transmitível. Sob 2026-07-28, cada solicitação declara sua versão, método, nome da ferramenta, identidade do cliente e capacidades.

A nova chamada do WebSearch adiciona três cabeçalhos HTTP:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: web-search-tool___WebSearch

Ela também adiciona metadados da solicitação dentro de params:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "web-search-tool___WebSearch",
    "arguments": {
      "query": "MCP 2026-07-28 specification",
      "maxResults": 2
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "agentcore-websearch-shim",
        "version": "0.2.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

As versões do cabeçalho e do corpo devem concordar. AgentCore Gateway rejeita incompatibilidades, o que fornece aos gateways e outras infraestruturas HTTP um sinal de roteamento confiável sem precisar analisar todo o corpo.

Resultados normais também carregam resultType: "complete". Operações interativas podem, em vez disso, retornar resultType: "input_required" e continuar através de uma solicitação posterior usando o modelo de Solicitação de Múltiplas Rodadas da especificação. O estado se torna dados explícitos, não um histórico de conexão oculto.

Quantificando a mudança

Para um cliente convencional ciente de sessão, a primeira chamada de ferramenta cai de uma troca de inicialização seguida pela troca de ferramenta para uma troca de ferramenta autossuficiente. Isso remove uma viagem de rede do caminho frio. A economia é igual ao tempo de ida e volta do cliente para o servidor, mas apenas antes da primeira chamada.

O AgentCore Gateway já aceitava a chamada direta do tools/call do meu shim sem um handshake anterior, então sua contagem de solicitações remotas permaneceu 1 -> 1. Eu medi o corpo JSON compacto para a mesma chamada do WebSearch:

A nova solicitação adiciona 210 bytes ao corpo, além de dois cabeçalhos de roteamento. Não há ganho de latência credível a ser reivindicado para este cliente porque a execução do WebSearch domina a chamada e o antigo shim já havia pulado o handshake. O benefício imediato para o cliente é a conformidade com o novo protocolo e acesso a seu resultado, descoberta, cache, rastreamento e contratos de múltiplas rodadas.

A aritmética do lado do servidor é mais forte:

• Estado da sessão de protocolo: N clientes ativos anteriormente significavam até N sessões de protocolo ou um armazenamento de sessão compartilhado. O novo núcleo não mantém registros de sessão de protocolo. O estado da aplicação permanece separado.
• Balanceamento de carga: qualquer