~/ / Artigos sobre IA / Especificação MCP 2026-07-28: o que mudou e o que verificar nos seus próprios arquivos
Especificação MCP 2026-07-28: o que mudou e o que verificar nos seus próprios arquivos
A revisão 2026-07-28 da especificação do Model Context Protocol (MCP) remove as sessões no nível do protocolo, marca como obsoletos o transporte HTTP+SSE mais antigo e vários recursos, e flexibiliza as regras para os esquemas de ferramentas. Este artigo resume o changelog oficial e mostra como verificar dois arquivos que você mesmo escreve: sua configuração MCP e seus esquemas de ferramentas.
Publicado: · Conferido com a especificação oficial em 2026-10-24. Este artigo a resume e não a substitui.
As maiores mudanças
- As sessões no nível do protocolo e o cabeçalho Mcp-Session-Id são removidos do transporte Streamable HTTP. Um servidor que precisa de estado entre chamadas usa identificadores explícitos que ele mesmo cria e repassa como argumentos comuns de ferramenta.
- O MCP passa a ser sem estado: o handshake initialize é removido. Cada requisição carrega a versão do protocolo e as capacidades do cliente em _meta, e uma incompatibilidade de versão retorna UnsupportedProtocolVersionError.
- Os servidores devem implementar uma nova chamada server/discover, que anuncia as versões de protocolo, as capacidades e a identidade que eles suportam.
- O endpoint HTTP GET e resources/subscribe são substituídos por subscriptions/listen, um único fluxo de resposta de longa duração para as notificações de mudança que um cliente escolhe receber.
- As requisições iniciadas pelo servidor, como roots/list, sampling/createMessage e elicitation/create, são substituídas por um padrão de Multi Round-Trip Requests: o servidor retorna um resultado que pede uma entrada, e o cliente repete a requisição original com as respostas.
- As tarefas experimentais saem do protocolo central e passam para uma extensão oficial.
- Os fluxos SSE retomáveis (Last-Event-ID) são removidos. Um fluxo de resposta interrompido perde a requisição em andamento, e o cliente precisa enviá-la de novo como uma nova requisição.
O que agora está obsoleto
| Recurso | Obsoleto desde | Remoção mais cedo | Migração sugerida |
|---|---|---|---|
| Roots | 2026-07-28 | Primeira revisão publicada em 2027-07-28 ou depois | Passar diretórios ou arquivos por parâmetros de ferramentas, URIs de recursos ou configuração do servidor |
| Sampling | 2026-07-28 | Primeira revisão publicada em 2027-07-28 ou depois | Integrar diretamente com as APIs dos provedores de LLM |
| Logging | 2026-07-28 | Primeira revisão publicada em 2027-07-28 ou depois | Registrar em stderr no caso de stdio, ou usar OpenTelemetry |
| Dynamic Client Registration | 2026-07-28 | Primeira revisão publicada em 2027-07-28 ou depois | Client ID Metadata Documents |
| Transporte HTTP+SSE | 2025-03-26 | Três meses depois que a SEP-2596 chegar a Final | Streamable HTTP |
| Valores thisServer e allServers de includeContext | 2025-11-25 | Acompanha o Sampling | Omitir o campo ou usar none |
Um recurso obsoleto continua fazendo parte da especificação. A remoção mais cedo indica quando ele passa a poder ser removido, e a remoção de fato é uma decisão tomada durante a preparação da versão. A nova política de ciclo de vida dos recursos define um período mínimo de obsolescência de doze meses.
Verifique sua configuração MCP
Se a sua configuração ainda usa o transporte HTTP+SSE, ela está na lista de obsoletos. A documentação do Claude Code também chama de obsoleto o seu tipo sse e diz para usar servidores HTTP quando disponíveis. A especificação descreve o substituto, o Streamable HTTP: o servidor expõe um único endpoint que aceita POST, e o cliente envia cada mensagem JSON-RPC como um HTTP POST próprio.
- Cada POST deve incluir um cabeçalho Accept que liste application/json e text/event-stream.
- Todo POST deve incluir um cabeçalho MCP-Protocol-Version cujo valor corresponda à versão do protocolo no corpo da requisição.
- As requisições levam um cabeçalho Mcp-Method e, para tools/call, resources/read e prompts/get, também um cabeçalho Mcp-Name.
- O servidor responde a cada requisição com um único objeto JSON ou com um fluxo SSE restrito àquela requisição.
Qual revisão do protocolo o seu cliente suporta é uma pergunta para a documentação do seu cliente. O verificador abaixo lê um .mcp.json ou claude_desktop_config.json e aponta entradas como um servidor remoto sem type ou um que ainda usa sse.
Experimente: MCP Config Checker
Regras conferidas com a documentação em 2026-10-23.
Documentação: Claude Code / Model Context Protocol / VS Code
Não verificado: se um comando existe, se um pacote é instalado, se um servidor remoto responde e configurações que outros aplicativos leem de outra forma.
Tudo roda no seu navegador. A configuração não é enviada.
Os esquemas de ferramentas podem usar todo o JSON Schema 2020-12
- inputSchema e outputSchema agora aceitam qualquer palavra-chave do JSON Schema 2020-12, e structuredContent pode ser qualquer valor JSON. A especificação acrescenta requisitos para resolver $ref e limites para os recursos que as palavras-chave de composição podem usar.
- Um servidor pode marcar o parâmetro de uma ferramenta com x-mcp-header para que seu valor seja copiado para um cabeçalho HTTP Mcp-Param-{name}. O parâmetro marcado deve ser uma string, um inteiro ou um booleano, não um número.
- A propriedade marcada deve ser alcançável a partir da raiz do esquema apenas por chaves properties. O caminho não pode passar por items, oneOf, anyOf, allOf, not, if/then/else nem $ref.
- Um cliente que usa Streamable HTTP deve rejeitar uma definição de ferramenta cuja anotação x-mcp-header quebre essas regras, o que significa que a ferramenta fica de fora do resultado de tools/list.
Para testar um esquema de ferramenta, cole-o com um conjunto de argumentos de exemplo no validador abaixo. Ele verifica as palavras-chave comuns do Draft 2020-12 e informa quais não verifica.
Experimente: JSON Schema Validator
Segue o JSON Schema Draft 2020-12 nas palavras-chave que suporta. Lê $ref apenas dentro do mesmo schema.
Tudo roda no seu navegador. O schema e os dados não são enviados.
Pontos de segurança para servidores
- Um servidor deve validar o cabeçalho Origin em todas as conexões recebidas, para evitar ataques de DNS rebinding. Se o cabeçalho estiver presente e for inválido, ele deve responder com HTTP 403 Forbidden.
- Um servidor que roda localmente deve escutar apenas em localhost (127.0.0.1), e não em todas as interfaces de rede (0.0.0.0).
- Os servidores devem implementar autenticação adequada para todas as conexões.
- Um servidor que processa o corpo da requisição deve rejeitar uma requisição cujos cabeçalhos não correspondam ao corpo, com HTTP 400 e o erro JSON-RPC HeaderMismatch (código -32020).
- Os servidores de autorização devem incluir o parâmetro iss nas respostas de autorização (RFC 9207), e quando um iss estiver presente, os clientes devem validá-lo antes de trocar o código de autorização.
- Os clientes devem indexar as credenciais de cliente salvas pelo emissor que as concedeu, e não devem reutilizá-las com um servidor de autorização diferente.