MCP sem estado elimina sessões fixas e simplifica escala na AWS

A especificação mais recente do Model Context Protocol (MCP) removeu as sessões de nível de protocolo e o cabeçalho Mcp-Session-Id, permitindo que cada requisição seja roteada de forma independente para qualquer instância disponível de um servidor MCP. A mudança elimina a exigência de sticky sessions e de armazenamento compartilhado de sessão para o protocolo, segundo a nota do InfoQ. Na prática, implantações na AWS deixam de precisar de infraestrutura mantida exclusivamente para preservar sessões MCP.

O que mudou na especificação

A nova especificação remove o handshake initialize/initialized e o cabeçalho Mcp-Session-Id. Com isso, um balanceador de carga convencional pode rotear chamadas sem afinidade de sessão. O protocolo também introduz a operação opcional server/discover para clientes que precisam conhecer as capacidades do servidor antes de invocar ferramentas.

O MRTR substitui requisições iniciadas pelo servidor que antes dependiam de streams mantidos abertos. Interações em múltiplas etapas passam a usar respostas input_required seguidas de novas requisições. Os cabeçalhos Mcp-Method e Mcp-Name permitem roteamento e throttling em gateways, enquanto o W3C Trace Context dá suporte a rastreamento distribuído. Os controles ttlMs e cacheScope fornecem opções de cache.

O que muda no deploy na AWS

Autores do AWS Architecture Blog descrevem a substituição do roteamento por afinidade de sessão por roteamento de requisição comum e a remoção de armazenamento de sessão usado apenas para manter estado do protocolo MCP. O AWS Lambda aparece como opção de deployment alinhada ao modelo requisição-resposta, porque o protocolo não exige mais conexões persistentes.

Essa mudança reduz componentes de infraestrutura específicos de sessão em arquiteturas serverless e em implantações atrás de load balancers. Não há ganho automático de aplicação, mas menos superfície operacional para escalar horizontalmente.

Estado de protocolo não é estado de aplicação

Michael Madsen resumiu a separação: o protocolo é stateless; a aplicação não precisa ser. Isso significa que a ausência de sessão no MCP não elimina a necessidade de manter estado da aplicação quando o caso de uso exigir — apenas desloca essa responsabilidade para fora do protocolo, para bancos, filas ou outros componentes.

Migração e ressalvas

A remoção de retomada de streams é uma limitação relevante. Clientes podem precisar repetir operações interrompidas, o que aumenta a importância de idempotência em chamadas de ferramentas com efeitos colaterais.

A implementação do servidor MCP da Apify está adicionando suporte stateless ao lado do servidor sessionful existente, com roteamento e testes de conformidade para as duas versões. A AWS recomenda rastrear 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 publicou uma política de ciclo de vida de funcionalidades com período de migração para capacidades deprecadas.

Para deploys AWS que hoje mantêm afinidade de sessão ou armazenamento dedicado só ao estado do protocolo, a especificação stateless faz sentido imediato. Para quem ainda atende clientes MCP antigos, a coexistência com a versão sessionful e o versionamento no gateway seguem recomendados na nota do InfoQ.