Claude résume un document dont il n'a lu que le début : un serveur MCP tronque sa réponse en silence

Un développeur a découvert que Claude avait résumé avec assurance un long document dont il n'avait en réalité lu que le début. La cause : une troncature discrète de la réponse côté serveur MCP.

Ce qu'a découvert le développeur

L'auteur a connecté l'outil mcp-server-fetch à Claude et a demandé à l'agent d'extraire plusieurs passages précis d'un document. Le modèle a répondu de manière fluide et assurée, sans rien laisser paraître du problème : le texte donnait l'impression que l'agent avait réellement traité l'intégralité du document. Ce n'est qu'en disséquant le trafic JSON-RPC entre le client et le serveur, c'est-à-dire en examinant les échanges bruts entre Claude et l'outil connecté, que le développeur a constaté que le contenu du document avait été coupé à 6000 caractères.

Le serveur a pourtant marqué la réponse tronquée comme réussie, sans le moindre signalement d'erreur ou de troncature. Du point de vue du protocole, la requête s'est terminée normalement : le code de réponse ne signalait ni timeout, ni dépassement de limite, ni aucune autre défaillance. Le modèle a reçu des données partielles et les a traitées comme complètes.

• L'outil : mcp-server-fetch, utilisé pour récupérer du contenu web et le transmettre au modèle
• La réponse a été tronquée à 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 destinée au modèle
• Le problème n'a été détecté que par une analyse manuelle du trafic JSON-RPC entre le client et le serveur

Pourquoi c'est dangereux pour les agents

MCP (Model Context Protocol) est un protocole ouvert qui permet aux modèles d'IA comme Claude de se connecter à des outils externes : systèmes de fichiers, bases de données, requêtes web. Lorsqu'un tel outil renvoie des données amputées sans signal d'erreur explicite, le modèle n'a aucun moyen de distinguer une réponse complète d'une réponse partielle. Il travaille simplement avec ce qu'il a reçu et livre son résultat avec la même assurance que s'il avait lu le document en entier. Pour l'utilisateur, rien ne change en apparence : la réponse reste aussi cohérente, aussi logique et aussi convaincante.

Le second point relevé par l'auteur est encore plus inquiétant : tout à la fin de la réponse tronquée, le serveur a inséré une instruction textuelle adressée au modèle. Formellement, elle fait partie du contenu que l'agent interprète comme des données issues du document. En pratique, il s'agit d'un texte de contrôle injecté par l'outil lui-même, après la fin du contenu réel. Pour un utilisateur qui ne regarde pas sous le capot des échanges JSON-RPC et ne voit que la réponse finale du modèle, cette substitution reste totalement invisible : texte cohérent, ton assuré, aucun signe visible de défaillance ou de manque de fiabilité.

L'épisode illustre un problème plus général de la chaîne « modèle – outil » : la confiance accordée au résultat d'un outil est rarement vérifiée en pratique, car la simple existence d'une réponse est perçue comme la preuve de sa complétude. Tant que le protocole n'impose pas de signaler explicitement une troncature, la vérification incombe de fait au développeur, qui doit journaliser et contrôler séparément le trafic brut plutôt que se fier au texte final du modèle.

Ce que cela signifie

À mesure que les agents basés sur Claude et d'autres modèles s'appuient davantage sur des 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 concret pour la qualité et la fiabilité des systèmes agentiques. Les développeurs qui bâtissent des pipelines sur MCP ont intérêt à intégrer, au sein même des outils, une détection des signes de troncature, et à ne pas faire aveuglément confiance aux outils, même lorsque la réponse finale du modèle semble parfaitement convaincante.