AWS تنشر 6 مقاربات لتحسين أدوات MCP وتوفير مساحة السياق

نشرت AWS في 12 يوليو 2026 دليلاً تقنياً حول مشكلات تصميم أدوات MCP، واقترحت 6 مقاربات عملية لمعالجتها، تبدأ بتحسين الأوصاف وتنتهي بتحليل المعاملات على جانب الخادم بمساعدة AI. وتستند الدراسة إلى اختبار فعلي لواجهة API للبحث في المحتوى التعليمي (K-12).

لماذا تُضعف أدوات MCP جودة النماذج

يساعد Model Context Protocol نماذج LLM على استخدام الأدوات الخارجية، لكن تصميم التعريفات كثيراً ما يكون غير موفّق. وقد رصدت AWS مشكلتين رئيسيتين:

Bloat (التضخم): يحمّل كل خادم MCP تعريفات أدواته في نافذة السياق حتى لو لم تُستخدم. وعند وجود عدة خوادم نشطة، تمتلئ النافذة بالتعريفات قبل أن يطرح المستخدم سؤاله الأول.

Confusion (الالتباس): يؤدي السياق المكتظ إلى تدهور استدلال النموذج. فيخلط LLM بين الأدوات المتشابهة، ويخطئ في المعاملات، ويفسّر القيود تفسيراً خاطئاً. ويزيد من حدة المشكلة التشابه الدلالي بين الأدوات وغموض أسماء المعاملات.

6 مقاربات: طيف كامل من الحلول

اختبرت AWS ست تطبيقات على استعلامات حقيقية، مثل «ابحث عن اختبار في الكسور للصف السابع» و«أحتاج محتوى متوافقاً مع TEKS»:

• V1 (Raw Passthrough): يعرض واجهة API الخلفية كما هي، مع نسبة أخطاء مرتفعة في المعاملات
• V2 (Rich Descriptions): docstrings مفصّلة مع أمثلة، وهي تحسّن الدقة لكن حجم التعريفات يزداد
• V3 (Schema & Defaults): معاملات أُعيدت تسميتها (`discipline` → `subject`)، مع enums من نوع `Literal` وقيم افتراضية معقولة، وهو حل وسط جيد
• V4 (Lazy Loading): التفاصيل (taxonomy) متاحة عبر أداة منفصلة، ما يعطي baseline أدنى لكنه يتطلب استعلامات إضافية
• V5 (Server-side Introspection): يحلل Amazon Nova 2 Lite المعاملات على الخادم، فيكون السلوك مستقراً، لكن ذلك يستلزم استدعاءات inference إضافية
• V6 (Agent-as-Tool): معامل واحد `question: str` وكل المنطق في الداخل، ما يمنح أقصى درجات التحكم لكنه يتطلب بنية تحتية

أبرز توصيات AWS

توصي AWS Prescriptive Guidance بإبقاء معاملات الأداة عند «نحو ثمانية أو أقل». وأظهرت دراسة Anthropic أن التحول إلى مخرجات تفصيلية عند الطلب on-demand يخفض رموز الاستجابة بمقدار الثلثين تقريباً.

وتوصي AWS كذلك بكتابة رسائل خطأ محددة وقابلة للتنفيذ (actionable): فلا تكتفي بعبارة «no results»، بل تصف بدقة ما ينبغي تجربته. كما توصي باستخدام أسماء معاملات مناسبة للمجال بدلاً من أسماء أعمدة قاعدة البيانات، لأن ذلك يقلل التباس النموذج بصورة حادة.

كيف تختار المقاربة المناسبة لمهمتك

لا يوجد حل شامل. فالاختيار يعتمد على عدد المعاملات (قليلة: V3، كثيرة: V4-V5)، ومدى استقرار المفردات، ومتطلبات latency، وما إذا كانت هناك حاجة إلى سلوك موحّد عبر نماذج مختلفة. وفي معظم مهام البحث والتصفية يكفي V3. أما التطبيقات المتخصصة (taxonomy معقدة، استدلال متعدد الخطوات) فتستفيد أكثر من V4-V5.

ماذا يعني ذلك

كثيراً ما تُبطئ أدوات MCP اليوم وكلاء LLM، لكن AWS بيّنت أن المشكلة قابلة للحل عبر هندسة السياق (context engineering). وأصبح لدى المهندسين الآن دليل عملي (playbook) للموازنة بين حجم السياق والدقة، بدلاً من الاستمرار في إضافة الأوصاف دون تمحيص.