MCP stateless elimina sessão fixa em servidores AWS

A AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → publicou nesta semana, no AWS Architecture Blog, uma análise de como as mudanças mais recentes na especificação do Model Context Protocol↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → (MCP) afetam o deployment de servidores remotos. A InfoQ reportou o caso em 25 de setembro de 2026: o núcleo da mudança é a remoção de sessões em nível de protocolo, o que elimina a exigência de sticky sessions e de um armazenamento de sessão compartilhado entre instâncias.

Para quem já subiu um servidor MCP em produção, isso ataca diretamente um dos pontos mais chatos da arquitetura: manter afinidade de sessão (routing por Mcp-Session-Id) exige camadas extras de roteamento, e sincronizar estado de sessão entre réplicas costuma virar dor de cabeça em cenários de autoscaling agressivo ou de deploys blue-green.

O que a especificação remove (e o que adiciona)

A nova versão do MCP elimina o handshake initialize/initialized e o header Mcp-Session-Id, que até então identificavam uma sessão persistente entre cliente e servidor. Sem esse handshake, uma requisição pode ser roteada para qualquer instância disponível atrás de um load balancer convencional, sem lógica especial de afinidade.

No lugar do handshake obrigatório, a especificação introduz uma operação opcional, server/discover, para clientes que precisam conhecer as capacidades do servidor antes de disparar chamadas de tool. Segundo os autores do post da AWS, Anand Komandooru, Steven DeVries e Haleh Najafzadeh, isso substitui o modelo de sessão persistente por um modelo request-response mais próximo do que já se usa em APIs REST tradicionais.

Outra peça central da mudança é o que a especificação chama de MRTR: em vez de o servidor manter um stream aberto para poder iniciar requisições ao cliente durante uma interação de múltiplos passos, o fluxo agora usa respostas do tipo input_required seguidas de novas requisições do cliente. Na prática, isso troca conexão de longa duração por uma sequência de chamadas curtas e independentes, o que é exatamente o padrão que infraestrutura serverless e load balancers convencionais sabem lidar bem.

Por que isso reduz custo e complexidade de infra

O ponto prático levantado pelos autores da AWS é que times que hoje mantêm um servidor MCP em produção podem eliminar componentes construídos só para sustentar sessão de protocolo: roteamento com afinidade de sessão vira roteamento convencional, e o armazenamento usado exclusivamente para guardar estado de sessão MCP deixa de ser necessário. Isso não significa que a aplicação fica sem estado nenhum, apenas que o protocolo não impõe mais essa obrigação. Como resumiu Michael Madsen, ao comentar a especificação no LinkedIn e citado pela InfoQ:

"The protocol is stateless. Your application doesn't have to be."

Ou seja: se a sua aplicação precisa lembrar de contexto entre chamadas (histórico de conversa, resultado de uma tool anterior), esse estado continua sendo responsabilidade sua, só que agora ele mora explicitamente na camada de aplicação, e não é mais imposto pelo transporte do MCP. Isso dá liberdade para escolher onde guardar esse estado (banco, cache, ou nem guardar, se o caso de uso permitir), em vez de ser forçado a manter conexões vivas e sessões coladas a uma instância específica.

Um efeito direto dessa mudança é que o AWS Lambda passa a ser identificado pelos autores como opção de deployment que se encaixa nesse modelo request-response, já que o protocolo não exige mais conexões persistentes de sessão. Para quem hoje evita Lambda para servidores MCP justamente por causa da natureza stateful das sessões, isso reabre a porta para um modelo de custo pay-per-invocation em vez de manter instâncias sempre ativas para preservar sessão.

Roteamento e observabilidade ganham headers próprios

A especificação também adiciona os headers Mcp-Method e Mcp-Name, pensados para permitir que gateways façam roteamento e throttling com base no método e no nome da tool sendo chamada, sem precisar inspecionar o corpo da requisição. Isso é relevante para quem opera múltiplos servidores MCP atrás de um gateway único e precisa aplicar rate limit por tool ou rotear chamadas específicas para instâncias especializadas.

Para tracing distribuído, a especificação adota W3C Trace Context, o que facilita integrar chamadas MCP a stacks de observabilidade já existentes baseadas em OpenTelemetry. E para cache, os controles ttlMs e cacheScope dão ao servidor uma forma padronizada de indicar por quanto tempo e em que escopo uma resposta pode ser cacheada, o que ajuda a reduzir custo em cenários com chamadas repetidas de tools que não mudam resultado com frequência.

O que fica mais difícil: resumibilidade de stream e idempotência

Nem tudo é ganho sem contrapartida. A especificação removeu a resumibilidade de stream, recurso que permitia a um cliente retomar uma operação interrompida a partir de onde parou. Sem isso, uma operação interrompida precisa ser reiniciada do zero pelo cliente, o que a InfoQ aponta como fator que aumenta a importância de garantir idempotência em chamadas de tool que produzem efeitos colaterais (grava dado, dispara uma ação externa, e assim por diante). Quem constrói tools MCP que alteram estado externo precisa agora tratar retry como cenário normal, não exceção, e desenhar as tools para que uma segunda execução da mesma chamada não duplique o efeito.

Migração: convivência entre versões antigas e novas

A transição não é instantânea. O projeto Apify, citado no post da AWS, está implementando suporte stateless em paralelo ao seu servidor MCP sessionful existente, com testes de conformidade cobrindo as duas versões do protocolo simultaneamente. Isso dá uma pista de como deve ser a migração na prática para quem mantém servidores MCP em produção hoje: não é um corte seco, é rodar as duas versões em paralelo até que o tráfego de clientes legados desapareça.

A própria AWS recomenda rastrear a versão do protocolo no gateway e manter a infraestrutura de sessão até que o tráfego legado tenha sido eliminado, ao invés de desligar tudo de uma vez. O projeto MCP, por sua vez, estabeleceu uma política de ciclo de vida de features que define um período determinado de migração para capacidades descontinuadas, dando previsibilidade para quem precisa planejar quando pode efetivamente aposentar a infraestrutura de sessão.

A AWS mapeou essas mudanças ao seu guia de Well-Architected para IA agêntica, cobrindo monitoramento, tracing, segurança e integração de tools, o que sinaliza que a mudança de protocolo já está sendo tratada como padrão de arquitetura de referência, e não como um detalhe isolado de implementação.

O que ainda está em aberto

A especificação stateless resolve o problema de afinidade de sessão no nível de protocolo, mas empurra de volta para quem constrói a aplicação a decisão de como e onde guardar contexto entre chamadas quando o caso de uso exige memória de conversa ou de execução. Times que hoje dependem fortemente de sessão persistente para lógica de negócio vão precisar desenhar essa camada de estado explicitamente, provavelmente com um cache ou banco próprio, em vez de depender do transporte MCP para isso. E enquanto houver clientes MCP antigos em produção, a promessa de simplificação de infraestrutura só se realiza parcialmente: a infraestrutura de sessão continua existindo até o tráfego legado zerar.

Fonte: InfoQ