MCP passa a ser sem estado: a especificação finalmente remove o último bloqueio empresarial

Uma nova revisão do Model Context Protocol elimina o requisito de sessão com estado — o elemento que tornava o MCP complicado de escalar atrás de um balanceador de carga. Pequena mudança no papel; grande na implantação.

Em termos simples. O Model Context Protocol - a especificação que permite que assistentes de IA chamem ferramentas externas - acaba de lançar uma revisão que remove a exigência de uma conexão com estado entre cliente e servidor. Essa é a mudança que as equipes de infraestrutura empresarial estavam esperando.

Por que o estado era um problema

O transporte original do MCP assumia uma sessão persistente cliente-servidor. Se seu assistente precisasse chamar uma ferramenta, o assistente e a ferramenta compartilhavam um canal ativo durante toda a interação. Funcionava bem em um laptop; era complicado em escala.

A complicação aparece assim que você coloca um balanceador de carga na frente disso. Uma sessão com estado significa que toda chamada subsequente deve ser direcionada para a mesma instância do backend. Isso inviabiliza o padrão de implantação mais barato em infraestrutura empresarial - distribuir solicitações em um pool sem estado, escalar automaticamente conforme a carga e tolerar a perda de nós. Você acaba construindo gambiarras de afinidade de sessão, roteamento fixo ou, pior, gerenciadores de conexão que se tornam pontos únicos de falha.

O que a nova especificação realmente muda

De acordo com relatos, o transporte revisado permite que os servidores anunciem um modo sem estado. Na prática:

# antes (parafraseado)
POST /mcp/sessão → session_id
POST /mcp/chamada { session_id, ferramenta, args } # deve atingir o mesmo nó
POST /mcp/fechar { session_id }

# depois - modo sem estado
POST /mcp/chamada { ferramenta, args, ctx } # qualquer nó, sem sessão

O ctx é o elemento que carrega o que o servidor precisa sobre turnos anteriores, enviado pelo cliente. É o mesmo padrão que as APIs REST adotaram vinte anos atrás - a ausência de estado comprada com solicitações ligeiramente maiores.

Por baixo dos panos: o trade-off que agora é seu

Sem estado não é de graça. Duas coisas passam a depender do cliente:

• Gerenciamento de contexto. O cliente agora é a fonte da verdade para qualquer estado por conversa que uma ferramenta precise. Payloads maiores e uma nova classe de bugs: esquecer de propagar.
• Idempotência. Uma vez que qualquer nó pode atender qualquer chamada, as tentativas de repetição se tornam possíveis em mais lugares. Os autores das ferramentas precisam tornar suas chamadas idempotentes ou lidar com duplicação de execução.

Para a maioria das implantações empresariais, esse trade-off vale a pena. Para assistentes de baixa latência, onde cada byte de ida e volta importa, é um custo real.

O que isso sinaliza

O ecossistema do MCP tem discutido sobre a infraestrutura amadurecendo de "qualidade de protótipo" para "podemos realmente colocar isso sob responsabilidade de uma equipe de SRE". O transporte sem estado é o passo concreto nessa direção. Também indica onde os autores da especificação veem o crescimento: dentro de empresas, atrás de proxies, não em máquinas individuais de desenvolvedores.

Então, o que fazer

Para um desenvolvedor: se você implantou uma integração MCP e sofreu com afinidade de sessão, a solução agora é abençoada pela especificação, não mais uma gambiarra personalizada. Para um tomador de decisão: o MCP acaba de se tornar mais amigável para aquisições. Espere que os fornecedores passem a anunciar "nativo em MCP" da mesma forma que antes anunciavam "nativo em REST".