Mudanças na especificação do Model Context Protocol: o que há de novo e o que quebra

Se o seu servidor MCP guarda algo entre duas requisições, a versão mais recente do protocolo acabou de transformar esse hábito em um bug. A especificação 2026-07-28 remove o handshake initialize, elimina o cabeçalho Mcp-Session-Id e reconstrói o MCP como um protocolo simples de requisição e resposta, em que cada mensagem carrega tudo o que o servidor precisa para responder. Algumas mudanças são pequenas: um cabeçalho aqui, um código de erro renumerado ali. Outras vão quebrar um servidor que funcionava bem na semana passada.

Este artigo ordena as mudanças pelo nível de impacto, usando o changelog oficial e o post de anúncio como fonte de referência. Você encontra nomes exatos de campos, números de SEP, uma tabela com o que foi removido e o que apenas foi descontinuado, e uma ordem de migração que você consegue concluir em uma única sprint.

💡 Resumo rápido: as sessões acabaram, as requisições iniciadas pelo servidor agora usam um padrão de nova tentativa, as respostas de lista são cacheáveis, a autorização ficou mais rigorosa e as tarefas passaram para uma extensão. Roots, Sampling e Logging continuam funcionando, mas só por no mínimo doze meses.

Por que esta revisão é diferente

As revisões anteriores adicionaram recursos. Esta remove suposições. A passagem de uma conexão com estado e bidirecional para uma troca sem estado afeta todos os transportes, todos os SDKs e todos os gateways posicionados na frente de um servidor.

Cinco revisões, uma direção

Leia a coluna da direita de cima para baixo e a direção fica óbvia. Cada revisão afasta o MCP de um socket longo, no estilo de chat, e o aproxima de algo que um balanceador de carga, uma CDN e um runtime serverless conseguem tratar sem tratamento especial.

A versão já tem suporte onde importa. Os quatro SDKs de Nível 1 (TypeScript, Python, Go e C#) funcionam com a 2026-07-28, e o SDK de Rust oferece suporte em beta. Os mantenedores admitem que haverá "algum custo de migração, especialmente para desenvolvedores que dependiam de identificadores de sessão", e acrescentam que o feedback dos testes iniciais tornou o processo mais fácil.

O núcleo sem estado

Duas propostas causam a maior parte do impacto: a SEP-2567 remove as sessões, e a SEP-2575 remove o handshake e reformula como as notificações fluem.

Sem handshake, sem ID de sessão

A requisição initialize e a notifications/initialized deixaram de existir, assim como Mcp-Session-Id. Os endpoints de lista (tools/list, resources/list, prompts/list) não podem mais variar por conexão, porque não há mais identidade de conexão para isso. Quando uma tool precisa de estado entre chamadas, o servidor cria um identificador explícito, como um ID de carrinho ou de workspace, e o modelo o devolve como um argumento comum da tool.

No lugar do handshake, cada requisição carrega seu próprio contexto em _meta. Este esboço mostra a forma, e não uma cópia da especificação:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "stateless transport" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Copiar prompt

Uma incompatibilidade de versão retorna UnsupportedProtocolVersionError, e os servidores se identificam em cada resultado por meio de io.modelcontextprotocol/serverInfo.

⚠️ O estado oculto é o risco real. Mapas em memória indexados por ID de sessão, níveis de log por conexão e listas de inscrição por conexão deixam de funcionar. Eles são fáceis de deixar passar em uma busca no código, porque raramente contêm a palavra "session".

Anúncio de versões e capacidades. Os servidores agora precisam implementar um novo RPC no namespace server/, que informa as versões de protocolo suportadas, as capacidades e a identidade. Os clientes podem chamá-lo antes de tudo para escolher uma versão logo no início, e no STDIO ele funciona como uma verificação de compatibilidade com versões anteriores. O changelog o lista logo abaixo da remoção do handshake, então confira a página do schema para o nome exato do método e o formato da resposta antes de integrá-lo.

O que substitui o stream GET

O endpoint GET de HTTP, resources/subscribe e resources/unsubscribe são substituídos por uma única chamada: subscriptions/listen. Ela abre um único stream de resposta POST de longa duração, e os clientes optam pelos tipos de mudança que lhes interessam:

• toolsListChanged
• promptsListChanged
• resourcesListChanged
• resourceSubscriptions

O servidor confirma e marca cada notificação com io.modelcontextprotocol/subscriptionId. Mensagens com escopo de requisição, como notifications/progress e notifications/message, permanecem no stream de resposta da requisição a que pertencem.

Três outras remoções vêm junto: ping, logging/setLevel e notifications/roots/list_changed. O nível de log agora é definido por requisição, por meio de io.modelcontextprotocol/logLevel, e um servidor não deve emitir notifications/message para uma requisição que não o contenha.

A retomada de SSE também acabou. Não existe mais o cabeçalho Last-Event-ID nem IDs de evento, então um stream de resposta interrompido perde a requisição em andamento, e o cliente precisa enviá-la novamente com um novo ID de requisição. Uma chamada de tool que roda por noventa segundos em uma conexão instável agora precisa da extensão de tasks, e não de sorte.

Multi Round-Trip Requests explicado

Por que as requisições do servidor tiveram que sair

Antes desta revisão, um servidor podia enviar elicitation/create, sampling/createMessage ou roots/list no meio de uma chamada, por um stream aberto. Isso prendia o cliente a uma única instância do servidor e exigia sticky load balancing ou armazenamento compartilhado.

Multi Round-Trip Requests (SEP-2322) substituem esse desenho. A especificação é direta a respeito: os servidores devem enviar essas requisições pelo padrão MRTR, o padrão antigo não é mais suportado, e esta é uma mudança que quebra compatibilidade. Todo resultado também passa a carregar o campo resultType, obrigatório. Um valor é input_required, o outro marca um resultado final comum, e os clientes tratam um campo ausente vindo de um servidor mais antigo como do tipo comum.

Como funciona o ciclo de nova tentativa

O fluxo tem quatro etapas:

1. O cliente envia uma requisição normal, por exemplo tools/call.
2. O servidor não consegue concluir, então retorna um InputRequiredResult listando o que precisa.
3. O cliente reúne as respostas com o usuário ou com outra fonte.
4. O cliente repete a requisição original com inputResponses anexado, usando um ID JSON-RPC novo.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "github_login": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Please provide your GitHub username",
          "requestedSchema": {
            "type": "object",
            "properties": { "name": { "type": "string" } },
            "required": ["name"]
          }
        }
      }
    },
    "requestState": "AEAD-protected blob"
  }
}

