Claude resumiu um documento lendo só o começo: o corte silencioso na resposta de um servidor MCP

Um desenvolvedor descobriu que o Claude resumiu com confiança um documento extenso, embora tenha lido, de fato, apenas o início dele. A causa foi um corte imperceptível na resposta do servidor MCP.

O que o desenvolvedor descobriu

O autor conectou a ferramenta mcp-server-fetch ao Claude e pediu ao agente que extraísse alguns trechos específicos de um documento. O modelo respondeu de forma coerente e confiante, sem dar nenhum sinal de problema: o texto dava a impressão de que o agente realmente havia processado o documento inteiro. Só ao analisar o tráfego JSON-RPC entre cliente e servidor, ou seja, a troca bruta de mensagens entre o Claude e a ferramenta conectada, o desenvolvedor percebeu que o conteúdo do documento havia sido cortado na marca de 6000 caracteres.

Além disso, o servidor marcou a resposta truncada como bem-sucedida, sem nenhuma indicação de erro ou truncamento. Do ponto de vista do protocolo, a requisição terminou normalmente: o código de resposta não sinalizou timeout, estouro de limite nem qualquer outra falha. O modelo recebeu dados parciais e os tratou como completos.

• Ferramenta: mcp-server-fetch, usada para obter conteúdo da web e repassá-lo ao modelo
• A resposta foi truncada na marca de 6000 caracteres
• O servidor marcou a resposta truncada como bem-sucedida, sem flag de erro
• No final do texto truncado, o servidor acrescentou uma instrução oculta destinada ao modelo
• O problema só foi detectado com a análise manual do tráfego JSON-RPC entre cliente e servidor

Por que isso é perigoso para agentes

O MCP (Model Context Protocol) é um protocolo aberto que permite a modelos de IA como o Claude se conectarem a ferramentas externas: sistemas de arquivos, bancos de dados e requisições web. Quando uma ferramenta dessas devolve dados incompletos sem um sinal explícito de erro, o modelo não tem como distinguir uma resposta completa de uma parcial. Ele simplesmente trabalha com o que recebeu e entrega o resultado com a mesma confiança que teria se tivesse lido o documento inteiro. Para o usuário, não há diferença visível: a resposta é igualmente coesa, lógica e convincente.

O segundo ponto da descoberta do autor é ainda mais preocupante: bem no final da resposta truncada, o servidor acrescentou uma instrução em texto dirigida ao modelo. Formalmente, ela faz parte do conteúdo que o agente interpreta como dados do documento. Na prática, porém, é um texto de controle inserido pela própria ferramenta depois que o conteúdo real já havia terminado. Para o usuário que não olha por baixo do capô da troca JSON-RPC e vê apenas a resposta final do modelo, essa substituição passa totalmente despercebida: texto coerente, tom confiante e nenhum sinal visível de falha ou de falta de confiabilidade.

O caso ilustra um problema mais amplo da cadeia "modelo–ferramenta": a confiança no resultado de uma ferramenta raramente é verificada na prática, porque a simples existência de uma resposta é tomada como prova de que ela está completa. Enquanto o protocolo não exigir uma sinalização explícita de truncamento, a responsabilidade pela verificação recai, na prática, sobre o desenvolvedor. Cabe a ele registrar e conferir separadamente o tráfego bruto, em vez de confiar no texto final do modelo.

O que isso significa

À medida que agentes baseados no Claude e em outros modelos recorrem cada vez mais a servidores MCP para acessar dados externos, cortes silenciosos e instruções ocultas nas respostas das ferramentas se tornam um risco concreto para a qualidade e a confiabilidade de sistemas agênticos. Desenvolvedores que montam pipelines sobre MCP devem prever, nas próprias ferramentas, verificações de sinais de truncamento e não confiar cegamente nelas, mesmo quando a resposta final do modelo parece totalmente convincente.