Spec do MCP 2025-06-18 derruba o batching e obriga cabeçalho de versão em produção

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 pela especificação oficial, remove o batching de JSON-RPC, exige cabeçalho de versão em toda requisição HTTP e reclassifica servidores como OAuth Resource Servers. Quem já tem agentes no ar precisa checar compatibilidade antes de atualizar.

A revisão 2025-06-18 do Model Context Protocol, publicada pela especificação oficial, remove o batching de JSON-RPC, exige cabeçalho de versão em toda requisição HTTP e reclassifica servidores como OAuth Resource Servers. Quem já tem agentes no ar precisa checar compatibilidade antes de atualizar.

A especificação do Model Context Protocol teve uma revisão publicada em 18 de junho de 2025, substituindo a versão anterior, de 26 de março do mesmo ano. O changelog oficial do MCP lista mudanças que não são cosméticas: removem um recurso de transporte, trocam a forma como clientes fazem autenticação OAuth e adicionam uma capacidade inteiramente nova, chamada elicitation. Mais de um ano depois, times que colocaram servidores e clientes MCP em produção entre o fim de 2024 e o início de 2025 ainda podem estar rodando contra a spec antiga sem perceber onde isso vai doer.

Este texto detalha o que muda tecnicamente em cada ponto da revisão e o que testar num servidor já implantado antes de assumir que ele é compatível.

Batching de JSON-RPC: suporte removido

