Seu servidor MCP guarda em memória qual cliente abriu qual sessão. Esse é o desenho padrão desde que o protocolo apareceu, no fim de 2024: o cliente manda um "initialize", o servidor responde, os dois trocam um Mcp-Session-Id e daí em diante toda chamada carrega esse cabeçalho para o servidor saber com quem está falando. Funciona bem até você precisar escalar horizontalmente e descobrir que precisa de sessão fixa no balanceador, porque o estado da conversa mora só naquela instância.
No dia 28 de julho de 2026, os mantenedores do protocolo publicaram a especificação MCP 2026-07-28, e ela tira exatamente esse pedaço do meio. Não é ajuste cosmético: o handshake initialize/initialized some, o cabeçalho Mcp-Session-Id some, e cada requisição passa a carregar sozinha a versão do protocolo, a identidade do cliente e as capacidades que ele suporta. Segundo o post oficial, isso permite rodar o servidor "atrás de um load balancer round robin comum, sem armazenamento compartilhado".
O tamanho do que está mudando dá para medir pelo download. Os SDKs de primeira camada do MCP, TypeScript, Python, Go e C#, somam hoje perto de meio bilhão de downloads por mês, e os dois primeiros já passaram de 1 bilhão de downloads totais cada um. Não é RFC ainda em debate de comitê: é atualização de algo que várias equipes já têm rodando em produção, com todo o incômodo que isso traz.
O que sai do lugar
A troca central é essa: onde antes o servidor precisava lembrar do cliente entre chamadas, agora cada chamada se apresenta sozinha. Isso resolve um problema de infraestrutura, menos estado para gerenciar, escala mais simples, mas empurra parte da complexidade para outro lugar. Cada requisição fica um pouco mais pesada, porque carrega contexto que antes ficava implícito na sessão.
Outras mudanças vêm no mesmo pacote:
- MRTR (Multi Round-Trip Requests) substitui o modelo de requisição iniciada pelo servidor, que dependia de manter um stream aberto. Agora uma ferramenta pode pedir informação no meio da chamada devolvendo resultType "input_required", e a resposta volta em inputResponses.
- Roteamento por cabeçalho: toda chamada passa a levar Mcp-Method e Mcp-Name no header HTTP, o que deixa gateway e rate limiter decidirem a rota sem abrir o corpo JSON.
- Cache de listas: respostas de tools, prompts e resources ganham ttlMs e cacheScope, então dá para cachear sem inventar lógica própria.
- Autorização mais dura: validação de emissor pela RFC 9207 vira obrigatória, e o registro dinâmico de cliente perde espaço para documentos de metadado com ID de cliente, o CIMD, com a credencial presa ao servidor que a emitiu.
O que fica pra trás
Três recursos saem do núcleo e vão para uma extensão separada, io.modelcontextprotocol/tasks, com prazo mínimo de doze meses até o desligamento: Roots, Sampling e Logging. Se o seu servidor usa algum dos três, você tem um ano de janela, não um fim de semana. Dá tempo, mas só se você souber agora que precisa migrar, e não descobrir isso quando o cliente parar de responder.
Aqui vale um ponto que não é técnico. A gente vê muito time tratando escolha de protocolo como decisão de uma vez só: implementa, esquece, revisita só quando quebra. O MCP nasceu há menos de dois anos e já está na segunda mudança de arquitetura que afeta como você desenha o servidor. Se a sua stack de agente depende de MCP, e depois de 1 bilhão de downloads do SDK Python é bem provável que dependa, direto ou por alguma lib no meio do caminho, tratar isso como código que "só funciona" é a mesma aposta que já perdeu antes com API versionada errado ou com OAuth 1 virando OAuth 2.
O que fazer com o seu servidor
Isso não quebra da noite para o dia. Compatibilidade retroativa e negociação de versão fazem parte do protocolo desde o início, e servidor antigo continua respondendo cliente antigo. O trabalho aqui é de planejamento, não de correção de emergência.
| Se o seu servidor faz isso hoje | O que muda com a 2026-07-28 |
|---|---|
| Guarda estado de sessão em memória por Mcp-Session-Id | Pode simplificar: nenhuma chamada depende mais de sessão fixa no balanceador |
| Usa registro dinâmico de cliente para autenticar | Precisa migrar para documento de metadado com ID de cliente |
| Depende de Roots, Sampling ou Logging | Tem doze meses para mover para a extensão de tasks |
| Faz requisição server-initiated com stream aberto | Pode trocar por MRTR e fechar o stream |
Duas coisas dão para fazer já, sem esperar o resto do time decidir nada. Primeiro, checa qual versão do SDK está rodando em produção, e se ela já fala 2026-07-28 ou ainda está presa no protocolo anterior. Segundo, procura no seu código por qualquer lugar que leia Mcp-Session-Id na mão: se existir, é candidato a virar dívida técnica em pouco tempo, mesmo funcionando hoje sem reclamar.
A gente trabalha com agentes de IA e integrações que dependem desse tipo de protocolo rodando em produção, e a lição que fica de novo é a mesma. Escolher a ferramenta certa não é decisão de uma vez, é manutenção contínua. Quem trata protocolo de agente como configuração estática vai ser pego de surpresa na próxima mudança, que também não vai vir com aviso grande.
