O MCP sem estado resolve o problema?

O MCP sem estado é a mudança que transformou o Model Context Protocol de um protocolo com conexões fixas em um modelo de requisição e resposta. Na especificação 2026-07-28, publicada pela Anthropic 28 de julho de 2026, cada chamada de ferramenta virou uma requisição HTTP independente, sem sessão nem ID para rotear. Isso derruba a infraestrutura que todo servidor MCP precisava manter ligada.

MCP sem estado: o que muda na especificação 2026-07-28

O MCP sem estado é a mudança central da quinta versão da especificação do Model Context Protocol, publicada pela Anthropic 28 de julho de 2026 e identificada como 2026-07-28. O protocolo deixou de ser bidirecional e stateful para virar um modelo de requisição e resposta: cada chamada de ferramenta é uma requisição HTTP isolada, sem sessão, sem ID e sem conexão persistente entre cliente e servidor.

O Model Context Protocol é um padrão aberto, criado pela Anthropic, para expor ferramentas e recursos a agentes de IA. Na versão anterior, o cliente abria uma sessão, recebia um ID e precisava que toda chamada seguinte voltasse ao mesmo servidor. A sessão existia mesmo quando nenhuma ferramenta era usada durante a execução.

Na prática, a mudança elimina três obrigações de infraestrutura: manter a conexão viva, rotear a sessão para a mesma instância e provisionar servidor dedicado. Em troca, o servidor precisa descrever suas ferramentas a cada requisição, e o cliente não pode depender de memória de estado entre chamadas.

A Anthropic descreve a mudança como o caminho para implantar servidores MCP em infraestrutura serverless e de borda. O ganho principal não é velocidade, e sim custo operacional: um servidor sem tráfego não mantém processo nem conexão ativos.

Por que o modelo antigo travava servidores e máquinas locais

O modelo antigo de MCP obrigava cada servidor configurado a manter uma conexão dedicada com o cliente enquanto a execução durasse. Se você configurasse cinco servidores MCP e usasse zero deles em uma tarefa, ainda assim os cinco ficariam ligados. O recurso era consumido independentemente do uso real.

O problema se multiplica em agentes com subagentes. O apresentador do vídeo original relata o caso de uma execução que abria cinco subagentes: cada um inicializava seus servidores MCP, chegando a cerca de 30 conexões ativas e 30 processos locais para um único prompt. Em macOS, esse volume de processos chama a atenção do monitoramento do sistema, que passa a consumir CPU verificando o que os processos fazem.

Essa estrutura também encarecia o lado do servidor. Provedores que queriam oferecer um MCP precisavam de balanceador inteligente para garantir que a sessão voltasse sempre à mesma máquina, o que inviabiliza arquiteturas sem estado e encarece a operação ociosa.

A consequência prática foi a migração de muitos servidores MCP para execução local: hospedar na nuvem algo usado em uma fração pequena do tempo não fechava a conta. A nova especificação ataca justamente esse ponto, porque um endpoint sem estado pode ficar em repouso sem custo relevante.

O que o MCP sem estado destrava na prática

Com o núcleo sem estado, cada chamada de ferramenta é uma requisição HTTP independente, então qualquer instância pode atendê-la. Isso remove a necessidade de afinidade de sessão, libera o uso de serverless e de borda, e permite escalar horizontalmente sem coordenação entre máquinas.

O ganho aparece também no custo de ociosidade. Um servidor MCP que não recebe chamadas não mantém conexão nem processo ativo, então é possível gastar próximo de zero quando ninguém usa o serviço, em vez de pagar por conexões paradas.

Para quem publica ferramentas para agentes, o protocolo passou a ser mais fácil de auditar do que um terminal. Um conjunto de endpoints autodescritivos limita o que o agente pode fazer ao que foi exposto, enquanto um shell com acesso à internet libera praticamente qualquer ação.

Há ainda um efeito no desenvolvimento: o padrão ficou simples o bastante para testar à mão, sem agente no meio. Dá para apontar uma ferramenta de linha de comando para um servidor MCP e listar as ferramentas disponíveis, o que aproxima o protocolo de um teste de API comum.

O que a nova especificação acrescenta além do núcleo sem estado

O MCP sem estado é o centro da versão 2026-07-28, mas a especificação traz outros três avanços: autorização reforçada e extensões oficializadas nos formatos apps e tasks. São mudanças que organizam o ecossistema, ainda que tenham peso menor do que a remoção da sessão.

As extensões oficiais resolvem um problema de fragmentação. Antes, cada cliente ou servidor inventava sua forma de expor funcionalidades extras; agora existe um caminho padronizado para declarar e consumir essas capacidades.

O endurecimento da autorização importa para quem expõe dados sensíveis via MCP. Um endpoint HTTP sem estado precisa de controles próprios de autenticação e limite de uso, porque não há mais sessão implícita para carregar contexto de identidade entre chamadas.

