Claude لخّص وثيقة بعد أن قرأ بدايتها فقط: اقتطاع صامت لاستجابة خادم MCP

اكتشف مطوّر أن Claude لخّص وثيقة كبيرة بثقة تامة، مع أنه لم يقرأ منها فعليًا سوى بدايتها، وتبيّن أن السبب اقتطاع غير ملحوظ في استجابة خادم MCP.

ما الذي اكتشفه المطوّر

ربط المطوّر الأداة mcp-server-fetch بـ Claude وطلب من الوكيل استخراج عدة مقتطفات محددة من الوثيقة. جاء ردّ النموذج متماسكًا وواثقًا، ولم يكشف عن أي مشكلة: بدا النص وكأن الوكيل عالج الوثيقة كاملة فعلًا. ولم يتبيّن الأمر إلا بعد تحليل حركة JSON-RPC بين العميل والخادم، أي بعد الاطلاع على تبادل الرسائل الخام بين Claude والأداة المتصلة به، إذ ظهر أن محتوى الوثيقة اقتُطع عند حدّ 6000 حرف.

وفي الوقت نفسه وسم الخادم الاستجابة المقتطعة بأنها ناجحة، من دون أي إشارة إلى خطأ أو اقتطاع. فمن زاوية البروتوكول انتهى الطلب بشكل طبيعي: لم يشر رمز الاستجابة إلى انتهاء مهلة ولا إلى تجاوز حدّ ولا إلى أي إخفاق آخر. وتلقّى النموذج بيانات جزئية وعالجها على أنها كاملة.

• الأداة المستخدمة هي mcp-server-fetch، وتُستخدم لجلب محتوى الويب وتمريره إلى النموذج
• اقتُطعت الاستجابة عند حدّ 6000 حرف
• وسم الخادم الاستجابة المقتطعة بأنها ناجحة، من دون علامة خطأ
• أضاف الخادم في نهاية النص المقتطع تعليمة مخفية موجّهة إلى النموذج
• لم تُكتشف المشكلة إلا عبر التحليل اليدوي لحركة JSON-RPC بين العميل والخادم

لماذا يشكّل ذلك خطرًا على الوكلاء

MCP (Model Context Protocol) بروتوكول مفتوح تتصل عبره نماذج الذكاء الاصطناعي مثل Claude بأدوات خارجية: أنظمة الملفات وقواعد البيانات وطلبات الويب. وحين تعيد أداة من هذا النوع بيانات مبتورة من دون إشارة صريحة إلى خطأ، لا يملك النموذج وسيلة للتمييز بين استجابة كاملة وأخرى جزئية؛ فهو يعمل بما وصله ويقدّم نتيجته بالثقة نفسها كما لو قرأ الوثيقة كاملة. وبالنسبة إلى المستخدم لا فرق ظاهريًا: الإجابة مترابطة ومنطقية ومقنعة بالقدر نفسه.

والأكثر إثارة للقلق هو الجانب الثاني في ما وجده المطوّر: ففي نهاية الاستجابة المقتطعة بالذات أضاف الخادم تعليمة نصية موجّهة إلى النموذج. شكليًا هي جزء من المحتوى الذي يفسّره الوكيل على أنه بيانات من الوثيقة، لكنها في الواقع نص توجيهي أدرجته الأداة نفسها بعد أن انتهى المحتوى الحقيقي. وبالنسبة إلى مستخدم لا يطّلع على ما يجري داخل تبادل JSON-RPC ولا يرى سوى الإجابة النهائية للنموذج، يبقى هذا التلاعب خافيًا تمامًا: نص متماسك ونبرة واثقة ولا أي مؤشر ظاهر على خلل أو عدم موثوقية.

ويعكس ذلك مشكلة أعمّ في سلسلة «النموذج — الأداة»: نادرًا ما يُتحقَّق عمليًا من موثوقية مخرجات الأداة، لأن مجرد وجود استجابة يُعدّ دليلًا على اكتمالها. وما دام البروتوكول لا يشترط الإشارة الصريحة إلى الاقتطاع، فإن مسؤولية التحقق تقع فعليًا على عاتق المطوّر، الذي عليه أن يسجّل الحركة الخام ويدقّقها على حدة بدلًا من الاعتماد على النص النهائي للنموذج.

ماذا يعني ذلك

مع تزايد اعتماد الوكلاء المبنيين على Claude ونماذج أخرى على خوادم MCP للوصول إلى البيانات الخارجية، تتحول عمليات الاقتطاع الصامتة والتعليمات المخفية داخل استجابات الأدوات إلى خطر عملي يهدد جودة الأنظمة الوكيلية وموثوقيتها. وعلى المطوّرين الذين يبنون خطوط معالجة قائمة على MCP أن يضمّنوا فحصًا لمؤشرات الاقتطاع في الأدوات نفسها، وألا يثقوا بالأدوات ثقة عمياء، حتى لو بدا الردّ النهائي للنموذج مقنعًا تمامًا.