MCP: a revisão de junho de 2025 do protocolo quebra servidores feitos para a versão anterior

A revisão 2025-06-18 do Model Context Protocol↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI →, publicada em 18 de junho de 2025, remove o envio em lote de chamadas, exige negociação explícita de versão e adiciona elicitation e saída estruturada. Quem mantém um servidor MCP precisa revisar o código.

O Model Context Protocol (MCP), o padrão aberto que a Anthropic usa para conectar modelos a ferramentas externas em produtos como Claude Desktop e que editores como o Cursor também adotaram, passou por uma revisão formal em 18 de junho de 2025. O changelog oficial do MCP (modelcontextprotocol.io) lista as mudanças em relação à revisão anterior, de 26 de março de 2025. Passados mais de dezesseis meses, o ponto que mais afeta quem já tinha um servidor em produção não é nenhum recurso novo: é o que a revisão removeu.

O que a revisão 2025-06-18 mudou, em ordem de impacto

O changelog agrupa as mudanças em "major changes" e "other schema changes". As que mexem com compatibilidade são estas:

• Remoção do suporte a JSON-RPC batching (envio de várias chamadas em um único array).
• Suporte a saída estruturada em resultados de ferramentas (structured tool output).
• Servidores MCP passam a ser classificados como OAuth Resource Servers, com metadata própria de descoberta.
• Clientes MCP são obrigados a implementar Resource Indicators (RFC 8707) para evitar que um servidor malicioso capture tokens de acesso.
• Suporte a elicitation, para o servidor pedir informação adicional ao usuário no meio de uma interação.
• Suporte a resource links em resultados de chamadas de ferramenta.
• Obrigatoriedade do header MCP-Protocol-Version em requisições HTTP subsequentes à negociação inicial.
• Troca de "SHOULD" por "MUST" nas operações de ciclo de vida (lifecycle) do protocolo.

O que quebra de verdade: o fim do JSON-RPC batching

