Especificação MCP 2026-07-28: Quais Mudanças e O Que Pode Quebrar

A especificação MCP 2026-07-28 é a maior reescrita que o Protocolo de Contexto de Modelo teve desde seu lançamento, e afetará qualquer negócio que execute agentes de IA contra seus próprios sistemas. No momento da redação, é um candidato a lançamento, em vez de um padrão final: o blog oficial do MCP bloqueou o candidato em 21 de maio de 2026, publicou SDKs beta em 29 de junho de 2026 e agendou a publicação da especificação final para 28 de julho de 2026. As mudanças descritas aqui já são públicas no changelog do rascunho, mas a data de publicação é o momento em que se tornam o padrão.

Se você tem um servidor MCP na frente do seu CRM, do seu sistema de inventário ou da sua base de conhecimento interna, esta é a revisão que decide quanto retrabalho os próximos doze meses conterão. Vale a pena dedicar uma hora da sua atenção agora, em vez de enfrentar uma interrupção surpresa mais tarde.

O que a especificação MCP 2026-07-28 realmente muda

A ideia central é que o MCP deixa de ser com estado.

De acordo com o changelog da especificação oficial, sessões em nível de protocolo e o cabeçalho de ID de sessão foram removidos do transporte HTTP Streamable sob o SEP-2567. Os endpoints de lista para ferramentas, recursos e prompts não variam mais por conexão. Servidores que realmente precisam de estado entre chamadas devem gerar identificadores explícitos e passá-los como argumentos normais de ferramenta.

A inicialização do handshake também foi eliminada, sob o SEP-2575. Cada solicitação agora carrega sua própria versão de protocolo e capacidades do cliente no campo de metadados da solicitação, e uma incompatibilidade de versão retorna um erro de versão de protocolo não suportada, em vez de falhar na configuração da conexão. Um novo server/discover assume a função de publicidade. Os servidores devem implementá-lo, e os clientes podem chamá-lo antes de qualquer outra coisa para selecionar uma versão antecipadamente.

Três outras remoções são importantes operacionalmente. O endpoint HTTP GET e os métodos de inscrição e cancelamento de recursos são substituídos por um único stream de escuta de longa duração que os clientes optam por notificação de tipo. Ping, o configurador de nível de log, e a notificação de mudança de lista de raízes foram removidos. A resumibilidade do stream também foi eliminada: sem IDs de evento e o cabeçalho de retomar, um stream de resposta quebrado perde a solicitação em andamento, e o cliente deve reenviá-la como uma nova solicitação.

Por que a ausência de estado é o ponto principal

O design antigo assumia um desenvolvedor executando um servidor em um laptop. Essa suposição deixou de ser verdadeira no momento em que as empresas colocaram servidores MCP atrás de balanceadores de carga.

O TechCrunch, cobrindo a atualização em 20 de julho de 2026, citou o engenheiro fundador da Arcade, Nate Barbettini, descrevendo o problema prático de forma clara: com sessões, cada máquina em uma frota precisa saber sobre um ID de sessão que outra máquina emitiu. Isso força sessões fixas, um armazenamento de sessão compartilhado, ou ambos, e é a razão pela qual tantas implantações de MCP nunca saíram da fase piloto.

Remover sessões significa que uma solicitação pode ser respondida por qualquer instância atrás de um balanceador de carga round-robin comum. Em termos de infraestrutura, isso é pouco glamoroso e extremamente valioso. Converte um servidor MCP de um serviço especial com estado em algo que sua hospedagem web existente já sabe como executar, escalar e reiniciar.

O Register, reportando em 23 de julho de 2026, citou David Soria Parra, da Anthropic, chamando essas "as mudanças mais substanciais que fizemos na especificação". O mesmo artigo trouxe um aviso da orientação de prontidão empresarial da Stacklok de que servidores na nova revisão podem não interagir com clientes mais antigos, e vice-versa, a menos que um lado implemente deliberadamente uma queda ou tradução.

A mudança mais provável de quebrar sua integração

Além das sessões, a mudança com o maior raio de impacto é o padrão de Solicitações de Múltiplas Rodadas, introduzido sob o SEP-2322.