A versão 2025-06-18 remove o suporte ao batching de JSON-RPC (PR #416 do repositório da especificação). Batching era o recurso que permitia agrupar várias chamadas tools/call, resources/read ou prompts/get num único array JSON-RPC, economizando round-trips entre cliente e servidor.

Servidores que implementaram lógica própria para desempacotar arrays de requisições precisam remover esse código ou, no mínimo, tratar o caso de receber um array como erro de protocolo. Clientes que ainda enviam lotes batched para um servidor atualizado para 2025-06-18 vão receber respostas de erro, porque o servidor não sabe mais interpretar aquele formato como válido. Na prática, qualquer SDK MCP que enfileirava chamadas para enviar juntas precisa voltar a mandar uma requisição JSON-RPC por vez.

MCP-Protocol-Version: cabeçalho virou obrigatório

A revisão também exige que, ao usar transporte HTTP, a versão de protocolo negociada na inicialização seja repetida em todas as requisições subsequentes, via cabeçalho MCP-Protocol-Version (PR #548). Antes, a negociação acontecia só no handshake inicial e o servidor confiava que a sessão continuava na mesma versão.

Isso muda o comportamento esperado de qualquer proxy, API gateway ou middleware que fica entre cliente e servidor MCP. Um exemplo de requisição correta depois da revisão:

POST /mcp HTTP/1.1
Host: servidor.exemplo.com
Content-Type: application/json
MCP-Protocol-Version: 2025-06-18

{"jsonrpc":"2.0","id":7,"method":"tools/call","params":{"name":"buscar_pedido","arguments":{"id":"123"}}}

Servidores atualizados que recebem requisições sem esse cabeçalho podem rejeitar a chamada ou assumir a versão errada. Vale testar isso diretamente: fazer uma chamada para o servidor em produção sem o cabeçalho e ver se ele responde com erro de versão ou silenciosamente aceita, o que seria um sinal de que o servidor ainda está na spec antiga.

OAuth: servidor MCP agora é Resource Server

A mudança com mais implicação de segurança é a reclassificação de servidores MCP como OAuth Resource Servers (PR #338), que passam a expor metadados de recurso protegido apontando para o servidor de autorização correspondente. Um Resource Server é quem valida e consome tokens, não quem os emite (esse papel é do Authorization Server), e é essa posição que a especificação agora formaliza para servidores MCP. Junto com isso, a especificação passa a exigir que clientes implementem Resource Indicators, conforme a RFC 8707 (PR #734).

Na prática isso evita um problema concreto: sem indicador de recurso, um token de acesso emitido para um servidor MCP podia, em tese, ser reaproveitado contra outro servidor malicioso que se passasse por um recurso legítimo. Com resource indicators, o cliente informa explicitamente, no pedido do token, para qual recurso aquele token vale, conforme descrito na RFC 8707.

Quem implementou fluxo OAuth próprio para seu servidor MCP antes de junho de 2025 provavelmente não tem o endpoint de metadados de recurso protegido nem implementa os Resource Indicators da RFC 8707 nos tokens recebidos. Isso não quebra a função básica, mas deixa o servidor fora da garantia de segurança que a spec atual pressupõe. O changelog também aponta uma página nova de boas práticas de segurança e esclarecimentos no próprio spec de autorização, que vale revisar linha a linha para quem mantém a camada OAuth à mão.

Elicitation: servidor pode pausar e pedir mais dado ao usuário

A revisão adiciona suporte a elicitation (PR #382): a capacidade de um servidor, no meio de uma interação, pedir informação adicional ao usuário antes de continuar. É um recurso novo, não uma correção, e por isso não quebra nada em quem não o usa, mas muda o que um cliente MCP precisa saber suportar para ficar compatível com servidores que passem a depender dele.

Em resumo: antes da revisão, um servidor MCP só tinha duas opções diante de um pedido incompleto, responder com erro ou tentar adivinhar o parâmetro faltante. Com elicitation, ele pode devolver o controle ao cliente pedindo um dado específico, de forma estruturada, no meio da execução de uma ferramenta. Clientes que não implementam a capacidade de elicitation vão simplesmente não conseguir completar interações com servidores que a exigem, então checar isso na negociação de capabilities antes da conexão é importante para quem integra servidores de terceiros.

Saída estruturada e resource links: menos parsing manual

Duas mudanças reduzem gambiarra do lado do cliente. A primeira é suporte a saída estruturada de ferramentas (PR #371): em vez de devolver só texto livre, uma ferramenta pode retornar um objeto estruturado que o cliente consome diretamente, sem precisar fazer parsing de string para extrair campos. A segunda é suporte a resource links dentro do resultado de uma chamada de ferramenta (PR #603), permitindo que a resposta aponte para um recurso MCP em vez de embutir o conteúdo inteiro na resposta.

Ambas são aditivas: um servidor antigo que só devolve texto continua funcionando, só não aproveita o formato novo. Mas times que constroem clientes genéricos para consumir qualquer servidor MCP precisam decidir se tratam esses campos como opcionais (saída tolerante a ausência) ou passam a exigi-los de servidores parceiros.

Outras mudanças que passam despercebidas

A revisão também muda um SHOULD para MUST na operação de lifecycle do protocolo, o que significa que um comportamento antes recomendado virou obrigatório para conformidade. Além disso:

• Campo _meta foi adicionado a mais tipos de interface, com regras específicas de uso (PR #710);
• CompletionRequest ganhou campo context, permitindo que pedidos de completion incluam variáveis já resolvidas anteriormente (PR #598);
• Campo title foi adicionado para nomes de exibição amigáveis ao usuário, separando identificador programático (name) de rótulo legível (PR #663).

Nenhuma dessas três é destrutiva isoladamente, mas somadas ao resto formam uma spec com bem mais superfície do que a de março de 2025.

O que testar antes de confiar na compatibilidade

Para quem mantém servidor ou cliente MCP rodando desde antes de junho de 2025, a lista prática de verificação inclui: confirmar se o cliente envia MCP-Protocol-Version em toda requisição HTTP pós-handshake; verificar se algum fluxo ainda depende de batching de JSON-RPC; e checar se a implementação OAuth do servidor expõe metadados de recurso protegido e implementa Resource Indicators (RFC 8707) nos tokens. O changelog completo, linkado na própria página de especificação, lista cada PR individualmente para quem precisa auditar código contra cada mudança específica.

Fonte

1. Model Context Protocol — Specification Changelog (2025-06-18): https://modelcontextprotocol.io/specification/2025-06-18/changelog

Fonte: Model Context Protocol — Specification Changelog (2025-06-18)