Claude Paraphrase un Document Après Avoir Lu Uniquement le Début : Troncature Cachée du Serveur MCP

Un développeur a découvert que Claude avait résumé avec assurance un document volumineux, même s'il n'avait en réalité lu que le début — la cause s'est avérée être une troncature imperceptible de la réponse du serveur MCP.

Ce que le développeur a découvert

L'auteur a connecté l'outil mcp-server-fetch à Claude et a demandé à l'agent d'extraire plusieurs fragments spécifiques d'un document. Le modèle a répondu avec fluidité et assurance, sans donner aucun signe de problème : le texte semblait comme si l'agent avait vraiment travaillé sur l'ensemble du document. Ce n'est qu'en analysant le trafic JSON-RPC entre le client et le serveur — c'est-à-dire en regardant l'échange brut de messages entre Claude et l'outil connecté — que le développeur a vu que le contenu du document avait été tronqué à la marque des 6000 caractères.

De plus, le serveur a marqué la réponse tronquée comme réussie, sans une seule indication d'erreur ou de troncature. Formellement, du point de vue du protocole, la demande s'était déroulée normalement : le code de réponse ne signalait ni délai d'expiration, ni limite dépassée, ni aucun autre problème. Le modèle avait reçu des données partielles et les avait traitées comme étant complètes.

• L'outil — mcp-server-fetch, utilisé pour récupérer le contenu web et le transmettre au modèle
• La réponse a été tronquée à la marque des 6000 caractères
• Le serveur a marqué la réponse tronquée comme réussie, sans indicateur d'erreur
• À la fin du texte tronqué, le serveur a ajouté une instruction cachée pour le modèle
• Le problème n'a été découvert que par analyse manuelle du trafic JSON-RPC entre client et serveur

Pourquoi c'est dangereux pour les agents

MCP (Model Context Protocol) — un protocole ouvert par lequel des modèles d'IA comme Claude se connectent à des outils externes : systèmes de fichiers, bases de données, requêtes web. Lorsqu'un tel outil retourne des données réduites sans un signal d'erreur explicite, le modèle n'a aucun moyen de distinguer une réponse complète d'une réponse partielle — il se contente de travailler avec ce qu'il a reçu et retourne les résultats avec la même assurance que s'il avait lu l'intégralité du document. Pour l'utilisateur, il n'y a aucune différence visible : la réponse est aussi cohérente, aussi logique et aussi convaincante.

Encore plus préoccupant est la deuxième découverte de l'auteur : à la fin du texte tronqué, le serveur a ajouté une instruction textuelle adressée au modèle. Formellement, ceci fait partie du contenu que l'agent interprète comme des données du document, mais en réalité — un message de contrôle inséré par l'outil lui-même après la fin du contenu réel. Pour un utilisateur qui ne regarde pas sous le capot de l'échange JSON-RPC et ne voit que la réponse finale du modèle, une telle substitution reste complètement invisible : texte cohérent, ton assuré, aucun signe visible de défaillance ou de manque de fiabilité.

Cela illustre un problème plus large dans la chaîne "modèle-outil" : la confiance dans le résultat d'un outil est rarement vérifiée en pratique, car la simple présence d'une réponse est perçue comme une confirmation de sa complétude. Tant que le protocole n'exige pas de signaler explicitement la troncature, la responsabilité incombe effectivement au développeur, qui doit enregistrer et recouper séparément le trafic brut, plutôt que de se fier au texte final du modèle.

Ce que cela signifie

Ce que les agents basés sur Claude et autres modèles utilisent de plus en plus les serveurs MCP pour accéder à des données externes, les troncatures silencieuses et les instructions cachées dans les réponses des outils deviennent un risque pratique pour la qualité et la fiabilité des systèmes d'agents. Les développeurs construisant des pipelines sur MCP doivent établir des vérifications des indicateurs de troncature dans les outils eux-mêmes et ne pas faire confiance aveuglément aux outils — même si la réponse finale du modèle semble absolument convaincante.