Claude resumió un documento tras leer solo el principio: el recorte oculto en la respuesta de un servidor MCP

Un desarrollador descubrió que Claude había resumido con total seguridad un documento extenso, aunque en realidad solo había leído el principio. La causa fue un recorte imperceptible de la respuesta en el lado del servidor MCP.

Qué descubrió el desarrollador

El autor conectó a Claude la herramienta mcp-server-fetch y pidió al agente que extrajera varios fragmentos concretos de un documento. El modelo respondió de forma coherente y segura, sin dar ninguna señal del problema: el texto parecía el de un agente que había procesado el documento completo. El desarrollador solo vio lo que ocurría al analizar el tráfico JSON-RPC entre el cliente y el servidor, es decir, al revisar el intercambio de mensajes en bruto entre Claude y la herramienta conectada. Ahí comprobó que el contenido del documento se había cortado en los 6000 caracteres.

Además, el servidor marcó la respuesta truncada como correcta, sin ninguna indicación de error o de recorte. Desde el punto de vista del protocolo, la petición terminó con normalidad: el código de respuesta no señalaba ni un timeout, ni un límite superado, ni ningún otro fallo. El modelo recibió datos parciales y los trató como si fueran completos.

• Herramienta: mcp-server-fetch, que se usa para obtener contenido web y pasárselo al modelo
• La respuesta se truncó en los 6000 caracteres
• El servidor marcó la respuesta truncada como correcta, sin ningún indicador de error
• Al final del texto truncado, el servidor añadió una instrucción oculta dirigida al modelo
• El problema solo se detectó al analizar manualmente el tráfico JSON-RPC entre el cliente y el servidor

Por qué es peligroso para los agentes

MCP (Model Context Protocol) es un protocolo abierto que permite a modelos de IA como Claude conectarse a herramientas externas: sistemas de archivos, bases de datos o peticiones web. Cuando una de estas herramientas devuelve datos recortados sin una señal de error explícita, el modelo no tiene forma de distinguir una respuesta completa de una parcial. Simplemente trabaja con lo que recibe y presenta el resultado con la misma seguridad que si hubiera leído todo el documento. Para el usuario no hay diferencia aparente: la respuesta es igual de coherente, igual de lógica e igual de convincente.

El segundo hallazgo del autor es todavía más preocupante: al final de la respuesta truncada, el servidor añadió una instrucción de texto dirigida al modelo. Formalmente forma parte del contenido que el agente interpreta como datos del documento, pero en la práctica es texto de control que la propia herramienta insertó cuando el contenido real ya había terminado. Para un usuario que no revisa las tripas del intercambio JSON-RPC y solo ve la respuesta final del modelo, esta sustitución pasa completamente desapercibida: texto coherente, tono seguro y ninguna señal visible de fallo o de falta de fiabilidad.

El caso ilustra un problema más amplio de la cadena «modelo–herramienta»: en la práctica, casi nunca se verifica el resultado de una herramienta, porque el simple hecho de recibir una respuesta se toma como prueba de que está completa. Mientras el protocolo no exija señalar explícitamente los recortes, la responsabilidad de comprobarlo recae de facto en el desarrollador, que debe registrar y contrastar por separado el tráfico en bruto en lugar de fiarse del texto final del modelo.

Qué significa esto

A medida que los agentes basados en Claude y en otros modelos recurren cada vez más a servidores MCP para acceder a datos externos, los recortes silenciosos y las instrucciones ocultas dentro de las respuestas de las herramientas se convierten en un riesgo real para la calidad y la fiabilidad de los sistemas agénticos. Quienes construyen pipelines sobre MCP deberían incorporar en las propias herramientas comprobaciones que detecten señales de truncamiento y no fiarse de ellas a ciegas, aunque la respuesta final del modelo parezca completamente convincente.