Copiar prompt

Apenas três requisições do cliente podem receber esse resultado: prompts/get, resources/read e tools/call. Todo InputRequiredResult precisa de pelo menos um de inputRequests ou requestState, e um servidor não deve pedir uma capacidade que o cliente nunca declarou. Como a nova tentativa informa ao cliente como as coisas terminaram, a notificação de conclusão de elicitation e o campo elicitationId, da versão 2025-11-25, são removidos.

Trate o requestState como entrada do usuário

A string requestState passa pelo cliente, então a especificação manda tratá-la como controlada por um atacante. Se ela influenciar autorização, acesso a recursos ou lógica de negócio, proteja sua integridade com HMAC ou AEAD e rejeite qualquer coisa que falhe na verificação.

Para proteção contra replay, coloque três itens dentro do payload protegido e verifique cada um ao recebê-lo:

• o principal autenticado
• uma expiração curta
• um identificador da requisição de origem, como o nome do método e um digest dos seus parâmetros principais

Essas medidas limitam o replay, mas não garantem uso único. Um resgate de uso único precisa ser aplicado no servidor.

Cabeçalhos, cache e códigos de erro

Cabeçalhos de roteamento para gateways

A SEP-2243 exige Mcp-Method e Mcp-Name em toda requisição POST do Streamable HTTP. O objetivo é operacional: gateways e WAFs agora conseguem rotear, medir e limitar a taxa do tráfego MCP sem analisar o corpo JSON. Cabeçalhos personalizados também podem ser derivados de parâmetros de tools por meio de x-mcp-header, e uma divergência entre cabeçalho e corpo aparece como um erro HeaderMismatch, que agora existe no schema.

💡 Se você roda um API gateway na frente de um servidor MCP, esta é a mudança que compensa primeiro. Escreva regras sobre os dois cabeçalhos, em vez de expressões regulares sobre os corpos das requisições.

Dicas de cache e códigos de erro

A SEP-2549 adiciona uma interface CacheableResult. Os resultados de tools/list, prompts/list, resources/list, resources/read e resources/templates/list agora precisam incluir:

• ttlMs: uma dica de validade em milissegundos, para que os clientes possam usar cache em vez de fazer polling
• cacheScope: "public" ou "private", que informa aos intermediários compartilhados se podem armazenar a resposta

Ambas complementam as notificações listChanged já existentes. Os servidores também devem retornar as tools em uma ordem determinística, o que ajuda os caches dos clientes e aumenta as taxas de acerto do cache de prompts no lado do modelo.

Os códigos de erro também mudaram, sob uma nova política de alocação: de -32000 a -32019 continuam definidos pela implementação, e de -32020 a -32099 são reservados para a especificação.

Se um cliente decide o que fazer com base nos números antigos, ele vai interpretar mal os novos erros.

A autorização fica mais rigorosa

Verificações de emissor e credenciais vinculadas

Três mudanças apertam o fluxo OAuth:

• SEP-2468: os servidores de autorização devem incluir o parâmetro iss da RFC 9207, e os clientes devem validar um iss presente contra o emissor registrado antes de resgatar o código de autorização.
• SEP-2352: as credenciais de cliente ficam vinculadas ao servidor de autorização que as emitiu. Armazene-as pelo identificador do emissor, nunca as reutilize com outro servidor e registre-se de novo quando o servidor mudar.
• SEP-837: os clientes devem enviar um application_type adequado durante o Dynamic Client Registration, o que evita conflitos de URI de redirecionamento do OpenID Connect em localhost.

