MCP 2025-06-18: o que quebra em agentes já plugados via Model Context Protocol
A revisão mais recente da spec do Model Context Protocol reclassifica servidores como OAuth Resource Servers, adiciona elicitation e structured tool output, e derruba o batching de JSON-RPC. Um guia do que muda pra quem já tem servidor 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 → é a primeira desde a 2025-03-26 que mexe em coisas que já estão rodando em produção. Não é uma lista de features cosméticas: tem remoção de recurso, mudança de SHOULD para MUST e um novo modelo de autorização que obriga a repensar como o client obtém tokens. Segundo o changelog oficial, são três frentes que realmente importam para quem construiu servidores e clients MCP: autorização (OAuth + resource indicators), elicitation e structured tool output. Este texto separa o que é breaking change do que é adição opcional.
O que some: JSON-RPC batching
A mudança mais direta de quebrar contrato é a remoção do suporte a JSON-RPC batching (PR #416). Na spec anterior, um client podia enviar um array de requisições numa única mensagem e receber um array de respostas. Isso acabou.
Se o seu servidor ou client faz parsing esperando um array na raiz da mensagem, ele precisa passar a tratar cada requisição individualmente. Na prática, quem usou o SDK oficial sem gambiarra provavelmente não sente nada, porque o batching era pouco usado. O risco mora em implementações caseiras que otimizavam round-trips agrupando chamadas: essas param de funcionar contra um peer que já adotou a 2025-06-18.
A recomendação para migrar é trivial de descrever e chata de auditar: procure no código onde você monta ou desmonta arrays de mensagens JSON-RPC e troque por envio unitário. Não existe fallback negociável aqui, o recurso simplesmente não existe mais na spec.
Autorização: servidor MCP agora é um OAuth Resource Server
Essa é a mudança mais estrutural e a que mais dá trabalho. A spec passa a classificar servidores MCP como OAuth Resource Servers (PR #338) e exige protected resource metadata para que o client descubra qual é o Authorization Server correspondente. Some a isso o PR #734, que obriga os clients a implementar Resource Indicators conforme o RFC 8707.
O problema que o RFC 8707 resolve é concreto: sem resource indicators, um servidor MCP malicioso pode receber um access token e reusá-lo contra outra API para a qual o token também é válido. O resource indicator amarra o token ao recurso pretendido. Quando o client pede o token, ele inclui o parâmetro resource apontando para o servidor MCP alvo:
POST /token
grant_type=authorization_code
&code=...
&resource=https://mcp.exemplo.comO Authorization Server então emite um token com audience restrita àquele resource. Se o servidor tentar reaproveitar esse token em outro lugar, a validação de audiência falha.
O que quebra aqui:
- Servidores que faziam a própria autorização embutida precisam separar os papéis: quem valida token (Resource Server) não é quem emite (Authorization Server). Se você acoplou os dois, tem refatoração pela frente.
- Clients que pediam tokens sem
resourcepassam a receber, no melhor caso, tokens que o servidor rejeita, e no pior caso continuam funcionando mas com o furo de segurança que a spec agora considera inaceitável. - É preciso expor o endpoint de protected resource metadata para que o client faça descoberta automática do Authorization Server. Sem isso, o client não sabe para onde mandar o fluxo de OAuth.
A spec ainda esclarece considerações de segurança numa nova página de best practices, o que é sinal de que a comissão está tratando MCP como superfície de ataque séria, e não mais como protótipo de laboratório. Para quem constrói no Brasil e pluga agentes a APIs internas de empresa, essa é a parte que o time de segurança vai olhar antes de aprovar qualquer deploy.
Elicitation: o servidor pode pedir dados ao usuário no meio da conversa
O suporte a elicitation (PR #382) é adição, não quebra, mas muda o desenho de fluxos de agente. Antes, se um servidor precisava de uma informação que não veio na chamada, ele só podia falhar ou adivinhar. Agora ele pode solicitar informação adicional ao usuário durante a interação.
O caso de uso óbvio: uma tool de reserva que percebe faltar a data e, em vez de retornar erro, dispara uma elicitation pedindo a data ao usuário através do client. O client é quem renderiza esse pedido, então a experiência depende de o client implementar o recurso. Servidores antigos ignoram; servidores novos ganham um caminho para diálogos multi-etapa sem inventar protocolo por cima.
O ponto de atenção de segurança é evidente e a própria spec sinaliza cautela: elicitation é um vetor para servidor malicioso pedir dados sensíveis ("me passe sua chave de API") fingindo ser parte legítima do fluxo. A implementação no client precisa deixar claro que o pedido vem do servidor, não da aplicação.
Structured tool output e resource links
A spec adiciona structured tool output (PR #371). Até então, o retorno de uma tool era essencialmente texto ou blocos de conteúdo, e cabia ao modelo interpretar. Com output estruturado, a tool pode devolver dados tipados que o client consome de forma previsível, sem depender do LLM parsear texto livre. Para quem constrói pipelines onde o resultado de uma tool alimenta outra, isso reduz a chance de erro de parsing no meio do caminho.
Complementando, o PR #603 adiciona resource links em resultados de tool call: uma tool pode retornar referência a um recurso em vez de despejar o conteúdo inteiro na resposta, útil para arquivos grandes ou dados que o client busca sob demanda.
Mudanças menores que ainda podem morder
Duas mudanças pequenas têm potencial de quebrar sem alarde:
MCP-Protocol-Versionheader agora é obrigatório em requisições HTTP subsequentes depois da negociação de versão (PR #548). Client que não manda o header pode ser rejeitado por servidor estrito.SHOULDvirouMUSTem Lifecycle Operation. O que era recomendação passou a ser exigência. Implementações que tomavam atalho no ciclo de vida da conexão podem deixar de ser conformes.
No lado das adições sem risco: campo _meta em mais tipos de interface (PR #710), campo context no CompletionRequest para incluir variáveis já resolvidas (PR #598) e um campo title para nome de exibição amigável, deixando name livre como identificador programático (PR #663). Esse último é boa notícia para UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → de clients, que antes tinham que escolher entre nome legível e nome estável.
O que fazer com isso
Para quem já tem MCP em produção, o roteiro de migração mais seguro é priorizar por impacto: primeiro auditar autorização, porque é onde mora o furo de segurança e a refatoração mais pesada; depois remover qualquer dependência de batching; então adicionar o header de versão obrigatório e revisar o ciclo de vida. Elicitation, structured output e resource links entram como melhorias incrementais, adotadas conforme o client suporte.
O que fica em aberto é o ritmo de adoção dos SDKs e dos principais clients (Claude Desktop, IDEs com suporte a MCP). Uma spec só quebra de verdade quando os dois lados atualizam, e enquanto houver client antigo falando com servidor novo, a negociação de versão vira o campo de batalha. Vale acompanhar o changelog completo no GitHub antes de assumir que sua stack está conforme.
Fonte: Especificação oficial do Model Context Protocol (MCP) — Changelog
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
