MCP 2025-06-18 exige OAuth Resource Server e corta JSON-RPC batching: veja o que quebra na migração

O 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 → (MCP) teve sua segunda revisão formal publicada em 18 de junho de 2025, substituindo a revisão 2025-03-26. O changelog oficial lista mudanças que não são cosméticas: autenticação, formato de transporte e formato de saída das tools mudaram ao mesmo tempo. Para quem subiu um servidor MCP ainda na revisão anterior e não atualizou o SDK desde então, a lista de coisas que quebram é maior do que parece à primeira vista.

O ângulo aqui não é anunciar a spec, que já tem quase um ano e meio. É simular a migração de um servidor MCP local da revisão 2025-03-26 para a 2025-06-18 e mapear, ponto a ponto, onde o código para de funcionar.

O que muda, em uma tabela

Cada linha dessa tabela é um ponto de quebra real para quem tem servidor ou cliente próprio, não gerado só por SDK oficial atualizado.

OAuth Resource Server: o quebra-cabeça de autenticação

A mudança mais pesada é a classificação do servidor MCP como OAuth Resource Server (PR #338). Antes, um servidor podia aceitar um token de acesso sem expor de onde esse token vinha. Agora ele precisa publicar metadata de recurso protegido, apontando para o Authorization Server correspondente, igual a um resource server padrão em qualquer fluxo OAuth 2.0.

Na prática, isso quer dizer que um servidor que só validava um bearer token fixo contra uma lista hardcoded para de ser compatível com clientes que seguem a spec nova à risca. O cliente, por sua vez, passou a ser obrigado a implementar Resource Indicators conforme a RFC 8707 (PR #734), justamente para impedir que um servidor malicioso capture um token emitido para outro recurso e o reutilize.

Em resumo: se o servidor expõe só um endpoint de API key simples, ele ainda funciona tecnicamente, mas deixa de se beneficiar das proteções que a spec adicionou contra token leakage entre servidores MCP diferentes. Num ambiente com múltiplos servidores MCP conectados ao mesmo cliente (um cenário cada vez mais comum em stacks de agentes), isso é a diferença entre um token vazar de um servidor para outro ou não.

No roteiro de migração que eu seguiria num servidor local de teste, o primeiro passo seria expor o endpoint de protected resource metadata (geralmente em /.well-known/oauth-protected-resource) e só depois mexer em qualquer outra coisa, porque sem isso o handshake nem começa direito com um cliente atualizado.

Sem JSON-RPC batching: adeus ao array de requests

A revisão anterior permitia enviar várias chamadas JSON-RPC num único array, economizando round-trips. A 2025-06-18 removeu esse suporte (PR #416) sem substituto direto. Qualquer código que monta um payload assim:

[
  {"jsonrpc": "2.0", "id": 1, "method": "tools/list"},
  {"jsonrpc": "2.0", "id": 2, "method": "resources/list"}
]

passa a receber erro de protocolo, porque o servidor atualizado espera uma mensagem JSON-RPC por vez, não um array. A correção é mecânica, mas pode estar espalhada por várias partes de uma integração legada: trocar o batching por chamadas sequenciais, aceitando a latência extra, ou paralelizar no cliente abrindo múltiplas requisições HTTP em vez de uma só com lote.

Para servidores que dependiam de batching para reduzir custo de rede em ambientes com latência alta (bastante comum em integrações rodando fora dos data centers dos grandes provedores de nuvem, caso típico de parte da infraestrutura brasileira), essa é a mudança que mais pesa no desempenho, mesmo não sendo a mais vistosa.

Saída estruturada: tool não devolve mais só texto

A PR #371 adicionou suporte a saída estruturada nas tools, e a PR #603 somou resource links aos resultados de chamada de tool. Antes, uma tool MCP devolvia um bloco de conteúdo com texto livre, cabendo ao modelo interpretar. Agora é possível declarar um outputSchema na definição da tool e devolver dados que seguem esse schema, além de referenciar recursos externos diretamente no resultado em vez de embutir tudo como texto.

Isso muda o contrato de quem implementa uma tool. Uma definição que antes era só:

{
  "name": "get_weather",
  "description": "Retorna o clima atual"
}

passa a poder declarar o formato de saída esperado, e o cliente que consome essa tool consegue validar a resposta contra um schema em vez de fazer parsing de texto livre. Quem construiu lógica própria de parsing em cima da resposta textual de uma tool MCP (um regex para extrair um número de uma frase, por exemplo) perde esse workaround, porque a saída estruturada já entrega o dado no formato certo, e manter o parsing antigo em paralelo vira dívida técnica desnecessária.

Outras mudanças que pegam quem não lê o changelog inteiro

A lista de mudanças menores do changelog oficial do MCP tem itens que parecem pequenos isoladamente, mas somados mudam o comportamento de qualquer integração séria:

• O header MCP-Protocol-Version passou a ser obrigatório em requisições HTTP subsequentes à negociação inicial (PR #548); sem ele, servidores estritos rejeitam a chamada.
• O protocolo passou de SHOULD para MUST na operação de lifecycle, fechando uma brecha de implementações que ignoravam a etapa de inicialização.
• Foi adicionado suporte a elicitation (PR #382), permitindo que o servidor peça informação adicional ao usuário no meio da interação, em vez de falhar ou assumir um valor padrão.
• O campo _meta chegou a mais tipos de interface (PR #710), e um campo title foi adicionado para nome amigável, separando identificador programático de rótulo visível (PR #663).
• CompletionRequest ganhou um campo context, permitindo que requisições de completion incluam variáveis já resolvidas anteriormente (PR #598).

Quando vale migrar agora e quando vale esperar

Se o servidor MCP roda atrás de um SDK oficial mantido (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), boa parte dessas mudanças é absorvida na troca de versão da dependência, e o trabalho manual fica concentrado em publicar a metadata de OAuth e revisar qualquer uso direto de batching. Já quem implementou o protocolo à mão, sem SDK, tem as cinco frentes (auth, batching, saída estruturada, header de versão e lifecycle) para revisar uma por uma antes de apontar um cliente atualizado para esse servidor.

Para servidores MCP que só rodam em rede local, sem exposição externa e sem múltiplos clientes compartilhando token, a pressão para adotar o fluxo completo de OAuth Resource Server é menor: a spec recomenda, mas um ambiente fechado de desenvolvimento pode conviver com autenticação simplificada por mais tempo sem risco real. O ponto de atenção é não deixar essa simplificação vazar para produção só porque funcionou em teste local.

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