MCP 2025-06-18: elicitation e as novas regras de autorização podem quebrar agentes antigos sem aviso

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 →, o padrão que conecta agentes de IA a ferramentas e fontes de dados externas, passou por uma revisão de especificação em 18 de junho de 2025. Ela substituiu a revisão anterior, de 26 de março de 2025, e trouxe mudanças que não são cosméticas: reescreveram como servidor e cliente negociam versão, como a autorização funciona e como um servidor pode pedir informação extra no meio de uma tarefa. O changelog oficial do MCP (modelcontextprotocol.io) lista as mudanças, mas não dramatiza o tamanho do impacto para quem já tem agente rodando.

Quase um ano e meio depois, boa parte dos times que subiram servidores MCP no início de 2025 ainda está no cliente antigo. O problema é que essas mudanças não quebram com erro explícito: elas quebram por omissão. Um campo que o cliente não reconhece é ignorado, não rejeitado. Um header que falta na requisição HTTP pode levar o servidor a interpretar a versão errada do protocolo. O agente continua rodando, só que com menos capacidade do que o servidor oferece, ou pior, com uma falha de segurança aberta.

Elicitation: o servidor agora pode parar e perguntar

A mudança mais visível da revisão é o suporte a elicitation (PR #382 no repositório da spec), que dá ao servidor MCP a capacidade de pedir informação adicional ao usuário no meio de uma interação, em vez de falhar ou assumir um valor padrão. Antes, se uma tool precisava de um dado que não veio na chamada, a prática comum era o servidor devolver erro ou o cliente simplesmente não suportar o caso.

Com elicitation, o servidor envia uma mensagem elicitation/create com um schema do que precisa, e o cliente decide como coletar isso do usuário (formulário, prompt, diálogo). A resposta carrega uma ação, que indica se o usuário aceitou, recusou ou cancelou o pedido:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "elicitation/create",
  "params": {
    "message": "Preciso do CEP para calcular o frete",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "cep": { "type": "string", "title": "CEP" }
      },
      "required": ["cep"]
    }
  }
}

A resposta do cliente segue o mesmo id e devolve uma ação com o conteúdo coletado:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "action": "accept",
    "content": { "cep": "01310-100" }
  }
}

O risco prático: um cliente que não implementa esse método não sabe o que fazer com a mensagem elicitation/create. Dependendo de como o cliente trata métodos desconhecidos, a tool pode travar esperando uma resposta que nunca chega, ou o servidor interpreta silêncio como recusa e segue com dado incompleto. Nenhum dos dois casos aparece como erro no log do jeito que um dev espera.

Autorização: o servidor MCP virou Resource Server

