A revisão de 28 de julho de 2026 do Model Context Protocol faz mais do que as manchetes sugerem. Sim, ela remove as sessões de protocolo — um ganho genuíno de escalabilidade. Mas a mesma versão adiciona dois headers HTTP obrigatórios, Mcp-Method e Mcp-Name, que permitem que gateways roteiem, apliquem rate limit e meçam o tráfego de agentes sem precisar abrir o corpo da requisição. A thread do Hacker News se dividiu de forma acirrada — não sobre se a ausência de estado é uma melhoria, mas sobre o que ela revela. “Inventamos um protocolo stateful, descobrimos que estado é difícil de escalar, removemos tudo e acabamos com: envie uma requisição POST”, escreveu um comentarista. “A turma do REST está esperando esse momento há 20 anos.”
Como o MCP funcionava antes: sessões como um imposto de escalabilidade
O transporte inicial começava com as trocas de mensagens initialize e initialized, estabelecendo uma sessão rastreada pelo header Mcp-Session-Id. Cada requisição subsequente precisava encontrar o estado associado àquela sessão. A infraestrutura de auto-scaling precisava fixar sessões, os deploys precisavam drená-las ou migrá-las, e o balanceamento de carga era impraticável porque um cliente ficava preso à instância que mantinha sua sessão.
O novo protocolo remove o handshake, o header de sessão e a sessão de protocolo do caminho principal de requisições. Cada requisição carrega a versão do protocolo, a identidade do cliente e as capacidades de que precisa. Qualquer requisição pode cair em qualquer instância.
A mudança maior e silenciosa: metadados na camada de transporte
Menos atenção foi dada ao que aconteceu com a requisição em si. As mensagens do MCP são JSON-RPC sobre HTTP, e antes tudo sobre uma requisição vivia no corpo JSON — um gateway precisava parsear o corpo para saber se a requisição listava ferramentas, chamava uma delas ou lia um recurso. Agora, as requisições Streamable HTTP devem incluir dois 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. Como detalhou Matt Carey, da Cloudflare, gateways, rate limiters e WAFs podem ler esses headers e agir por método ou por ferramenta, usando os mesmos mecanismos que já aplicam a qualquer outra API. A especificação vai além — argumentos de ferramentas podem até ser copiados para headers para roteamento customizado.
A governança está descendo na stack
Até agora, a governança de agentes vinha da direção oposta. O agent tracing da Cloudflare e a camada AI Gateway do Azure API Management ficam acima do protocolo como planos de controle separados. Esta versão coloca os metadados no próprio transporte, para que os sistemas que as equipes de infraestrutura já operam consigam lê-los. É nessa mesma camada de governança que colisões entre múltiplos agentes compartilhando um mesmo codebase serão resolvidas — um problema que os próprios experimentos multi-agente da Anthropic mostraram estar longe de solucionado.
A elicitação foi repartida. Requisições iniciadas pelo servidor antes exigiam um stream aberto; agora usam requisição/resposta em múltiplas rodadas — o servidor retorna input_required, o cliente coleta as respostas e refaz a chamada. As aprovações passaram de uma conexão keep-alive para duas requisições: mais simples de implantar, mas a espera por uma resposta humana não vive mais dentro de uma única chamada.
A autorização também ficou mais rígida: o registro dinâmico de clientes foi descontinuado e está programado para remoção após o verão de 2027, a identificação de issuer adota o RFC 9207, e os clientes enviam o URI canônico do servidor como um resource do RFC 8707, de modo que tokens só sejam aceitos por aquele audience.
O debate: o MCP é só REST com etapas extras?
O debate no HN é a parte interessante. Um grupo diz que o MCP stateful foi, em retrospecto, claramente um erro — transformou o MCP em mais um endpoint de API REST, permitindo que as equipes reaproveitassem os load balancers, API gateways e entrega progressiva que já haviam construído. pjmlp enquadrou isso como uma lição que a indústria fica reaprendendo, desde o Sun RPC: servidores stateless são sempre melhores; só use estado quando inevitável. luciana1u foi mais direta: “Inventamos um protocolo stateful, descobrimos que estado é difícil de escalar, removemos tudo e acabamos com: envie uma requisição POST.” bloppe foi estrutural — MCP é uma API estilo REST, mais uma especificação que o OpenAPI já poderia fornecer, mais autorização em nível de framework; apenas o terceiro é genuinamente novo.
Os defensores não negam a semelhança; discordam da conclusão. “O MCP é na verdade só JSON-RPC; o que foi realmente inventado é uma convenção que os modelos já foram treinados a usar.” vidarh resumiu melhor: a vantagem central do MCP é ser um padrão endossado pelos provedores de IA, o que dá às pessoas um forte incentivo para implementá-lo de fato.
Uma thread paralela perguntou se os agentes precisam de um protocolo — basta dar a eles acesso shell a ferramentas de linha de comando comuns. A contraponto: a posição do CLI pressupõe um desenvolvedor num laptop com um shell aberto num ambiente de codificação, o que descreve uma pequena fatia do uso. A maior parte vem de apps móveis, chat na web e componentes embarcados.
Para onde o dinheiro está indo: o sinal real
A adoção não está em disputa — a Anthropic reporta mais de 400 milhões de downloads mensais dos SDKs do MCP, o triplo no último ano. Se a adoção beneficia os servidores individuais é outra questão. A auditoria de uma consultoria em um servidor de um cliente encontrou 61 chamadas de ferramentas em três meses, 58 delas feitas pelos próprios engenheiros do cliente. As equipes trataram “agentes podem acessar” como “agentes querem acessar”. A conclusão do post ecoa esta versão: o dinheiro está fluindo para gateways, registries e camadas de identidade, não para os servidores em si.
Essa é a mudança estrutural que vale acompanhar. À medida que o tráfego de agentes se torna uma workload real, o valor se concentra no plano de controle — roteamento, medição, autenticação — enquanto o protocolo em si converge de volta para o tooling HTTP comum que a indústria opera há duas décadas. A contribuição do MCP nunca foi o formato na rede; foi transformar o acesso de agentes a ferramentas em um padrão ao qual modelos e provedores se comprometem.
O que fazer se você roda MCP em produção
A migração é um trabalho real para equipes que dependem de sessões de protocolo, requisições servidor-para-cliente ou streams. A especificação e os SDKs atualizados de TypeScript, Python, Go e C# já estão disponíveis. O caminho recomendado: rodar uma rota stateless em paralelo ao roteamento stateful existente, migrar as capacidades, drenar as sessões ativas e remover o caminho antigo dentro da janela de descontinuação. Enquanto isso, comece a tratar Mcp-Method e Mcp-Name como sinais de primeira classe nas suas configurações de gateway e rate limiter — é para aí que a indústria está indo. E se você opera infraestrutura de agentes, audite o uso real das ferramentas antes de presumir que seus agentes estão sendo utilizados; nossa análise do experimento multi-agente da Anthropic mostra a velocidade com que agentes alinhados começam a brigar pelo mesmo codebase.
