MCP fica stateless e desenvolvedores perguntam se isso o transforma em API comum

A nova versão da especificação do Model Context Protocol, identificada como 2026-07-28, promove a maior mudança estrutural do protocolo desde o lançamento: o núcleo do MCP passa a ser stateless. Na prática, o handshake initialize e initialized desaparece, assim como o header de sessão que antes amarrava um cliente a uma instância específica de servidor. A notícia, publicada pelo InfoQ, repercutiu entre desenvolvedores com uma pergunta provocativa: sem sessão e sem estado, o MCP vira apenas mais uma API HTTP?

O que muda na especificação

A revisão remove duas peças centrais do modelo anterior. A primeira é o handshake de inicialização, que estabelecia capacidades e versão entre cliente e servidor antes de qualquer chamada (mudança descrita na proposta SEP 2575). A segunda é o header Mcp Session Id, que identificava a sessão e exigia afinidade de conexão entre cliente e instância de servidor (proposta SEP 2567). Sem esse header, qualquer requisição pode ser atendida por qualquer réplica do servidor, o que destrava escalabilidade horizontal de verdade.

No lugar do estado, entram dois headers obrigatórios em toda requisição Streamable HTTP: Mcp Method e Mcp Name (proposta SEP 2243). Eles carregam o método invocado e o nome da ferramenta de forma explícita, fora do corpo da mensagem. A consequência prática é direta: gateways, balanceadores de carga, WAFs e rate limiters passam a rotear, medir e limitar o tráfego de agentes inspecionando apenas headers HTTP, sem precisar decodificar o corpo JSON RPC de cada chamada.

A versão também deprecia partes antigas do protocolo. Roots, Sampling, Logging e o transporte legado HTTP com SSE entram em desuso. Clientes e servidores antigos podem continuar operando em versões anteriores do protocolo até que ambos os lados negociem a nova, o que evita quebra imediata de ecossistemas já em produção.

Por que isso importa para infraestrutura

O modelo stateful anterior criava problemas reais de operação. Como a sessão fixava o cliente em uma instância, escalar servidores MCP exigia sticky sessions, drenagem cuidadosa em deploys e trabalho extra para failover. Com o núcleo stateless, o tráfego de agentes passa a se comportar como tráfego HTTP comum: réplicas atrás de um balanceador, autoscaling por demanda, rolagem de deploy sem cerimônia. O Google, em análise sobre a mudança, destacou exatamente esse ponto, o desbloqueio de escala horizontal e de roteamento HTTP padrão para infraestrutura de agentes.

A roteabilidade por headers também muda o jogo para segurança e observabilidade. Políticas de rate limit por ferramenta, bloqueio de métodos sensíveis no WAF e métricas por endpoint deixam de depender de parsers específicos do protocolo e passam a usar mecanismos que qualquer equipe de plataforma já domina.

O debate: vantagem ou perda de identidade

A reação da comunidade se dividiu. De um lado, desenvolvedores celebram a simplificação operacional e a aderência aos padrões HTTP, que reduz a barreira para colocar servidores MCP atrás de gateways corporativos existentes. De outro, há quem questione se o protocolo não está abrindo mão do que o diferenciava. Recursos que dependiam de contexto de sessão, como elicitações e comportamentos stateful, precisam ser repensados, e críticos argumentam que um MCP stateless se aproxima tanto de uma API REST comum que a justificativa para adotar o protocolo em vez de endpoints HTTP diretos fica mais fraca.

A resposta pragmática que emerge da discussão é que o valor do MCP nunca esteve apenas no transporte, e sim no contrato: descoberta de ferramentas, schemas estruturados de entrada e saída e um ecossistema de clientes e servidores interoperáveis. Tornar o transporte stateless remove atrito de infraestrutura sem abandonar esse contrato. Ainda assim, o debate é legítimo e sinaliza que a governança do protocolo terá que provar que os recursos além do básico continuam relevantes.

Como isso pode ser útil para você

Se você mantém servidores MCP em produção ou planeja expor ferramentas para agentes, essa mudança altera decisões concretas de arquitetura. Comece a desenhar seus servidores sem assumir afinidade de sessão: estado que hoje vive em memória precisa migrar para armazenamento externo, como Redis ou banco, ou ser reconstruído a cada requisição. Aproveite os novos headers para configurar rate limiting e roteamento por ferramenta direto no gateway que sua equipe já opera, em vez de criar camada própria. Para quem trabalha com consultoria ou quer gerar renda, há uma janela clara de oportunidade: empresas que adotaram MCP cedo vão precisar migrar implementações stateful para o novo modelo, e dominar essa transição, incluindo os deprecations de Roots, Sampling e do transporte SSE legado, é um diferencial técnico vendável. Mesmo em projetos pessoais, servidores stateless são mais baratos de hospedar, já que cabem em plataformas serverless e escalam a zero.

Fonte: https://www.infoq.com/news/2026/08/mcp-stateless-gateway/