A Armadilha do Stateful que Prejudicava o MCP
O protocolo inicial do MCP impôs uma restrição arquitetural significativa: statefulness inerente. Anteriormente, um cliente iniciava a interação com uma solicitação initialize para um endpoint MCP. O servidor então criava e retornava um session ID único, um token crítico para toda a comunicação subsequente entre cliente e servidor. Cada solicitação de acompanhamento tinha que carregar esse identificador.
Este design criou uma falha fundamental para implantações escaláveis. O session ID obrigatório prendia o cliente à instância específica do servidor que processou inicialmente a chamada initialize. Isso quebrou os paradigmas padrão de balanceamento de carga. Se um balanceador de carga, digamos um roteador round-robin, direcionasse uma solicitação subsequente para uma instância diferente, esse servidor não teria nenhum registro da sessão. O resultado era um erro 400 "session not found" debilitante, interrompendo as operações do cliente. Da mesma forma, se uma instância falhasse, todos os seus estados de sessão ativos eram perdidos instantaneamente, causando falhas imediatas nas solicitações do cliente.
Os desenvolvedores eram forçados a usar soluções alternativas complexas e ineficientes para mitigar esses problemas. Soluções comuns incluíam a implementação de sticky sessions, que garantiam que um cliente atingisse consistentemente a mesma instância do servidor. Outra abordagem envolvia a implantação de armazenamentos de estado compartilhado, como uma instância Redis, para centralizar e sincronizar dados de sessão em todos os servidores. Ambos os métodos introduziram sobrecarga operacional desnecessária, aumentaram a latência da rede e elevaram significativamente os custos de infraestrutura. Esses eram fardos induzidos pelo protocolo, não escolhas.
Stateless por Padrão: Um Protocolo Renascido
A nova especificação do MCP, '2026-07-28', introduz uma mudança radical. Duas propostas principais, SEP-2575 e SEP-2567, redefinem o núcleo do protocolo. A SEP-2575 elimina o handshake initialize e initialized, enquanto a SEP-2567 remove o cabeçalho MCP-Session-Id e sua session associada em nível de protocolo.
Essas mudanças transformam uma chamada de ferramenta de várias etapas em uma única solicitação HTTP independente. Anteriormente, o contexto era fragmentado; agora, todas as informações necessárias trafegam em um campo meta dentro do corpo JSON. Este design torna cada solicitação independente, espelhando os princípios HTTP stateless.
O alinhamento com a infraestrutura HTTP padrão está completo. Novos cabeçalhos, MCP-Method e MCP-Name, agora carregam informações críticas de roteamento. Isso permite que componentes de rede como gateways, firewalls e limitadores de taxa tomem decisões sem analisar o payload JSON. Tal eficiência é crucial para o desempenho, especialmente no Cloudflare.
O protocolo não exige mais Durable Objects para falar MCP, simplificando a implantação. Os serviços podem escalar para zero quando ociosos, reduzindo significativamente os custos operacionais e expandindo as opções de implantação. Essa mudança elimina os pontos problemáticos de sticky sessions ou instâncias Redis compartilhadas, tornando o MCP verdadeiramente stateless por padrão.
Infraestrutura mais Inteligente e Estado da Aplicação
Ser stateless desbloqueia enormes vantagens de implantação. Plataformas serverless como Cloudflare Workers e Google Cloud Run agora escalam para zero quando ociosas, reduzindo drasticamente os custos operacionais. Os servidores não mantêm mais conexões persistentes, eliminando a necessidade de instâncias sempre ativas para manter o estado da sessão. Isso muda fundamentalmente o provisionamento de infraestrutura.
O Protocol não sobrecarrega mais o gerenciamento de estado. Em vez disso, o estado torna-se uma preocupação em nível de aplicação. Ferramentas podem criar identificadores explícitos, como um basket_id ou browser_id. O modelo então passa esse identificador de volta como um argumento comum em chamadas de ferramenta subsequentes. Isso confere aos desenvolvedores maior flexibilidade, permitindo que gerenciem o estado exatamente conforme necessário, em vez de se conformarem a padrões impostos pelo protocolo.
O MCP adota cache inspirado em HTTP para maior eficiência do lado do cliente. Novas dicas de time to live e cache scope informam aos clientes sobre a atualidade das listas de ferramentas, prompts e recursos. Isso permite que os clientes façam cache de respostas com confiança, evitando conexões persistentes para atualizações. Para mais leituras sobre design de API stateless robusto, explore Statelessness in API Design: Understanding & Examples - Unkey. Essas dicas garantem que os clientes saibam exatamente por quanto tempo os dados permanecem válidos entre os usuários.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Novos Padrões para Interações Complexas
Interações complexas agora seguem um padrão claro, orientado pelo cliente. Anteriormente, o servidor enviava perguntas de acompanhamento não solicitadas, um risco de segurança. A nova especificação evita isso. Para interações de múltiplos turnos, o servidor retorna um resultado input_required.
Este resultado inclui um payload request_state serializado, encapsulando todo o contexto para a ação pendente. Um cliente recebe input_required, solicita ao usuário (por exemplo, "Tem certeza?") e, em seguida, reinicia a solicitação original. O cliente anexa a resposta do usuário e ecoa o request_state. Isso garante que o cliente sempre conduza a interação. Qualquer instância de servidor pode retomar a solicitação, reforçando a natureza stateless.
Operações de longa duração aproveitam a agora oficial extensão 'tasks'. Este recurso graduou-se do status experimental. Para uma tarefa como processar um reembolso, o servidor reconhece imediatamente a solicitação. Ele retorna uma resposta indicando que o trabalho está em execução, evitando o bloqueio da conexão.
Os clientes então rastreiam o progresso de forma assíncrona. Eles podem consultar usando tasks/get ou inscrever-se via subscriptions/listen. Isso permite a recuperação do resultado final assim que a tarefa de longa duração for concluída. Este design elimina a necessidade de conexões persistentes durante computações longas, melhorando a eficiência e a resiliência do protocolo.
Perguntas Frequentes
Qual era o principal problema com o antigo MCP com estado?
O protocolo antigo exigia IDs de sessão que prendiam os clientes a instâncias específicas do servidor. Isso tornava o balanceamento de carga difícil, exigia soluções alternativas complexas como sticky sessions ou Redis, e tornava o sistema frágil, já que uma reinicialização do servidor poderia perder o estado da sessão.
Como o novo MCP stateless resolve esses problemas?
Ele remove completamente os handshakes e IDs de sessão (especificação 2026-07-28). Cada solicitação é autossuficiente, permitindo o balanceamento de carga round-robin padrão, maior resiliência e a capacidade de os servidores reduzirem a zero, diminuindo custos.
Como o estado é gerenciado no novo MCP se o protocolo é stateless?
O estado agora é gerenciado no nível da aplicação, não no nível do protocolo. Os desenvolvedores podem fazer com que uma ferramenta crie um identificador explícito (por exemplo, 'browser_id') que o modelo passa de volta em chamadas subsequentes, um padrão flexível comum em APIs HTTP padrão.
O que acontece com chamadas de ferramenta de longa duração sem uma conexão persistente?
A nova especificação gradua a extensão 'tasks' para um recurso oficial. Para um trabalho de longa duração, o servidor pode retornar imediatamente um ID de tarefa, e o cliente pode então consultar ou inscrever-se nessa tarefa para obter atualizações de progresso e o resultado final de forma assíncrona.