الفصل 3 — أوّليات الخادم: عرض السياق والقدرات
المقالة الثالثة من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. حيث نَتعلَّم ماذا يَستطيع خادم MCP فعلاً أن يقول — ثلاثة أسماء، ثلاث دورات حياة، ثلاثة نماذج خطأ — ولماذا يُقرِّر انضباط اختيار الصحيح ما إذا كان الخادم يَتمدَّد أم يَتراكم.
لماذا يوجد هذا الفصل
البروتوكول مفيدٌ بقدر ما يُتيح لك قوله. بنى الفصل 2 النموذج الذهني للمُضيف والعميل والخادم، وراقَب الجلسة تأتي حيةً عبر التفاوض على القدرات. ما إن تَكتمل المصافحة ويَعرف الطرفان ما يَستطيع الآخر فعله، ماذا على الطاولة محدَّداً؟ يُجيب MCP بثلاثة أسماء: الموارد والموجِّهات والأدوات. تَبدو متشابهة سطحياً — كلٌّ شيءٌ مسمَّى موصوفٌ بمخططٍ يَستطيع الخادم إنتاجه أو تشغيله — لكنها تُمثِّل ثلاث نوايا متباينة. الموارد قراءة حالة. والموجِّهات سقَّالة قابلة لإعادة الاستخدام. والأدوات أفعال كتابة. يَمشي الفصل على كلٍّ بالترتيب: المخطط، دورة الحياة، نموذج الخطأ، والأماكن التي يُخطئ فيها المهندسون.
3.1 الموارد: بيانات سياقية للقراءة فقط
المورد بياناتٌ يَستطيع الخادم تسليمها للنموذج بوصفها سياقاً. الكلمة المُحدِّدة للقراءة فقط. لا يُغيِّر المورد العالم؛ يَصفه. إذا تسبَّب الجلب في تغيُّر حالةٍ في مكانٍ آخر — صفُّ سجل تدقيق، عدَّاد يُزاد، خطاف ويب يُطلَق — فهو ليس مورداً، بل أداةٌ تَلبس زيّاً. رسم هذا الخط بحدَّةٍ هو الانضباط الأول لتصميم خادم MCP.
لكل موردٍ URI ثابت في مخططٍ يَختاره الخادم (file://، postgres://، linear://issue/ENG-1234)، إضافةً إلى البيانات الوصفية: اسم، وصفٌ اختياري، نوع MIME، حجمٌ اختياري. ولا حقلٌ من هذه زخرفي. مَوردٌ بلا وصفٍ مَوردٌ لا يَستطيع النموذج تقييمه. دورة الحياة مباشرة: resources/list للتعداد، resources/read للجلب. ولا يوجد resources/write — إذا أراد الخادم كتاباتٍ، فعليه أن يَعرض أداة. يُبقي اللاتماثل حدّ الثقة مرئياً.
نمطان يَجعلان الموارد عمليةً على نطاقٍ واسع. قوالب URI تُتيح للخادم عرض نقطة قراءةٍ مُعَلَّمة (db://orders/{order_id}) بدل تعداد ملايين الصفوف. والاشتراكات تُتيح للمُضيف تسجيل اهتمامٍ بـ URI وتلقي notifications/resources/updated حين تتغيَّر البيانات الكامنة — البديل هو الاستطلاع بإيقاع النموذج اللغوي، وهو هدرٌ في الاتجاهَين. الشرك الذي يجب تَجنُّبه هو إلقاء كل كائنٍ داخلي على قائمة الموارد عند بدء الجلسة: قائمةٌ بثلاثة آلاف موردٍ تأكل عشرات آلاف الرموز قبل أن يكتب المستخدم. اعرض قمَّةً مُختارةً مع قوالب، ودَع النموذج يَبحث في الذيل الطويل.
3.2 الموجِّهات: قوالب وسير عمل قابلة لإعادة الاستخدام
الموجِّهات في MCP لا علاقة لها بموجِّه النظام لنموذجٍ لغوي. إنها قوالب مُعرَّفة على الخادم قابلة لإعادة الاستخدام يَستطيع المستخدم — أو مُضيفٌ نيابةً عنه — استدعاءها لبدء تفاعلٍ بعينه. الموجِّه أقرب إلى أمرٍ مائل منه إلى شخصية. الغرض أن يَستطيع خادمٌ شحن أنماط تفاعلٍ مُجرَّبة جنباً إلى جنب مع الأدوات والموارد التي يَعرضها، فلا يَضطر الإنسان عند لوحة المفاتيح إلى تذكُّر كيف يَصوغ الطلب.
للموجِّه اسم، ووصفٌ اختياري، وقائمة وسائط. يَستدعي المُضيف prompts/list للاكتشاف، ثم prompts/get لتوسيع موجِّهٍ إلى متتالية رسائل يَستطيع المُضيف تَغذيتها في حلقة نموذجه. قد يُشير الموجِّه إلى مواردٍ بـ URI، وفي تلك الحالة يَدمجها المُضيف داخلياً قبل الإرسال. يَكتب الخادم سيناريو الأدوار الافتتاحية؛ ويَأخذ النموذج من ثَمَّ.
التمييز بين الموجِّهات ورسائل النظام يَهُمّ. مستخدمٌ يَستدعي /review_pr يَرى، في سجل محادثته، المساعد يَبدأ العمل على مراجعة — يَفهم ما الذي بدأ، يَستطيع المقاطعة، يَستطيع التدقيق. لو كان الخادم بدلاً من ذلك يُلحق تعليماتٍ بصمتٍ بموجِّه نظام المُضيف، لما كان للمستخدم فكرةٌ لماذا تَصرَّف المساعد فجأةً بشكلٍ مختلف. الموجِّهات سقَّالة مرئية للمستخدم؛ وموجِّهات النظام تأطير المُضيف. لا ينبغي الخلط بينهما. الانضباط أن أيَّ محتوى موجِّهٍ ما كان المستخدم سيُوافق عليه لو عُرض صراحةً عيبٌ.
3.3 الأدوات: أفعال، مخرجاتٌ مهيكلة، وخصوصية الاستدعاء
الأدوات حيث يصير MCP مُثيراً وخطيراً بالقدر ذاته. الموارد قراءة؛ والموجِّهات سقَّالة؛ والأدوات كتابة — تُنشئ صفوفاً، تُرسل رسائل، تَنشر خدمات، تُحاسب بطاقات. لكل أداةٍ اسم، ووصف، ومخطط مدخلاتٍ بـ JSON Schema. الوصف هو أهم حقلٍ على سطح MCP كلِّه، لأنه النص الذي يَستخدمه النموذج ليُقرِّر استدعاء الأداة، ومتى يَستدعيها، وبأيِّ وسائط. أداةٌ يقول وصفها «تُرسل بريداً إلكترونياً» يَمتدّ النموذج إليها كلما ظهرت نية على شكل بريد. أداةٌ يقول وصفها «تُرسل بريداً إلكترونياً معاملاتياً عبر منصة التسويق، فقط لعناوين عملاء مُتحقَّق منها؛ ليس للمراسلات الشخصية» يَستخدمها النموذج بأكثر تمييز.
نموذج الخطأ بقناتَين. خطأ بروتوكول (وسائط مشوَّهة، أداةٌ مجهولة) يُعيد خطأ JSON-RPC وهو فشل تأطير. خطأ أداة (مُستلِم مرفوض، قرصٌ ممتلئ) يُعيد استجابةً ناجحة مع isError: true وكتلة محتوى تُفسِّر ما حدث. التمييز يَهُمّ: على النموذج رؤية أخطاء الأداة والتكيُّف؛ وعلى المُضيف رؤية أخطاء البروتوكول واستعادة النقل. خلطهما يَسلب النموذج المعلومات التي يَحتاج.
يَدعم MCP الحديث structuredContent جنباً إلى جنب مع مصفوفة المحتوى النثرية، تَتطابق مع outputSchema مُعلَن. الأثر التراكمي عبر أثرٍ طويل حقيقي: مخرجاتُ أدواتٍ قصيرةٌ مهيكلة تَترك للنموذج مساحةً لاستدلالٍ حقيقي؛ ومخرجاتٌ نثرية طويلة تأكل ميزانية السياق. انضباطان آخران جديران بالتسمية. الحدّ الأدنى: اثنتا عشرة أداةً موصوفةً جيداً تَهزم ستِّينَ في كل قياسٍ تقريباً؛ اعرض find_users بمُرشِّحٍ مهيكَل بدل list_users وget_user وsearch_users وcount_users. خصوصية الاستدعاء: عواصف إعادة المحاولة محتومة؛ أداةٌ تَقبل مفتاح خصوصية استدعاءٍ أو تَستخدم مخطط مُعرِّف حتمي تَجعل انقطاعات الشبكة عملياتٍ فارغة لا حوادث سلامة بيانات.
3.4 التركيب: كيف تتعاون الأوّليات الثلاث
الأوّليات أكثر فائدةً حين تَعمل معاً. خادمٌ مُصمَّم جيداً يَعرض عادةً بعضاً من كلٍّ: حِفنة موجِّهاتٍ لِبَذر التفاعلات الشائعة، مجموعةً صغيرةً من الأدوات للأفعال المُهمَّة، ومجموعةً قد تكون كبيرة من الموارد التي تُمَدّ السياق. خادم دعم عملاء قد يَعرض ملفات العملاء وتاريخ التذاكر بوصفها موارد، reply_to_ticket وescalate_ticket أدواتٍ، /triage_ticket موجِّهاً يُحَمِّل الموارد الصحيحة ويَطلب من النموذج التصنيف. الموجِّهات تَبذُر؛ والموارد تَملأ الوضع؛ والأدوات تُغيِّر العالم.
الإغراء، حالما ترى كم الأوّليات مرنة، أن تَدفع كلَّ شيء عبر واحدة. تَستطيع تزييف موارد بأدواتٍ للقراءة فقط، تزييف أدواتٍ بموجِّهاتٍ تَدفع النموذج لإخراج أوامر، تزييف موجِّهاتٍ بمواردَ تَحوي تعليمات. كلٌّ يَضغط مساحة التصميم ويَفقد شيئاً. الموارد التي زيَّفتها أدواتٍ لا يُمكن تخزينها مؤقتاً، الاشتراك بها، أو دمجها في توسيع موجِّه. الأدوات التي زيَّفتها موجِّهات لا يُمكن التفويض عليها في نقطة الاستدعاء وليس لها قناة مخرجاتٍ مهيكلة. الأوّليات ليست اعتباطية؛ هي مُفصَّلة ليَعرف المُضيف كيف يُعامل كلاً منها بأمان. احترام التفصيل جزءٌ من عقد البروتوكول.
ما يُمهِّد له الفصل 3
مَشيت على جانب الخادم من الصفقة. يَعرض الخادم الموارد والموجِّهات والأدوات، كلٌّ بمخططه ودورة حياته ونموذج خطئه. الانضباط اختيار الأوّلية الصحيحة لكل شيءٍ يَستطيع الخادم فعله، تسميتها ووصفها بعنايةٍ، ومقاومة التحميل. لكن MCP ليس طريقاً وحيد الاتجاه. يَستطيع المُضيف أيضاً عرض قدراتٍ للخادم — وذلك حيث تَسكن أكثر الاختيارات تشويقاً وحساسيةً أمنياً للبروتوكول.
التالي — الفصل 4: أوّليات العميل — المعاينة والجذور والاستنطاق. السطح المعكوس — ما يُعيره المُضيف للخادم — والآثار الأمنية لكل قدرةٍ تُسلَّم عبر حدِّ الثقة.
