MCP Torna-se Sem Estado: O Que o RC de 2026-07-28 Significa para Servidores

O candidato a release do Model Context Protocol 2026-07-28 é a primeira revisão do MCP que deve fazer com que servidores remotos se sintam como uma infraestrutura HTTP comum, em vez de uma infraestrutura de sessão fixa com JSON-RPC dentro dela.

Esse é o modelo mental útil para desenvolvedores. Implantações anteriores de HTTP Streamable ainda podiam depender de um handshake de inicialização, um Mcp-Session-Id e suposições baseadas em conexão. O RC de 2026-07-28 remove a sessão em nível de protocolo e move os metadados do protocolo para cada solicitação. Ele também formaliza cabeçalhos de solicitação, como Mcp-Method, adiciona dicas de cache, como ttlMs e cacheScope, move Tarefas para uma extensão oficial e reforça o comportamento do OAuth em torno da validação do emissor.

A Effloow Lab executou um PoC local apenas com a biblioteca padrão para este artigo. O PoC não usou um SDK oficial do MCP e não reivindica conformidade. Ele validou a forma da migração: uma solicitação alcançou qualquer trabalhador simulado sem uma sessão, a incompatibilidade de cabeçalho/corpo retornou um erro estruturado, tools/list retornou metadados de cache, e uma tarefa criada pelo trabalhador B foi consultada pelo trabalhador A através de um identificador de tarefa explícito. Evidências estão salvas em data/lab-runs/mcp-stateless-http-2026-07-28-rc-production-guide.md.

Por Que Este RC É Importante

O blog oficial do MCP diz que o candidato a release se tornou disponível em 21 de maio de 2026, com a especificação final planejada para 28 de julho de 2026. Ele descreve o RC como um núcleo de protocolo sem estado com extensões de primeira classe, Tarefas, Aplicativos MCP, reforço de autorização e uma política formal de descontinuação.

Isso é mais do que uma limpeza. Servidores MCP estão sendo cada vez mais implantados como serviços remotos atrás de gateways, proxies reversos, balanceadores de carga e sistemas de observabilidade. Se um servidor MCP requer que a solicitação dois chegue ao mesmo processo que lidou com a solicitação um, os operadores precisam de roteamento fixo ou um armazenamento de sessão de protocolo compartilhado. Esses são problemas solucionáveis, mas desnecessários para muitos servidores de ferramentas.

O RC muda a arquitetura padrão. Cada solicitação pode carregar a versão do protocolo, a identidade do cliente e as capacidades do cliente em _meta. O HTTP Streamable pode espelhar campos relevantes de roteamento em cabeçalhos. O estado da aplicação ainda existe, mas se move para identificadores explícitos: um workspace_id, basket_id, task_id, browser_id ou outro identificador gerado pelo servidor que o modelo retorna como um argumento normal da ferramenta.

Essa é a distinção importante: o MCP está se tornando sem estado no nível do protocolo, sem fingir que aplicações reais não têm estado.

O Que a Effloow Lab Verificou

O sandbox local usou a biblioteca padrão do Python para iniciar um endpoint HTTP temporário em 127.0.0.1. Cada solicitação do cliente incluía:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/list
Accept: application/json, text/event-stream

O corpo JSON-RPC carregava valores correspondentes de _meta:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "effloow-lab",
        "version": "0.1"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/tasks": {
            "version": "draft"
          }
        }
      }
    }
  }
}

A saída útil não foi o próprio servidor de brinquedo. Foi o comportamento:

discover_status= 200
tools_cache= {'ttlMs': 30000, 'cacheScope': 'public'}
mismatch_status= 400
mismatch_error= HeaderMismatch
task_create_status= 202
task_created_by= B
task_get_status_value= completed
task_polled_by= A
task_result_text= sandbox result

Essa saída prova apenas um ponto de design local. Não prova compatibilidade com a especificação final, segurança do OAuth, comportamento do SSE, suporte a SDK ou interoperabilidade do cliente. Mostra por que o RC é operacionalmente atraente: o estado da sessão em nível de protocolo não é mais necessário para o caso simples em que cada solicitação é auto-descritiva e o estado da tarefa é armazenado atrás de um identificador explícito.

A Principal Mudança Quebradora: Sem Sessão de Protocolo

O changelog do rascunho lista duas mudanças principais relacionadas: remover sessões em nível de protocolo e remover o handshake initialize / notifications/initialized. A forma de solicitação mais antiga estabelecia uma sessão de protocolo primeiro, e então enviava solicitações subsequentes com Mcp-Session-Id. Na forma do RC, uma solicitação tools/call pode se sustentar sozinha.

Para um servidor de produção, isso afeta quatro áreas.

Primeiro, balanceadores de carga não precisam mais manter o mesmo cliente preso ao mesmo trabalhador por razões de protocolo. Você ainda pode optar por roteamento fixo para desempenho da aplicação, mas o protocolo em si não deve forçá-lo.

Segundo, a escalabilidade horizontal se torna mais fácil de entender. Se o trabalhador A falhar, o trabalhador B ainda pode processar a próxima solicitação, desde que qualquer estado de aplicação necessário esteja em um banco de dados, cache, armazenamento de objetos, motor de fluxo de trabalho ou identificador explícito comum.

Terceiro, a lógica de compatibilidade se torna mais importante. Um servidor sério pode precisar rejeitar versões de protocolo não suportadas com erros claros, aceitar apenas versões que realmente implementa e manter testes de migração para formas de solicitação antigas e novas.

Quarto, estado oculto se torna um cheiro de design. Se uma ferramenta depende de um cliente ter chamado anteriormente outro método, a dependência deve ser visível no esquema ou argumentos. Modelos são melhores em usar visibilidade.