الفصل 5 — بروتوكولات النقل والاكتشاف

المقالة الخامسة من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. كل رسالةٍ في الفصلَين 3 و4 كانت طافيةً في الهواء بين المُضيف والخادم — لكن الرسائل لا تَطفو، تَركب نقلاً، والنقل يُقرِّر بهدوءٍ تقريباً كل شيءٍ تشغيلي بشأن تكاملٍ.

لماذا يوجد هذا الفصل

يُعرِّف MCP صيغة رسائله — JSON-RPC 2.0 فوق قناةٍ ثنائية الاتجاه — ثم يُعرِّف ثلاثة نقولٍ تُنفِّذ القناة. النقول ليست قابلةً للتبديل. كلٌّ يَلائم نمط نشر، يَحمل أمتعةً تشغيليةً مختلفة، ويَعرض أسطحاً أمنيةً مختلفة. سؤالٌ ثانٍ يُخَيِّم على الأرض ذاتها: كيف يَجد المُضيف خادماً في المقام الأول؟ ما لم يَعرف المُضيف أن خادماً موجودٌ وأين يَسكن، فإن أجمل البروتوكولات مواصفةً لا يُنتج محادثات.

يَمشي هذا الفصل على كليهما. تُقرِّر النقول هل الخادم مُتزامِنُ الموقع أم بعيد، هل لديك مصادقةٌ أم عزل عمليات، وكيف يَتمدَّد الخادم. وتُقرِّر طبقة الاكتشاف هل خادمك شيءٌ يَستخدمه مهندسٌ واحد أم شيءٌ يَستطيع فريقٌ تَبَنِّيه.

5.1 stdio وSSE وHTTP القابل للبث

stdio هو إطلاق المُضيف للخادم بوصفه عملية ابن. يَكتب المُضيف JSON-RPC إلى stdin للابن ويَقرأ الاستجابات من stdout؛ ويَحمل stderr السجلات. لا منفذ، لا مقبس، لا شبكة. تُعالج المصادقة بحدّ إطلاق العملية في نظام التشغيل. Claude Desktop وCursor وفاحص MCP الرسمي كلها تَستخدم stdio للخوادم المحلية. النموذج صادقٌ بشأن ما هو: أداةٌ على آلتك، مُتزامنة الموقع، في نطاق ثقة المُضيف ذاته. لا يُمكن مشاركته عبر مُضيفين، لا يَستطيع الجَري على آلةٍ مختلفة، وواحدٌ لكل مُضيف هي التعدُّدية الوحيدة المتاحة — خمسة عملاء يُريدون الخادم ذاته يَحرقون خمس عمليات.

HTTP+SSE كان جواب MCP الأول لحالة الشبكة. ثنائي الاتجاه، لكنه ازدواجٌ مُلصَقٌ من قطعتَين أُحاديتَي الاتجاه. مهجور. لا يزال في البرية. ستَلتقي بخوادم قائمةٍ على SSE لبعض الوقت بعد.

HTTP القابل للبث هو نقل الشبكة المُفضَّل. نقطة نهايةٍ مفردة — عادةً /mcp — تَقبل طلبات JSON-RPC وتُجيب إما باستجابةٍ واحدة (للاستدعاءات المتزامنة) أو ببثٍّ من أحداث Server-Sent حين تكون ثمة رسائل عدة، بما في ذلك الإشعارات التي يَبدأها الخادم. تُعرَّف الجلسات بترويسة Mcp-Session-Id مضبوطةٍ عند التهيئة ومُمَرَّرةٍ عبر كل طلبٍ تالٍ. الجلسة وحدة الحالة، قابلة للتحرير بـ DELETE أو تُحصد بمهلةٍ زمنية. يَتركَّب النقل نظيفاً مع موزِّنات الحِمل، الوكلاء العكسيين، حواف التخزين المؤقت، وTLS. التمديد الأفقي جلسةٌ لاصقةٌ على معرِّف الجلسة. لا شيء من هذا هندسة HTTP حديثة؛ النقطة أن MCP يَلائم داخلها دون اختراع طبقةٍ جديدة.

الاختيار قرارٌ أمني بقدر ما هو قرار نشر. خوادم stdio تَميل نحو الإفراط في الامتياز — تَرث صلاحيات نظام ملفات المستخدم وشبكته، بلا مصادقةٍ لأن لا مُتصِل بعيد. خوادم الشبكة تُواجه الإنترنت المفتوح وعليها مصادقة كل طلب، مع OAuth 2.1 المعيار المُتقارِب الآن. اختيار النقل الخطأ لوضعك الأمني يُجبرك على إلصاق ما كان ينبغي أن يكون مَبنياً.

5.2 اكتشاف الخادم: .well-known/mcp.json وبطاقات الخادم

بروتوكولٌ يَتطلَّب من كل مُضيفٍ التكوين اليدوي مع كل عنوان خادمٍ لا يَصير نظاماً بيئياً. يَصير كابوس تكوين. تَستعير طبقة اكتشاف MCP نمط URI المعروف من RFC 8615 — الآلية ذاتها المُستخدمة من robots.txt و.well-known/openid-configuration. يَنشر خادمٌ .well-known/mcp.json على عنوانه الأساس. يَجلبها المُضيف، يُحَلِّلها، ويَتعلَّم ما يَدَّعيه الخادم عن نفسه: نقطة نهاية MCP، نسخة البروتوكول، مخطط المصادقة، البيانات الوصفية للهوية، ومؤشِّرٌ إلى بطاقة الخادم.