Antes da revisão, um cliente podia empacotar várias chamadas JSON-RPC num único array e mandar de uma vez, economizando round-trips. A revisão 2025-06-18 removeu esse suporte (PR #416 no changelog). Servidor ou cliente que ainda monta esse array de requisições simplesmente não terá resposta válida do outro lado, porque a validação de mensagem na versão nova espera um objeto único, não uma lista.

Na prática, se o seu servidor MCP local (por exemplo, um que você conectou ao Claude Desktop via claude_desktop_config.json) foi escrito com uma lib ou SDK que ainda monta lotes, a correção é trocar cada chamada em lote por chamadas sequenciais, uma requisição JSON-RPC por vez. Não existe flag de compatibilidade retroativa: quem migra o servidor para uma versão atualizada do SDK oficial do MCP ganha esse comportamento automaticamente, sem precisar reescrever a lógica de negócio da ferramenta.

Negociação de versão: o header que virou obrigatório

A negociação de versão do protocolo já existia desde revisões anteriores, feita na mensagem initialize da conexão. O que muda agora é que, quando o transporte é HTTP, o cliente é obrigado a reenviar a versão negociada em todas as requisições seguintes, pelo header MCP-Protocol-Version:

POST /mcp HTTP/1.1
Host: localhost:3001
MCP-Protocol-Version: 2025-06-18
Content-Type: application/json

{"jsonrpc":"2.0","method":"tools/call","id":7,"params":{...}}

Um servidor estrito para a revisão nova pode (e deve, pela mudança de SHOULD para MUST no changelog) rejeitar requisições HTTP sem esse header, mesmo que o initialize inicial tenha corrido bem. Isso derruba integrações que guardaram a versão negociada em algum lugar mas nunca a reenviaram em cada chamada subsequente, um padrão comum em protótipos feitos antes de junho de 2025.

Elicitation: o servidor pode parar e perguntar

Nota da redação: os nomes de métodos, campos e exemplos de código desta e da próxima seção (elicitation e saída estruturada) ilustram, de forma genérica, o uso dos recursos anunciados no changelog oficial, mas a fonte não especifica esses nomes exatos nem foram executados em ambiente real. Valide antes de usar em produção.

Antes da revisão, um servidor MCP só tinha dois caminhos quando faltava um dado para completar uma tarefa: adivinhar ou falhar. O recurso de elicitation (PR #382) dá um terceiro caminho: o servidor envia uma requisição ao cliente pedindo que o usuário preencha um valor, descrito como um schema JSON, e a execução da ferramenta só continua depois que a resposta chega.

Num servidor típico escrito com um SDK que implemente esse recurso, isso pode aparecer como uma chamada que o handler da ferramenta faz de volta ao cliente antes de devolver seu resultado final, em um formato próximo deste (ilustrativo):

const resposta = await server.elicitInput({
  message: "Qual repositório devo usar para o deploy?",
  requestedSchema: {
    type: "object",
    properties: {
      repositorio: { type: "string" }
    },
    required: ["repositorio"]
  }
});

O ponto de atenção para quem migra: clientes que ainda falam a revisão 2025-03-26 não sabem responder a esse pedido, porque o método não existia. O servidor precisa checar a versão negociada no initialize antes de tentar usar elicitation, e cair num comportamento alternativo (pedir o dado por parâmetro da própria ferramenta, por exemplo) quando o cliente for antigo.

Saída estruturada: parar de devolver só texto

O outro recurso que muda como se escreve uma ferramenta MCP é o suporte a saída estruturada (PR #371). Até a revisão anterior, o resultado de uma chamada de ferramenta era, na prática, texto livre dentro do campo content. Agora a definição da ferramenta pode declarar um schema de saída, e a resposta pode trazer dados tipados, em vez de o cliente precisar fazer parsing de texto para extrair um valor (o changelog não detalha os nomes exatos de campo usados nessa implementação).

Isso muda o contrato de quem consome a ferramenta do outro lado: um agente que antes precisava interpretar uma frase como "o deploy foi concluído com sucesso no commit abc123" pode agora ler algo como { status: "success", commit: "abc123" } diretamente. Servidores migrados sem declarar esse schema de saída continuam funcionando, só não ganham esse benefício, nenhuma ferramenta é obrigada a adotar saída estruturada.

O que muda para quem roda local, no Claude Desktop ou no Cursor

A versão do protocolo é negociada por conexão: cliente e servidor trocam a versão que cada um fala na mensagem initialize, e o servidor responde com a versão que vai usar dali em diante.

Na prática do dia a dia com Claude Desktop ou Cursor, o comportamento depende de qual revisão o cliente embutido de cada app já negocia, informação que muda a cada atualização desses programas e que o changelog oficial do protocolo não documenta. O risco mais previsível está do outro lado: servidores MCP de terceiros, instalados via npx ou pip, que foram escritos contra a revisão anterior e nunca foram atualizados. Um desses servidores pode aceitar a conexão (a negociação de initialize não falha, só registra a versão), mas quebrar na primeira chamada que depende de um dos recursos novos ou que ainda tenta usar batching.

Para quem mantém um servidor MCP próprio, o checklist de migração é curto:

1. Atualizar o SDK oficial (TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → ou Python) para a versão que implementa a revisão 2025-06-18.
2. Procurar no código qualquer lugar que monte arrays de chamadas JSON-RPC e trocar por chamadas sequenciais.
3. Se o transporte for HTTP, confirmar que o cliente reenvia MCP-Protocol-Version em toda requisição, não só no handshake.
4. Avaliar se alguma ferramenta se beneficia de elicitation ou de saída estruturada, com um caminho alternativo para clientes que ainda negociarem a versão antiga.
5. Se o servidor expõe autenticação via OAuth, revisar a classificação como Resource Server e a validação de Resource Indicators (RFC 8707) antes de aceitar tokens.

O changelog oficial também lista mudanças menores, como o campo title para nomes amigáveis em interfaces (separando-o do identificador programático name) e o campo context em requisições de completion, que permite reaproveitar variáveis já resolvidas. Nenhuma das duas quebra compatibilidade, mas valem revisão em servidores que exibem nomes de ferramenta para o usuário final.

Fonte 1: Especificação oficial do Model Context Protocol — Changelog da revisão 2025-06-18 (https://modelcontextprotocol.io/specification/2025-06-18/changelog)

Key Changes - Model Context Protocol

Documentation Index Fetch the complete documentation index at: /llms.txt Use this file to discover all available pages before exploring further. Skip to main content This document lists changes made to the Model Context Protocol (MCP) specification since the previous revision, 2025-03-26 .

​ Major changes

Remove support for JSON-RPC batching (PR #416 )

Add support for structured tool output (PR #371 )

Classify MCP servers as OAuth Resource Servers , adding protected resource metadata to discover the corresponding Authorization server. (PR #338 )

Require MCP clients to implement Resource Indicators as described in RFC 8707 to prevent malicious servers from obtaining access tokens. (PR #734 )

Clarify security considerations and best practices in the authorization spec and in a new security best practices page .

Add support for elicitation , enabling servers to request additional information from users during interactions. (PR #382 )

Add support for resource links in tool call results. (PR #603 )

Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548 ).

Change SHOULD to MUST in Lifecycle Operation

​ Other schema changes

Add _meta field to additional interface types (PR #710 ), and specify proper usage .

Add context field to CompletionRequest , providing for completion requests to include previously-resolved variables (PR #598 ).

Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663 )

​ Full changelog For a complete list of all changes that have been made since the last protocol revision, see GitHub . Was this page helpful? Yes No Assistant Responses are generated using AI and may contain mistakes.

Fonte: Especificação oficial do Model Context Protocol — Changelog da revisão 2025-06-18