O registro dinâmico está saindo de cena

O protocolo OAuth 2.0 Dynamic Client Registration (RFC 7591) foi descontinuado em favor dos Client ID Metadata Documents. Ele continua funcionando para servidores de autorização que não têm a opção mais nova, mas o anúncio diz que será removido em uma versão posterior da especificação. Planeje a troca agora, e não durante um incidente.

Tasks, schemas e extensões

As tasks passam para uma extensão

As tasks experimentais saíram do protocolo central e se tornaram a extensão oficial io.modelcontextprotocol/tasks (SEP-2663). A reformulação troca o método bloqueante tasks/result por polling com tasks/get, adiciona tasks/update para que um cliente possa enviar entrada a uma task em execução, e remove tasks/list. Os servidores agora podem retornar um identificador de task sem que o cliente o peça.

Esse último ponto importa para trabalhos longos. Um gerador de relatórios lento não precisa mais manter um stream de resposta aberto: ele retorna um identificador, o cliente faz polling, e uma conexão caída não custa nada.

Schemas mais flexíveis e novos espaços para extensões

Acréscimos menores que merecem uma linha cada:

• inputSchema e outputSchema podem usar qualquer construção do JSON Schema 2020-12, e structuredContent pode ser qualquer valor JSON (SEP-2106), com novas regras para resolução de $ref e limites de recursos em construções de composição.
• ClientCapabilities e ServerCapabilities ganham um campo extensions para recursos opcionais além do núcleo.
• O contexto de rastreamento do OpenTelemetry trafega em _meta por meio de traceparent, tracestate e baggage (SEP-414).

O texto da Cloudflare sobre a versão informa que o endpoint /mcp dela aceita tanto as novas requisições sem estado quanto clientes da versão 2025, o que é um padrão sensato para quem roda um servidor público.

O que quebra e como corrigir

Recursos removidos

Estes vão falhar de imediato com uma implementação 2026-07-28:

Recursos descontinuados

Descontinuado não é removido. Estes ainda funcionam por no mínimo doze meses sob a nova política de ciclo de vida de recursos (SEP-2596), que define os estados Active, Deprecated e Removed e um registro público:

Alguns textos colocam Roots, Sampling e Logging junto com as remoções. O texto da especificação diz descontinuado, então trate-os como um item de calendário, e não como uma queda do serviço. Só ping e logging/setLevel de fato deixaram de existir.

Uma ordem de migração que funciona

1. Atualize o SDK primeiro. Passe para uma versão de Nível 1 que suporte a 2026-07-28 e leia as notas de migração dela antes de mexer no seu código.
2. Procure o estado de sessão. Busque por Mcp-Session-Id e por qualquer mapa indexado por conexão. Substitua cada um por um identificador explícito passado como argumento de tool.
3. Aceite as duas gerações. Sirva clientes antigos e novos pelo mesmo endpoint durante a transição, como faz a Cloudflare.
4. Reescreva as chamadas iniciadas pelo servidor. Transforme cada chamada de elicitation, sampling e roots em um InputRequiredResult com um requestState assinado.
5. Adicione os campos de cache. Retorne ttlMs e cacheScope nos resultados de lista e de leitura, e ordene as listas de tools de forma determinística.
6. Atualize as regras do gateway. Roteie por Mcp-Method e Mcp-Name, e depois aposente as regras que analisam o corpo.
7. Corrija a autorização. Valide iss, armazene as credenciais por emissor e agende a migração para os Client ID Metadata Documents.

Depois, teste os casos difíceis: derrube um stream de resposta no meio de uma requisição, reenvie um requestState antigo e rode duas instâncias do servidor sem roteamento fixo. Se os três se comportarem corretamente, a migração está sólida.

💡 Dica de produtividade: cole o código de tratamento de sessão do seu servidor e a seção do changelog acima no Claude Sonnet 5 na Picasso IA e peça uma lista de todos os lugares em que o estado vaza entre requisições. Revise o resultado você mesmo, já que um modelo pode deixar passar um mapa escondido atrás de uma função auxiliar.

Crie seus próprios visuais

Posts técnicos como este dependem totalmente dos diagramas e das imagens de capa, e você não precisa de uma equipe de design para produzi-los. A Picasso IA reúne dezenas de modelos de imagem em um só lugar, então você pode testar o mesmo prompt em vários deles e ficar com o melhor resultado.

Experimente o Seedream 5 Pro para cenas fotorrealistas, o GPT Image 2 para seguir o prompt com precisão, ou o Ideogram v4 Quality quando sua imagem precisar de texto legível. Descreva a cena, escolha a proporção 16:9 e gere algumas variações antes de se decidir.

Abra a Picasso IA, escolha um modelo e crie a primeira imagem para o seu próximo texto sobre MCP hoje mesmo.