بطاقة الخادم هي openapi.json الخاص بـ MCP: قطعة أثرٍ تَصِف نفسها يَستطيع البشر والآلات استهلاكها. يَستطيع المُضيف عرض البطاقة على المستخدم خلال تدفُّق الاتصال — «يقول هذا الخادم إنه يَستطيع الوصول إلى مساحة عمل Linear الخاصة بك، سيقرأ التذاكر لكنه لن يَحذفها، تُديره Linear ذاتها، يَستخدم OAuth» — ويَستطيع المستخدم اتخاذ قرار قبول الادِّعاء. البطاقات في شكلها غير المُوَقَّع ادِّعاءات، لا برهان. التخفيف تَشهيدٌ مُوَقَّع، بنموذج توقيعٍ تقارَب على نمط sigstore عبر OIDC: بطاقةٌ مُوَقَّعة عبر تكامل OIDC في GitHub تحت github.com/some-org/mcp-server يُمكن التحقُّق منها بأيِّ مُضيفٍ يَثق بادِّعاءات هوية GitHub. تَستطيع المُضيفات وَضع سياسةٍ فوقها — الثقة فقط بالبطاقات المُوَقَّعة، فقط من مُقدِّمٍ بعينه، فقط ما لم تَكن على قائمة إبطال.

يَبدو التدفُّق كإضافة شبكة Wi-Fi. مرةً واحدة. يَخزن المُضيف التكوين؛ تَتخطى الجلسات اللاحقة الاكتشاف. ماذا يَعني «تَغيَّر شيءٌ» عملياً — قفزات إصدار، توسعات نطاق، نقلات قدرة — ينبغي أن يُطلق موافقةً مُجدَّدة، كما تَفعل تغيُّرات شهادة TLS. المُضيفات التي تَتخطى هذه الخطوة تَترك الخوادم تُوَسِّع مَدّها بصمتٍ مع الزمن، وهو بالضبط زحف القدرة البطيء الذي يَنتقص الثقة في أيِّ تكاملٍ طويل العمر.

5.3 الأجزاء المُمِلَّة التي تُقرِّر هل تَشحن

ثلاثة اهتماماتٍ تشغيلية تَستحقّ معالجتها الخاصة لأن كلاً منها مكانٌ يُنتج فيه التنفيذ المُهمل إما تكاملاتٍ مكسورة أو ثغراتٍ أمنية.

CORS يَهُمّ لأيِّ خادم MCP يُمكن بلوغه من مُضيفٍ قائمٍ على المتصفح. الإغراء أن تَضبط Access-Control-Allow-Origin: * وتَمضي. هذا خطأ. مع مصادقة الكوكي هي كارثة CSRF؛ مع رموز Bearer في localStorage هي مُجازفة تَسريب رمز. استخدم قائمة مَنشأ مسموحاً بها لكل مَنشأ، وفَضِّل ترويسات Authorization على الكوكيز فلا يكون نفس المَنشأ خط دفاعك الوحيد.

التحقُّق من المَنشأ هو CORS مُطَبَّق على جانب الخادم، لأن العملاء غير المتصفحين لا يَفرضون شيئاً. الفشل الكلاسيكي: يُجري مطوِّرٌ خادم MCP على localhost:8000، يَزور صفحة ويبٍ تَعرف الاتفاقية، تُطلق الصفحة طلباً، ويَفعل الخادم — دون فحص مَنشأ — ما طَلَبَته الصفحة. تَحقَّق من Origin على كل خادم HTTP قابلٍ للبث.

التخزين المؤقت هو الثالث. التوثيق الساكن يُمكن تخزينه مؤقتاً بقوة؛ صفُّ قاعدة بياناتٍ فقط طالما الاشتراكات موصولة؛ وثيقةٌ تُحَرَّر فعلياً ليس على الإطلاق. أعِد Cache-Control وETag الصحيحَين لكل مورد. التفاعل بين التخزين المؤقت والاشتراكات حيث يُلدغ المهندسون — وسيطٌ يَخدم نسخةً قديمة يَعني أن إشعار resources/updated للمُضيف لا يَنطلق أبداً، لأن آلية الاشتراك لا تَصل أبداً إلى الخادم الحي.

إعادة ربط DNS تُكَمِّل الجوار وتُؤَثِّر تفاوتياً على الخوادم المحلية. اربط بـ 127.0.0.1 لا 0.0.0.0، تَحقَّق من ترويسة Host مقابل قائمةٍ مسموحٍ بها، اطلب رمز مصادقةٍ حتى لـ localhost. خادم MCP محلي بدون هذه عرضٌ تجريبيٌّ واحدٌ بعيد عن أن يكون استشاريةً أمنية.

ما يُمهِّد له الفصل 5

يَختم هذا الجزء الثاني من الكتاب. لدينا البروتوكول في اليد: أوّليات الخادم في الفصل 3، أوّليات العميل في الفصل 4، السلك وطبقة الاكتشاف هنا. نَعرف أيُّ الرسائل تَنتقل، في أيِّ اتجاه، فوق أيِّ نقل، بين أيِّ نطاقات ثقة، بعد أيِّ مصافحة. يَنتقل الجزء الثالث من الأوّليات إلى الأنماط. خادمٌ واحدٌ متصلٌ بمُضيفٍ واحدٍ مفيد؛ والمكافأة المعمارية لـ MCP هي التركيب — خوادم متعددة، وكلاء متعددون، نماذج متعددة، تَتعاون نحو أهدافٍ أكبر.

التالي — الفصل 6: استراتيجيات التنسيق الأساسية. متى يَهزم وكيلٌ مُجهَّزٌ جيداً تصميماً متعدد الوكلاء، والشكلان الأساسيان — الأنابيب المتتابعة وتوازي الاندفاع-الجمع — اللذان يَعتمد عليهما مُعظم نشر الإنتاج.