A nova especificação do Model Context Protocol (MCP) torna o protocolo Apify MCP server: stateless support (GitHub issue) (github.com)-is-your-aws-mcp-server-deployment-Well-Architected guidance for agentic AI (AWS) (docs.aws.amazon.com)/" target="_blank" rel="nofollow noopener">MCP went stateless: is your AWS MCP server deployment wel... (aws.amazon.com) o handshake initialize/initialized e o cabeçalho Mcp-Session-Id foram removidos, permitindo que cada requisição seja roteada de forma independente para qualquer instância de servidor atrás de um load balancer convencional. A mudança elimina a exigência de sticky sessions e de armazenamento compartilhado de sessão no nível do protocolo, segundo análise publicada pela AWS Architecture Blog.
Na prática, servidores MCP remotos deixam de precisar de afinidade de sessão, o que simplifica o escalonamento horizontal. A contrapartida é que gerenciamento de estado e outras responsabilidades migram para a infraestrutura ao redor do servidor, e não mais para o protocolo em si.
Info: a especificação atualizada também introduz uma operação opcional server/discover, que permite ao cliente consultar as capacidades do servidor antes de fazer chamadas de ferramentas.
O que muda nas implantações de servidores MCP na AWS
Os autores Anand Komandooru, Steven DeVries e Haleh Najafzadeh, do AWS Architecture Blog, descrevem a substituição do roteamento com afinidade de sessão por roteamento de requisições convencional, além da remoção de storage de sessão usado exclusivamente para estado do protocolo MCP. Para implantações na AWS, isso pode eliminar infraestrutura mantida apenas para sustentar sessões do protocolo.
O trio também aponta o AWS Lambda como opção de deploy que se encaixa no modelo requisição-resposta, já que o protocolo não exige mais conexões de sessão persistentes. Mas o protocolo ficou stateless, e a aplicação também precisa ficar? Não necessariamente.
# publicidade
"O protocolo é stateless. Sua aplicação não precisa ser", resumiu Michael Madsen ao comentar a especificação no LinkedIn, destacando a distinção entre estado de protocolo e estado de aplicação.
Essa distinção é o ponto central: o estado da aplicação continua existindo, só que gerenciado pela infraestrutura ao redor, e não mais pelo MCP. O Blog de arquitetura da AWS mapeia as mudanças para a orientação Well-Architected para IA agêntica, cobrindo monitoramento, tracing, segurança e integração de ferramentas.
Mrtr, novos cabeçalhos e controles de cache
O padrão MRTR substitui as requisições iniciadas pelo servidor, que antes exigiam streams mantidos abertos. Interações em múltiplas etapas agora acontecem por meio de respostas input_required e requisições subsequentes, conforme a especificação do padrão MRTR.
A especificação também traz novos mecanismos operacionais:
- Cabeçalhos Mcp-Method e Mcp-Name: permitem roteamento em gateway e throttling por método ou ferramenta.
- W3C Trace Context: suporte a distributed tracing entre cliente e servidor.
- ttlMs e cacheScope: controles de cache para respostas.
Um trade-off relevante: a retomada de streams (stream resumability) também foi removida. Clientes podem precisar repetir operações interrompidas, o que eleva a importância da idempotência em chamadas de ferramentas que produzem efeitos colaterais. Como garantir que uma tool de pagamento, por exemplo, não execute duas vezes após um retry? A resposta passa a ser responsabilidade da aplicação, com chaves de idempotência e design defensivo.
Atenção: sem stream resumability, toda tool call com efeito colateral precisa ser idempotente. Retries automáticos podem duplicar operações se o servidor não tratar repetições.
Migração: projetos mantêm suporte a clientes legados
Trabalhos iniciais de implementação mostram que a infraestrutura existente ainda exige um caminho de transição. O projeto de servidor MCP da Apify está implementando suporte stateless em paralelo ao servidor com sessão já existente, com testes de roteamento e conformidade cobrindo as duas versões do protocolo.
A recomendação da AWS para esse período é acompanhar as versões do protocolo no gateway e manter a infraestrutura de sessão até que o tráfego legado seja eliminado. O projeto MCP também estabeleceu uma política de ciclo de vida de funcionalidades, com período de migração definido para capacidades depreciadas.
Dica: se você opera um servidor MCP em produção, versione o tráfego no gateway desde já. Isso permite medir quando clientes antigos deixam de existir e planejar a remoção da camada de sessão com segurança.
Na avaliação do Mercado de TI, o movimento alinha o MCP ao modelo operacional que times de plataforma brasileiros já dominam: stateless atrás de load balancer, com estado delegado a Redis, bancos ou filas. Para quem já estudava o que é o Model Context Protocol, a mudança reduz a barreira de entrada para rodar servidores MCP em ambientes serverless e de baixo custo. Times que adotam autenticação centralizada para MCP em empresas ganham um desenho mais simples de gateway, com throttling por método via os novos cabeçalhos. E para quem avalia funções como opção de deploy, vale lembrar que a AWS Lambda passou a permitir funções de até 90 minutos em Lambda Managed Instances, ampliando o espaço para workloads MCP mais longos. O próximo passo para os times é auditar tool calls quanto à idempotência antes de desligar qualquer infraestrutura de sessão.
Fonte: Infoq