Esses itens não substituem decisões de segurança da aplicação. Autenticação forte no endpoint, escopo mínimo por ferramenta e registro de chamadas continuam sendo responsabilidade de quem opera o servidor.

A conta que ninguém quer pagar: compatibilidade quebrada

A especificação 2026-07-28 não é compatível com implementações anteriores do lado do cliente. Um cliente que espera abrir sessão, guardar ID e rotear cada chamada para o mesmo servidor não consegue conversar com um servidor sem estado, porque o pressuposto de conexão persistente deixou de existir.

Isso cria uma ambiguidade imediata: dizer que um produto “suporta MCP” já não informa qual versão do padrão está implementada. Servidores construídos na versão antiga e clientes ainda não atualizados continuam funcionando entre si, mas não com o novo modelo.

O risco de adoção é real porque a versão antiga, mais pesada e mais cara de operar, foi amplamente implementada durante 2025. A versão nova é mais simples, mas depende de atualização do lado do cliente para produzir qualquer efeito.

A discussão sobre atualização perde força quando o próprio trabalho de migração pode ser delegado a um agente de código. Ainda assim, a decisão de atualizar ou não é de quem mantém o produto, não do padrão.

Como decidir entre MCP sem estado e um CLI para agentes

A escolha entre expor um servidor MCP sem estado e entregar um CLI ao agente depende do nível de controle que você precisa. Um terminal com acesso à rede permite quase qualquer ação; um conjunto de endpoints MCP limita o agente ao que foi publicado, com escopo verificável.

Para fluxos sensíveis, o controle granular pesa mais do que a flexibilidade. Para exploração e prototipagem, um CLI costuma ser mais rápido de montar, porque não exige definir esquema de ferramenta nem publicar endpoint.

O quadro abaixo resume as diferenças que importam na hora de escolher.

Critério	MCP sem estado (2026-07-28)	CLI para o agente
Infraestrutura	Endpoint HTTP em serverless ou borda	Processo local ou sandbox
Estado	Nenhum entre chamadas	Depende do processo em execução
Controle de escopo	Restrito às ferramentas publicadas	Amplo, limitado ao ambiente
Custo ocioso	Próximo de zero	Processo permanece ativo
Compatibilidade	Exige cliente atualizado	Depende do sistema operacional

Vale lembrar que o padrão continua sendo um projeto da Anthropic, com especificação pública e evolução rápida. Quem adota agora precisa acompanhar as versões seguintes, porque o histórico mostra mudanças estruturais em intervalos curtos.

Perguntas frequentes sobre MCP sem estado

• O que é MCP sem estado? É o modelo introduzido na especificação 2026-07-28 do Model Context Protocol, em que cada chamada de ferramenta é uma requisição HTTP independente. Não existe sessão, ID nem conexão persistente entre cliente e servidor.

• Quais são as principais vantagens do MCP sem estado? O servidor pode rodar em serverless e na borda, escala sem roteamento de sessão e não mantém processo ativo quando ninguém chama. Isso reduz custo de ociosidade e simplifica a implementação no cliente e no servidor.

• A versão 2026-07-28 é compatível com os servidores MCP antigos? Não. Clientes que esperam abrir sessão e manter a conexão viva não conseguem usar um servidor sem estado, porque o ID de sessão e o roteamento fixo deixaram de existir no novo modelo.

• O MCP sem estado substitui o uso de terminal por agentes? Não substitui. O terminal oferece mais flexibilidade, enquanto o MCP limita a ação do agente às ferramentas publicadas, o que facilita auditoria e reduz a superfície de risco em aplicações sensíveis.

• Por que o MCP foi criado? O protocolo foi apresentado pela Anthropic novembro de 2024 para padronizar a forma como agentes baseados em modelos de linguagem descobrem e chamam ferramentas externas. A quinta versão da especificação saiu em julho de 2026.

• Dá para testar um servidor MCP sem agente? Sim. Como o protocolo virou requisição e resposta, uma ferramenta de linha de comando consegue apontar para o servidor e listar as ferramentas expostas, sem nenhum agente envolvido.

• O MCP sem estado elimina a necessidade de autenticação? Não. Sem sessão implícita, cada requisição precisa carregar suas próprias credenciais, e o servidor deve aplicar escopo mínimo, limites de uso e registro de chamadas.

• A mudança vale para qualquer provedor de hospedagem? O ganho maior aparece em plataformas sem estado, como funções serverless e redes de borda. Um servidor tradicional também funciona, mas continua pagando pelo processo ocioso.

• O que observar antes de migrar um cliente para o novo padrão? Verifique se a versão do cliente suporta a especificação 2026-07-28, teste as ferramentas expostas contra um servidor sem estado e trate a migração como mudança incompatível, não como atualização incremental.

• Quem deve considerar o Bootcamp do Dev Doido? Quem quer aprender desenvolvimento com TypeScript e IA na prática, incluindo integração de agentes a APIs. O conteúdo do Crazystack Typescript cobre esses fundamentos, e vale conferir em crazystack.com.br.

Source video