Anteriormente, um servidor poderia iniciar uma solicitação de volta ao cliente, que era como a amostragem, listagem de raízes e elicitação funcionavam. Isso não é mais possível em um mundo sem estado. Em vez disso, um servidor retorna um resultado intermediário marcado como requerendo entrada, carregando as perguntas que precisa que sejam respondidas. O cliente coleta as respostas e tenta novamente a chamada original com essas respostas anexadas.

Cada resultado agora também carrega um campo de tipo de resultado requerido, definido como completo ou como entrada-requerida. Os clientes devem tratar um campo ausente de um servidor mais antigo como completo, que é a única concessão deliberada de compatibilidade retroativa no design.

Se você construiu um servidor MCP personalizado em vez de gerar um a partir de um SDK, é aqui que o trabalho recai. Qualquer fluxo em que seu servidor perguntava ao cliente uma questão durante a execução precisa ser reestruturado em torno de tentativas em vez de callbacks.

O que está obsoleto e o relógio de doze meses

A revisão também introduz algo que o protocolo estava faltando: um ciclo de vida formal de recursos. Sob o SEP-2596, a especificação agora define estados ativos, obsoletos e removidos, com uma janela mínima de obsolescência de doze meses e um registro público de recursos obsoletos.

Três recursos entram nessa janela sob o SEP-2577. Raízes, amostragem e registro estão todos obsoletos. Eles continuam funcionando, mas novas implementações não devem adotá-los. O changelog sugere substituições concretas: passe diretórios e arquivos como parâmetros de ferramenta, URIs de recursos ou configuração do servidor em vez de raízes; chame a API do seu provedor de LLM diretamente em vez de usar amostragem; e escreva para o erro padrão ou emita rastros OpenTelemetry em vez de usar registro de protocolo.

O antigo transporte HTTP com eventos enviados pelo servidor, já suavemente obsoleto desde o início de 2025, agora está formalmente obsoleto. Assim como o registro dinâmico de clientes OAuth como um mecanismo de registro, em favor de documentos de metadados de ID de cliente, embora continue disponível para servidores de autorização que precisem dele.

Para qualquer um que planeje uma construção, a leitura prática é simples. Uma janela mínima de doze meses significa que você não está enfrentando uma emergência, mas está enfrentando um prazo que agora tem uma forma publicada.

Tarefas e Aplicativos MCP se tornam extensões

Trabalhos de longa duração se movem do protocolo central para uma extensão oficial de tarefas sob o SEP-2663. O redesenho se adapta ao modelo sem estado: um servidor pode devolver um identificador de tarefa, e o cliente consulta o status em vez de manter uma chamada bloqueada aberta. Há também um método para alimentar entrada a uma tarefa durante a execução.

Junto com isso, os Aplicativos MCP permitem que um servidor envie HTML interativo que o host renderiza em um iframe isolado, para que uma ferramenta possa retornar um gráfico, um formulário ou um seletor em vez de um bloco de texto. Para fluxos de trabalho empresariais, isso é o mais interessante dos dois. Um passo de aprovação que é renderizado como um formulário real é uma experiência materialmente melhor do que uma negociada por meio de chat.

Ambos são extensões em vez de núcleo, o que é uma escolha deliberada de governança. Den Delimarsky, da Anthropic, citado no Register, enquadrou extensões como uma maneira de testar ideias antes de incorporá-las ao protocolo. Extensões estão desativadas por padrão e requerem opt-in explícito, e a especificação pede que os implementadores documentem a degradação graciosa quando o outro lado não as suporta.

A autorização se torna mais rigorosa

As mudanças de autorização são menores, mas não opcionais. Os clientes agora devem validar o parâmetro emissor nas respostas de autorização contra o emissor registrado antes de resgatar um código de autorização, de acordo com o RFC 9207 e o SEP-2468. Os clientes devem declarar um tipo de aplicativo apropriado durante o registro dinâmico do cliente para evitar conflitos de URI de redirecionamento. E as credenciais agora estão explicitamente vinculadas ao servidor de autorização que as emitiu, portanto, devem ser vinculadas pelo emissor, nunca reutilizadas em outro lugar, e re-registradas quando o servidor de autorização mudar.

Se o seu servidor MCP lida com dados de clientes, essas são as cláusulas a serem entregues ao seu revisor de segurança.

Um plano de migração que se adapta a uma pequena equipe

Trabalhe através de i