Voltar as noticias
MCP acaba de deletar a sessão: o que a especificação de 28 de julho quebra no seu servidor
Compartilhar
MCP ProtocolAltaEN

MCP acaba de deletar a sessão: o que a especificação de 28 de julho quebra no seu servidor

Fonte original: Dev.to - MCP·28 de junho de 2026

Curadoria, tradução e análise: Redação Triplo Hub.

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:

Análise editorial da Triplo Hub

A 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.

Compartilhar
Seguir @triploup

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.