MCP Se Torna Stateless na Sua Maior Atualização de Protocolo

A Anthropic lançou a especificação MCP 2026-07-28 em 28 de julho — a maior revisão desde que o protocolo foi lançado em novembro de 2024 — e ela muda fundamentalmente como o MCP funciona: o protocolo agora é stateless. Chega de handshakes initialize, chega de headers Mcp-Session-Id, chega de sessões fixas no load balancer. Cada requisição agora carrega sua própria versão de protocolo, identidade do cliente e capacidades em _meta. Qualquer requisição pode cair em qualquer instância de servidor atrás de um load balancer round-robin simples. Esta é a atualização que torna o MCP infraestrutura empresarial pronta para produção.

O que aconteceu

O núcleo stateless é a manchete, mas a especificação 2026-07-28 traz seis grandes mudanças de uma vez:

• Sem handshake ou sessões. A troca initialize/initialized e o header Mcp-Session-Id foram aposentados. Cada requisição é autodescritiva — clientes que precisam das capacidades do servidor antecipadamente chamam o novo RPC server/discover, mas é opcional. Servidores MCP agora podem rodar em implantações Kubernetes convencionais com load balancers padrão e sem stores Redis compartilhadas (Anthropic, 2026).
• Multi Round-Trip Requests (MRTR). Interações servidor-para-cliente como elicitação e sampling não exigem mais um stream SSE mantido aberto. O servidor retorna resultType: "input_required" com um token opaco requestState, e o cliente repete a chamada original com as respostas do usuário. Qualquer instância de servidor pode atender a repetição (Anthropic, 2026).
• Roteamento baseado em headers. Toda requisição Streamable HTTP agora expõe Mcp-Method e Mcp-Name em headers padrão. API gateways, rate limiters e WAFs podem rotear, limitar e medir apenas pelos headers — sem necessidade de parse de corpo JSON (Anthropic, 2026).
• Resultados de listagem cacheáveis. As respostas de tools/list, prompts/list e resources/list agora carregam dicas de ttlMs e cacheScope. Clientes podem cachear catálogos de ferramentas sem manter conexões persistentes abertas para notificações de mudança (Anthropic, 2026).
• Endurecimento de autorização. Validação de issuer RFC 9207, vinculação de credencial de cliente ao servidor de autorização emissor, e uma descontinuação formal do Dynamic Client Registration (DCR) em favor de Client ID Metadata Documents (CIMD). O framework de autenticação agora se alinha com padrões de produção OAuth 2.0 e OpenID Connect nos quais as equipes de segurança empresarial já confiam (Anthropic, 2026).
• Framework formal de extensões. Capacidades como Tasks, MCP Apps e Enterprise Managed Authorization (EMA) agora vivem como extensões governadas com seus próprios IDs reverse-DNS e cadências de lançamento — independentes da especificação principal. Isso evita a fragmentação que atormentou versões anteriores (Anthropic, 2026).

Todos os quatro SDKs Tier 1 — TypeScript, Python, Go e C# — foram lançados com suporte ao 2026-07-28 no dia do lançamento. O SDK Rust chegou em beta.

O ecossistema se moveu rápido. O AWS AgentCore Gateway(abre num novo separador) lançou suporte no dia um com um único toggle de configuração UpdateGateway — adicione "2026-07-28" ao supportedVersions do seu gateway e os clientes existentes continuam funcionando sem alterações (AWS, 2026). A Microsoft lançou o .NET C# SDK v2.0(abre num novo separador) visando a nova especificação. O GitHub's MCP Server(abre num novo separador) lançou suporte cinco dias antes da especificação. Cloudflare, Google Cloud, Supabase e FastMCP anunciaram suporte no dia zero.

Por que isso importa

O MCP acaba de resolver a maior barreira à adoção empresarial: a arquitetura vinculada a sessão que tornava o escalonamento horizontal um pesadelo prático. Antes do 2026-07-28, toda interação MCP começava com um handshake que fixava o cliente a uma instância específica de servidor. Escalar significava sessões fixas no load balancer, stores de sessão compartilhadas ou inspeção profunda de pacotes — tudo isso incomodava as equipes de operações que aprovam implantações de produção.

Agora um servidor MCP é um endpoint HTTPS padrão. Funciona atrás de qualquer load balancer. Funciona bem com API gateways, CDNs e service meshes. O protocolo amadureceu para algo que uma equipe de plataforma empresarial pode realmente operar.

O framework de extensões é quase tão importante quanto a ausência de estado. Ao desacoplar capacidades como Tasks e autorização da especificação principal, o MCP agora pode evoluir sem forçar mudanças coordenadas que quebram compatibilidade em todo o ecossistema. A AWS contribuiu com a extensão Tasks; Cloudflare, Anthropic e outros estão lançando as suas próprias. Foi assim que o HTTP cresceu — e é o modelo certo para um protocolo com meio bilhão de downloads de SDK por mês.

A política de descontinuação também importa: Roots, Sampling, Logging e o transporte legado HTTP+SSE estão descontinuados com uma janela mínima de doze meses. Você planeja upgrades em vez de reagir a eles.

O que muda para você

Se você roda servidores MCP em produção: Você pode abandonar sessões fixas e stores Redis compartilhadas. Migre para os novos SDKs — o transporte stateless elimina toda uma classe de complexidade operacional. A janela de descontinuação lhe dá tempo, mas o ganho arquitetural de se tornar stateless é imediato.

Se você mantém um cliente MCP: Audite dependências de Mcp-Session-Id, chamadas logging/setLevel e o código de erro literal -32002 (agora -32602). Verifique se seu cliente declara as capacidades corretas — um cliente que omite as obrigatórias é rejeitado com código -32021 no novo caminho.

Se você está avaliando o MCP para um novo projeto: Comece no 2026-07-28. Os SDKs Tier 1 estão prontos. O AWS AgentCore Gateway suporta modo de versão dupla — você pode servir clientes antigos e novos simultaneamente enquanto migra. Não há razão para construir nova infraestrutura na especificação 2025 vinculada a sessão.

Se você usa o AWS AgentCore Gateway: Uma chamada UpdateGateway adiciona 2026-07-28 ao seu supportedVersions. Seus clientes existentes, definições de ferramentas e configuração de autenticação permanecem inalterados.

FAQ

Isso é retrocompatível? Não — a especificação 2026-07-28 é incompatível com versões anteriores por design. Mas é opt-in: os clientes selecionam a versão do protocolo por requisição via header MCP-Protocol-Version. Gateways podem anunciar múltiplas versões simultaneamente, então clientes existentes continuam funcionando enquanto você migra. Os mantenedores do protocolo declararam que esta deve ser a última revisão que quebra compatibilidade.

O que está descontinuado e quando deixará de funcionar? Roots, Sampling e Logging estão descontinuados, junto com o transporte legado HTTP+SSE e Dynamic Client Registration (DCR). Todos permanecem funcionais por pelo menos doze meses a partir da data de publicação da especificação. Novas implementações não devem adotá-los.

Quais SDKs suportam a nova especificação? TypeScript, Python, Go e C# (Tier 1) foram lançados com suporte ao 2026-07-28 no dia do lançamento. O SDK Rust suporta em beta. Consulte a documentação do SDK MCP(abre num novo separador) para a lista de tiers atual.