A segunda mudança estrutural é de segurança. A revisão passou a classificar servidores MCP como OAuth Resource Servers (PR #338), exigindo que eles exponham metadados de recurso protegido apontando para o Authorization Server correspondente. Isso formaliza algo que antes era implícito: o servidor MCP não autentica ninguém sozinho, ele delega para um provedor OAuth e só valida o token recebido.

Junto disso veio uma exigência dura para quem implementa cliente: clientes MCP precisam implementar Resource Indicators conforme a RFC 8707 (PR #734). Essa RFC define como o cliente informa, no pedido de token, para qual recurso específico aquele token vale. Sem isso, a especificação deixa claro o motivo: um servidor malicioso pode obter um token emitido para outro recurso e reutilizá-lo indevidamente.

A ausência de indicadores de recurso pode permitir que servidores maliciosos obtenham tokens de acesso destinados a outros recursos.

Changelog da especificação MCP, revisão 2025-06-18Require MCP clients to implement Resource Indicators as described in RFC 8707 to prevent malicious servers from obtaining access tokens.

Esse não é um ajuste de API, é uma correção de modelo de ameaça. Um cliente que ainda não passa o Resource Indicator no fluxo de autorização está potencialmente vulnerável ao cenário que a mudança existe para fechar, mesmo que a integração continue funcionando no dia a dia sem nenhum sintoma visível.

JSON-RPC batching saiu do protocolo

A revisão removeu o suporte a batching de JSON-RPC (PR #416), ou seja, a possibilidade de enviar várias chamadas em um único array de requisições. Clientes ou servidores que ainda montam payloads em lote param de ter essas mensagens reconhecidas pela outra ponta. Não há aviso de depreciação suave aqui: a capacidade simplesmente não existe mais na spec atual, então qualquer código que dependa dela precisa ser reescrito para chamadas individuais.

O header que a spec passou a exigir

Outra mudança que costuma passar batido: ao usar transporte HTTP, a versão de protocolo negociada agora precisa ser especificada via MCP-Protocol-Version nas requisições subsequentes (PR #548). Antes, a negociação de versão acontecia uma vez e ficava implícita na sessão. Agora cada chamada HTTP depois do handshake carrega esse header.

Um cliente escrito antes dessa mudança simplesmente não popula o header, porque ele nunca precisou. O changelog não detalha o comportamento exato do servidor diante da ausência do header, o que por si só é um motivo para testar: o comportamento pode variar entre implementações de servidor, e assumir que "vai funcionar do mesmo jeito" é apostar sem saber a regra.

Outras mudanças de schema que afetam integração

A lista de mudanças menores também tem efeito cumulativo:

• Structured tool output (PR #371): respostas de tool podem vir com saída estruturada, não só texto livre, o que muda como o cliente precisa parsear o resultado.
• Resource links em resultados de tool (PR #603): uma tool pode devolver um link para um recurso em vez do conteúdo inteiro, exigindo que o cliente saiba buscar esse recurso depois.
• Campo title (PR #663): separa nome de exibição (title) de identificador programático (name), então código que usava name para mostrar texto ao usuário pode precisar migrar para title.
• Campo _meta (PR #710): adicionado a mais tipos de interface, com regras próprias de uso que clientes antigos ignoram por padrão.
• Mudança de SHOULD para MUST em uma operação do ciclo de vida da conexão, tornando obrigatório algo que antes era recomendação.

Nenhuma dessas mudanças quebra sozinha, mas juntas elas formam uma superfície de compatibilidade bem diferente da revisão de março.

O roteiro que eu seguiria para testar hoje

Em um agente com servidor MCP já em produção, o caminho mais direto para validar a exposição a essas mudanças seria:

1. Conferir a versão de protocolo que o cliente anuncia no handshake e comparar com 2025-06-18 na documentação do SDK usado.
2. Simular uma chamada de tool que dispare elicitation/create e observar se o cliente trata a mensagem ou a ignora silenciosamente.
3. Revisar o fluxo de autorização: o cliente envia o parâmetro de Resource Indicator da RFC 8707 na requisição de token, ou ainda assume um token genérico?
4. Procurar no código qualquer envio de array JSON-RPC em lote e substituir por chamadas individuais.
5. Checar se as requisições HTTP subsequentes ao handshake carregam o header MCP-Protocol-Version.

Nenhum desses testes exige reescrever o agente do zero. Mas pular essa checagem significa descobrir o problema pela denúncia de um usuário, não por um log de erro.

Quando isso ainda não é urgente

Agentes que só consomem servidores MCP internos, controlados pelo mesmo time, com SDK atualizado dos dois lados, já absorveram boa parte dessas mudanças sem esforço manual, porque os SDKs oficiais tendem a implementar a revisão vigente. O risco concentra-se em integrações com servidores MCP de terceiros, implementações caseiras de cliente ou código que foi escrito direto contra a revisão de março de 2025 e nunca mais revisitado. Nesses casos, a lacuna entre o que o servidor espera e o que o cliente entende é onde o agente falha sem avisar.

Fonte: Especificação oficial do Model Context Protocol (MCP), revisão 2025-06-18