O MCP acabou de fazer sua maior mudança desde a chegada dos servidores remotos: ele removeu as sessões. A especificação de 2026-07-28 transforma o Model Context Protocol de um protocolo bidirecional e stateful em um protocolo stateless de requisição/resposta. Chega de handshake de inicialização, chega de header Mcp-Session-Id, chega de prender um cliente à instância que guarda sua sessão. Agora, qualquer requisição pode cair em qualquer instância atrás de um load balancer simples de round-robin.
Só essa manchete já seria suficiente para uma release note. Mas a mesma versão trouxe de carona algo mais discreto e, possivelmente, ainda maior: dois headers HTTP obrigatórios que permitem que gateways roteiem, limitem e meçam o tráfego de agentes sem nunca abrir o corpo da requisição. O tráfego de agentes acabou de virar HTTP comum — e os times de infraestrutura acabaram de recuperar sua caixa de ferramentas de sempre.
O que mudou: as sessões sumiram, os headers carregam o peso
Os primeiros transports do MCP começavam com uma troca initialize/initialized que estabelecia uma sessão, rastreada via Mcp-Session-Id. Cada requisição subsequente precisava encontrar o estado ligado a essa sessão. Infraestrutura com auto-scaling tinha que manter as sessões vivas, deploys precisavam drená-las ou migrá-las, e o balanceamento de carga era praticamente impossível porque o cliente ficava preso à instância que guardava sua sessão.
A nova spec remove o handshake, o header de sessão e as sessões em nível de protocolo do caminho central de requisições. Cada requisição agora carrega sua versão do protocolo, identidade do cliente e capacidades em _meta. Um cliente que quer as capacidades de antemão pode fazer uma chamada opcional server/discover, mas nada exige isso. As requisições são totalmente autodescritivas.
A mudança menos perceptível: requisições Streamable HTTP agora devem incluir os headers Mcp-Method e Mcp-Name. Uma chamada de ferramenta chega como Mcp-Method: tools/call e Mcp-Name: search, seguida do payload JSON-RPC. Gateways, rate limiters e WAFs podem ler esses headers e agir por método ou por ferramenta, usando exatamente os mecanismos que já rodam para qualquer outra API. Alguns implementadores vão além, copiando os argumentos das ferramentas para os headers e permitindo roteamento customizado.
Governança migra para a camada de transporte
Até agora, a governança de agentes crescia em uma direção separada: o agent tracing da Cloudflare e o tier AI Gateway do Azure API Management ficam acima do protocolo como um control plane independente. Esta release coloca os metadados no próprio transporte, de forma que os sistemas que os times de infraestrutura já operam consigam lê-los. A observabilidade de agentes deixa de ser um universo paralelo e vira uma coluna no dashboard existente.
A elicitation também foi repartida. Requisições iniciadas pelo servidor antes exigiam um stream aberto; agora usam requisições com múltiplos round-trips. O servidor retorna input_required, o cliente coleta a resposta e refaz a chamada. Uma aprovação que era uma única conexão aberta agora são duas requisições — mais simples de implantar, embora a espera do human-in-the-loop não viva mais dentro de uma única chamada.
A autorização também ficou mais rígida: o registro dinâmico de clientes foi descontinuado (remoção planejada depois do verão de 2027), a identificação do issuer migra para o RFC 9207, e os clientes enviam um URI de recurso com escopo para que tokens sejam aceitos apenas pelo público-alvo pretendido. O trabalho de segurança open-source segue uma onda semelhante de endurecimento — o GLM-5.3 mostrou o que modelos abertos conseguem fazer em benchmarks de segurança — e o MCP agora aplica essa mesma disciplina à identidade.
Isso é só REST com etapas extras?
O debate no Hacker News se dividiu de forma acentuada — não sobre se a ausência de estado é uma melhoria, mas sobre o que ela revela. Um campo diz que isso confirma que o protocolo nunca deveria ter sido stateful. Como colocou o drdexebtjl: “Em retrospecto, o MCP stateful foi claramente um erro. Isso efetivamente transforma o MCP em mais um endpoint de API REST, permitindo usar a mesma infraestrutura que você já construiu para REST — load balancers, API gateways, rollout progressivo.” Outro comentarista foi mais direto: “Inventamos um protocolo stateful, descobrimos que estado é difícil de escalar, removemos o estado e acabamos com ‘apenas envie um POST’. A turma do REST esperou 20 anos por esse momento.”
Os defensores não negam a semelhança; eles discordam da conclusão. O MCP é JSON-RPC por baixo — o que de fato foi inventado é uma convenção que os modelos foram treinados a usar. Como resumiu o vidarh: “A principal vantagem que o MCP traz é que ele é um padrão endossado pelos provedores de IA, então há um forte incentivo para realmente implementá-lo.”
O enquadramento que se encaixa: o MCP não é REST com etapas extras. É uma camada de roteamento para chamadas de ferramentas nativas de modelos — e camadas de roteamento sempre acabam stateless, cacheáveis e amigáveis a gateways. O protocolo amadureceu; só amadureceu na direção que a web já havia pavimentado.
O que isso sinaliza para o stack de agentes
A adoção não está em discussão: a Anthropic reporta mais de 400 milhões de downloads mensais dos SDKs do MCP, um triplo no ano. Mas a escala corta dos dois lados. Uma auditoria de consultoria no r/AI_Agents descobriu que o servidor MCP de um cliente registrou 61 chamadas de ferramentas em três meses — 58 delas vindas dos próprios engenheiros do cliente. A conclusão do post ecoa esta release: “O dinheiro está indo para gateways, registros e camadas de identidade, não para os servidores em si.”
A ausência de estado empurra no mesmo sentido. Quando qualquer requisição pode atingir qualquer instância, o valor se concentra na camada na frente dos servidores: roteamento, rate limiting, medição, autenticação. O protocolo acabou de tornar essa camada endereçável com ferramentas HTTP padrão — uma mudança estrutural, não um ajuste de funcionalidade. Isso também se encaixa no padrão mais amplo de amadurecimento acelerado da infraestrutura de agentes, do blueprint da DeepSeek para agentes autoevolutivos até a própria camada de protocolo. Para os times que rodam MCP em produção, o caminho de migração é real, mas limitado: rodar uma rota stateless ao lado do roteamento legado de sessões, drenar as sessões ativas e remover o caminho antigo dentro da janela de descontinuação.
O que fazer agora
- Se você opera servidores MCP: planeje a migração para 2026-07-28. A spec mantém os transports antigos funcionando por pelo menos doze meses, mas o tráfego novo deve migrar cedo para as rotas stateless.
- Se você opera um gateway ou WAF: comece a rotear e medir com base em Mcp-Method / Mcp-Name. Essa é a nova superfície de controle do tráfego de agentes.
- Se você constrói agentes: espere que os catálogos de ferramentas se tornem respostas de listas cacheáveis — os clientes podem cachear as listas de ferramentas e manter os caches de prompt estáveis entre reconexões.
- Se você observa o mercado: observe a camada de governança. O valor no stack de agentes está se consolidando exatamente onde esta spec aponta: gateways, identidade e transporte.
O MCP stateless é uma história de amadurecimento com um fio de ironia: o protocolo em que todo mundo apostou acabou de admitir que precisa se comportar como qualquer outra API — e essa admissão é precisamente o que o torna implantável em escala empresarial.
