MCP ficou sem estado: 5 alterações que a especificação 2026 faz em seu servidor

O candidato a lançamento do Model Context Protocol foi bloqueado em 21 de maio de 2026. Ele é enviado como versão 2026-07-28 em 28 de julho, e a mudança no título reescreve como cada servidor lida com um solicitação: o MCP não tem estado na camada de protocolo. Não initialize aperto de mão, não Mcp-Session-Id, sem roteamento fixo. Qualquer solicitação pode chegar a qualquer instância.

Se você executar um servidor MCP atrás de um balanceador de carga, isso removerá a única parte da infraestrutura isso tornava o escalonamento horizontal irritante: o armazenamento de sessões compartilhadas. Aqui estão as cinco mudanças que assunto e as edições de transporte exatas que você precisa antes que os clientes comecem a enviar a nova versão.

1. O núcleo sem estado remove o aperto de mão

O transporte 2025 abriu com um initialize/initialized intercâmbio. O servidor cunhou uma sessão, devolveu um Mcp-Session-Id, e o cliente repetiu isso cada solicitação posterior. Essa sessão tinha que estar em algum lugar tanto no balanceador de carga quanto no servidor poderia alcançar, então você executou sessões fixas ou uma loja compartilhada.

O transporte de 2026 exclui tudo. Metadados de protocolo que costumavam residir na sessão agora cavalga em um _meta campo em cada solicitação. Os clientes leem recursos por meio de um novo server/discover método em vez de lê-los uma vez no momento da conexão. O resultado: nenhum objeto de sessão para perder, nenhuma instância para fixar.

2. O roteamento passa para os cabeçalhos de solicitação

Como não há sessão para inspecionar, a especificação adiciona Mcp-Method e Mcp-Name solicitar cabeçalhos para que um proxy possa rotear sem analisar o corpo JSON-RPC. UM tools/call para dns_lookup carrega ambos no cabeçalho, e sua borda pode envie ferramentas pesadas para um pool maior sem desserializar nada.

Você pode confirmar se um servidor implantado fala o novo transporte inspecionando o que ele retorna para um pedido simples. O endpoint botoi headers mostra o status da resposta e os cabeçalhos de qualquer URL, então você pode verificar o endpoint de um MCP Allow e cabeçalhos CORS sem escrever um cliente:

3. O estado sobrevive por meio de identificadores explícitos

Transporte sem Estado não significa ferramentas sem Estado. Um trabalho de longa duração ainda precisa rastrear progresso. A resposta da especificação é o padrão de manipulação explícito: uma chamada de ferramenta retorna um ID, o modelo passa esse ID de volta na próxima chamada, e o estado fica no seu armazenamento de dados digitado pelo identificador. Qualquer instância pode servir o acompanhamento porque a solicitação contém a chave.

Esta é a mesma forma que uma API REST usa. A solicitação carrega tudo que o servidor precisa, então você dimensione adicionando pods, não sincronizando sessões. O servidor botoi MCP já roda desta forma: sem estado, um novo manipulador por solicitação, a chave de API encaminhada nos cabeçalhos.

4. Graduação em tarefas, extensões e aplicativos MCP

Três características são formalizadas nesta revisão:

• Tarefas mudou de um recurso principal experimental para uma extensão com um limpador ciclo de vida. Os clientes impulsionam o progresso com tasks/get, tasks/update, e tasks/cancel em vez do antigo design de votação.
• Extensões agora carregam identificadores de DNS reverso, negociam por meio de capacidade mapas, versões independentes e seguem seu próprio caminho de Proposta de Melhoria de Especificação. Você enviar um recurso sem esperar por um lançamento principal.
• Aplicativos MCP deixe um servidor retornar HTML interativo renderizado em um iframe em área restrita. Cada ação da UI passa pelo mesmo caminho de auditoria que uma chamada de ferramenta, portanto, um clique no botão é registrado e com permissão verificada como qualquer outra operação.

5. A autorização é reforçada em torno da RFC 9207

Seis SEPs reforçaram o alinhamento do OAuth 2.0 e do OpenID Connect. A mudança que você não pode pular: validar o iss parâmetro de acordo com RFC 9207. Sem ele, um invasor pode injetar um código de autorização cunhado por um servidor em um fluxo para outro, uma classe de ataque entre servidores que atinge qualquer implantação executando mais de um servidor MCP por trás de autenticação compartilhada. A especificação também esclarece a rotação do token de atualização e alerta contra o acúmulo silencioso de escopo através do consentimento telas.

Sua lista de verificação de migração

• Elimine o armazenamento de sessão. Pare de cunhar e ler Mcp-Session-Id. Ler metadados de protocolo de _meta em cada solicitação.
• Adicione cabeçalhos de roteamento. Emitir e aceitar Mcp-Method e Mcp-Name então seu proxy é roteado sem analisar o corpo.
• Converta sessões em identificadores. Retorne um ID de ferramentas com estado e digite seu armazene nele. Qualquer instância responde ao acompanhamento.
• Adicione a verificação iss. Valide o emissor do servidor de autorização de acordo com RFC 9207 em cada troca de token.
• Fixar em 2026-07-28. Construa contra o RC agora; está com recursos congelados e corresponde à especificação final.

Botoi executa hoje um servidor MCP sem estado com 49 ferramentas selecionadas, para que você possa estudar uma produção transporte sem estado em vez de adivinhação. Conecte-o ao Claude Code, Cursor ou VS Code do Página de configuração do MCP, ou inspecione a resposta de qualquer endpoint com /v1/headers do documentos interativos.