Arquitetura Stateless: Escalando Servidores de Agentes Sem Sessões Persistentes

Resumo do Artigo

A versão candidata do Protocolo de Contexto do Modelo 2026-07-28 introduz uma das maiores mudanças arquitetônicas desde o lançamento do MCP: o núcleo de transporte se torna sem estado. Anteriormente, os servidores HTTP MCP exigiam um initialize handshake e um Mcp-Session-Id, forçando os clientes a permanecerem ligados ao estado da sessão. Em grande escala, isso criava roteamento pegajoso, armazenamento de sessões Redis, problemas de falha de pod e comportamento ruim em ambientes serverless. A nova especificação remove a gestão de sessões em nível de transporte. Cada solicitação se torna autodescritiva e independente, permitindo balanceamento de carga normal em round-robin, failover transparente, implantação serverless, roteamento por cabeçalho HTTP, controles de cache, interações de múltiplas viagens e tarefas assíncronas.

O MCP originalmente se encaixava em um ambiente como:

um desenvolvedor
→ um servidor MCP local

Isso era ideal para integrações stdio e locais.

A implantação empresarial é diferente:

10.000 usuários
→ gateway de IA
→ cluster MCP
→ muitas ferramentas empresariais

Nessa escala, as sessões de transporte se tornam infraestrutura.

Por que o antigo modelo de sessão era difícil

O design HTTP mais antigo usava:

initialize
→ Mcp-Session-Id
→ solicitações subsequentes reutilizam a sessão

Imagine três pods Kubernetes:

Pod A
Pod B
Pod C

A primeira solicitação chega ao A.

A próxima solicitação em round-robin chega ao C.

Se o estado da sessão vive apenas em A, C não pode continuar.

O resultado é uma falha de sessão não encontrada.

Soluções tradicionais

Roteamento pegajoso

Prenda um cliente a um pod.

Isso prejudica o balanceamento de carga e o failover.

Redis compartilhado

Armazene o estado da sessão fora dos pods.

Isso adiciona chamadas de rede, latência, complexidade operacional e outra dependência altamente disponível.

Gateway ciente da sessão

Faça o gateway entender o estado do protocolo.

Isso aumenta o acoplamento e a complexidade.

O que a especificação de 2026-07-28 muda

O novo núcleo remove:

o handshake initialize / initialized;
o Mcp-Session-Id lógico.

Cada solicitação carrega seus próprios metadados.

Os cabeçalhos HTTP incluem valores como:

MCP-Protocol-Version
Mcp-Method
Mcp-Name

O corpo da solicitação também inclui informações e capacidades do cliente em _meta.

Qualquer instância de servidor saudável pode processar qualquer solicitação.

Consequências arquitetônicas

Round robin padrão

As solicitações podem ir para qualquer pod.

Falha de pod transparente

Um contêiner reiniciado não destrói mais uma sessão de transporte.

Implantação serverless

Os servidores MCP podem funcionar naturalmente em infraestrutura serverless e escalar para zero quando ocioso.

Sem Redis de sessão de protocolo

Um estado compartilhado ainda pode ser necessário para tarefas empresariais, mas não é mais necessário apenas para manter uma sessão de transporte MCP.

A Google observa que servidores de produção importantes, como o servidor MCP do GitHub, já se afastaram do armazenamento de sessões Redis sob essa arquitetura.

Os cabeçalhos HTTP se tornam uma camada de governança

Promover a identidade de método e ferramenta para os cabeçalhos HTTP permite que os gateways realizem:

roteamento;
limitação de taxa;
auditoria;
política;
métricas;

sem analisar o corpo JSON.

Por exemplo:

Mcp-Name: delete_user
→ requer aprovação

Mcp-Name: search
→ permitir

O protocolo também exige que os valores de cabeçalho e corpo correspondam, reduzindo as oportunidades de contornar políticas.

O cache se torna explícito

O novo design introduz campos como:

ttlMs
cacheScope

Os clientes podem armazenar em cache listas de ferramentas e recursos por um período explícito, em vez de manter conexões de longa duração apenas para detectar mudanças.

Isso pode reduzir significativamente solicitações repetidas em escala empresarial.

E quanto à confirmação do usuário?

Sistemas sem estado ainda precisam de interações de múltiplas etapas.

O novo padrão de Solicitações de Múltiplas Viagens permite que um servidor retorne um InputRequiredResult mais o requestState serializado.

O cliente:

pergunta ao usuário;
coleta a resposta;
reenviam a solicitação;
inclui o estado da solicitação original.

Qualquer instância de servidor pode continuar o fluxo de trabalho.

O estado se move para um objeto de nível de aplicativo explícito, em vez de afinidade de transporte.

Tarefas de longa duração

Um backup de banco de dados ou reembolso pode levar muitos segundos.

A extensão de Tarefas permite que uma chamada de ferramenta retorne um taskId imediatamente e execute em segundo plano.

O cliente pode usar mais tarde primitivas de tarefa para recuperar status e resultados finais.

A conversa não precisa manter uma conexão aberta.

Transporte sem estado não significa lógica de negócios sem estado

Um reembolso de longa duração ainda precisa:

taskId
status
result

armazenado em algum lugar.

A diferença é que o datastore existe para o estado da tarefa de negócios, não para sessões de transporte de protocolo.

Essa é uma fronteira arquitetônica mais limpa.

Melhorias de segurança

A especificação também fortalece vários mecanismos de segurança.

Verificação de emissor

Os clientes validam emissores de autorização.

Indicadores de recurso

Tokens identificam o servidor de recurso MCP pretendido.

JSON Schema 2020-12

Os argumentos da ferramenta podem usar composição de esquema mais rica e validação mais rigorosa.

Essas mudanças são mais importantes à medida que o MCP passa do desenvolvimento local para a infraestrutura empresarial remota.

Depreciação formal

O novo ecossistema também introduz um ciclo de vida previsível:

Ativo
→ Depreciado
→ Removido

A observabilidade em nuvem está se movendo cada vez mais em direção ao OpenTelemetry, em vez de registros específicos de protocolo.

Novamente, o MCP está começando a parecer mais com infraestrutura em nuvem do que um mecanismo de integração local.

Arquitetura de nuvem recomendada

Implantação mais antiga:

agente
→ gateway MCP
→ balanceador de carga pegajoso
→ pod MCP
→ sessão Redis

Novo design:

agente
→ gateway API
→ balanceador de carga round-robin
   ├── pod MCP
   ├── pod MCP
   └── pod MCP

O estado da tarefa de negócios de longa duração permanece separado.

Abordagem de migração

Não migre todos os servidores de uma vez.

Comece com:

inventariar as dependências atuais de protocolo e sessão;
identificar suposições de Redis e sessão pegajosa;
atualizar um read-on