
MCP acaba de deletar a sessão: o que a especificação de 28 de julho quebra no seu servidor
A reescrita do MCP de 28 de julho se torna sem estado. Ela corrige seu balanceador de carga e não faz nada pela conta que você realmente paga: inchaço do contexto do esquema da ferramenta.
Se você lançou um servidor MCP no último ano, você o construiu em torno de uma mentira que a especificação lhe contou: que uma conexão é algo que você pode manter. Em 28 de julho de 2026, essa suposição será deletada.
A versão candidata de 2026-07-28 foi bloqueada em 21 de maio e se torna sem estado. Sem mais initialize/initialized handshake. Sem mais cabeçalho Mcp-Session-Id fixando um cliente a um único processo. Todo o modelo "abrir uma sessão, mantê-la ativa, redirecionar tudo de volta para a mesma caixa" que todos os tutoriais ensinaram agora é legado. (Ainda é uma RC até 28 de julho, então trate os detalhes da rede abaixo como o candidato, não como o final gravado em pedra — mas as equipes de SDK já estão migrando contra isso.)
Quero fazer dois argumentos ao mesmo tempo. Primeiro: tornar-se sem estado é a decisão certa e já era hora. Segundo: isso corrige a dor operacional que todos reclamaram enquanto não faz nada pela coisa que é realmente cara sobre o MCP. Essas coisas não estão em tensão. Você pode enviar uma bela implantação round-robin e ainda assim queimar seu orçamento de token.
O que realmente mudou na rede
Aqui está o antigo caminho de solicitação. Um cliente se conecta, faz o handshake, recebe um ID de sessão e, a partir de então, cada solicitação carrega esse ID e deve aterrissar na mesma instância de servidor que o criou.
POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: 4e9c1a7f-2b3d-44a8-9f10-0c2d6a1b88ef
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search_repo","arguments":{"q":"retry"}}}
Esse Mcp-Session-Id é o imposto do balanceador de carga. Ele força sessões fixas ou um armazenamento de sessão compartilhado, porque a instância B não tem ideia do que a instância A negociou durante initialize.
O novo caminho elimina completamente a sessão. Os metadados do cliente que costumavam ser negociados uma vez na configuração da conexão agora acompanham cada solicitação em um campo _meta, e dois novos cabeçalhos obrigatórios — Mcp-Method e Mcp-Name — permitem que gateways e limitadores de taxa roteiem sem analisar o corpo JSON.
POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Method: tools/call
Mcp-Name: search_repo
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search_repo","arguments":{"q":"retry"},
"_meta":{"client":{"name":"my-agent","version":"3.1.0"}}}}
A troca de capacidades que costumava acontecer em initialize agora acontece através de uma chamada server/discover que qualquer instância pode responder. Listas e respostas de recursos também recebem ttlMs e cacheScope para que um gateway possa armazená-las em cache como HTTP. Essa última parte é mais importante do que parece — eu voltarei a isso.
Deletando o armazenamento de sessão
A migração que a maioria das pessoas subestimará é o estado do servidor. Se seu servidor se parece com isso, cada linha dele agora é peso morto:
# ANTES — com estado, estilo 2025-11-25
sessions = {} # em memória, ou pior, Redis que você agora tem que operar
def on_initialize(req):
sid = uuid4()
sessions[sid] = {"caps": req.params["capabilities"],
"client": req.params["clientInfo"]}
return {"sessionId": sid, "capabilities": SERVER_CAPS}
def on_tools_call(req, headers):
s = sessions[headers["Mcp-Session-Id"]] # KeyError na caixa errada
...
Depois, não há mapa de sessão e não há on_initialize. Cada manipulador é puro em relação à solicitação — ele lê o que precisa de _meta e responde:
Contexto Triplo UpA mudança para um modelo sem estado pode impactar significativamente a arquitetura de servidores das empresas brasileiras, permitindo uma melhor escalabilidade e eficiência. No entanto, as empresas devem se preparar para os novos custos associados ao uso do MCP, que não foram abordados pela atualização.
Noticias relacionadas
Servidor MCP 1.1.0 da endoflife.ai: Exposição KEV, verificações SBOM e dispositivos de borda para agentes de IA
O servidor MCP da endoflife.ai agora possui dez ferramentas de leitura. Novas funcionalidades incluem exposição a vulnerabilidades conhecidas e status de dispositivos de borda, essenciais para a segurança de versões de software.

O que os agentes de IA realmente veem ao buscar seu Ator Apify
O artigo explora como os agentes de IA interagem com o servidor MCP da Apify, destacando a importância da descrição e otimização dos Ators para serem encontrados. Inclui uma análise de como os resultados de busca diferem entre humanos e agentes.
Como o Protocolo de Contexto do Modelo (MCP) muda para sempre o lançamento de recursos em SaaS
O Protocolo de Contexto do Modelo (MCP) é mais do que leitura de dados; sua aplicação mais poderosa é a orquestração de aplicativos em tempo de execução, permitindo que agentes de IA gerenciem anúncios e guias de onboarding sem código efêmero.
Gostou do conteudo?
Receba toda semana as principais novidades sobre WebMCP.