بروتوكول MCP لصاحب المشروع: عبدالله سنكر يشرح وش تكسب منه فعلاً

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

المشكلة قبل البروتوكول

تخيّل عندك خمس أدوات عمل، وتبي تستخدم ثلاثة مساعدين ذكاء اصطناعي مختلفين. بالطريقة القديمة كل مساعد يحتاج ربط خاص بكل أداة: يعني خمسة عشر ربطاً، كل واحد له كوده وصيانته وأخطاؤه. وإذا تغيّر شي في أداة وحدة، تصلح الربط في كل مكان.

MCP اختصار Model Context Protocol، بروتوكول مفتوح طرحته Anthropic عشان يوحّد هالشي. الفكرة نفس فكرة منفذ USB: بدل ما كل جهاز له شاحن خاص، صار فيه منفذ واحد متفق عليه. تبني «خادم MCP» واحد لأداتك، وأي تطبيق ذكاء اصطناعي يدعم البروتوكول يقدر يتصل فيه.

وش يقدّم خادم MCP بالضبط؟

الخادم هو الوسيط بين نظامك والنموذج. يعرض ثلاثة أنواع من الأشياء:

• أدوات (Tools): أفعال يقدر النموذج يطلب تنفيذها، مثل «ابحث عن طلب برقمه» أو «أنشئ فاتورة».
• موارد (Resources): بيانات للقراءة، مثل قائمة الأسعار أو سياسة الاسترجاع.
• قوالب أوامر (Prompts): صيغ جاهزة يجهّزها صاحب الخادم عشان المستخدم يشغّلها بضغطة.

والمهم هنا: النموذج ما يدخل قاعدة بياناتك مباشرة. هو يطلب، والخادم يقرر وش ينفّذ ووش يرفض. يعني أنت اللي تحدد حدود اللعب.

وش تكسب أنت كصاحب مشروع؟

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

متى ما تحتاج MCP؟

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

MCP يبرز لما يكون عندك أكثر من أداة، وأكثر من مستخدم أو مساعد، وتبي النموذج نفسه يختار متى يستخدم أي أداة حسب السؤال. هنا التوحيد يوفّر عليك فعلاً.

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

ولاحظ إن الأدوات مسماة بلغة الشغل، مو بلغة قاعدة البيانات. هذا مقصود: كل ما كانت الأداة أوضح، كل ما استخدمها النموذج صح، وكل ما سهل عليك تراجع وش سوّى.

الجانب اللي لازم تنتبه له

البروتوكول يسهّل الاتصال، بس ما يضمن الأمان لحاله. خادم MCP من مصدر مجهول ممكن يطلب صلاحيات أكثر من اللازم، وأداة كتابة مفتوحة بلا تأكيد ممكن تنفّذ شي ما تبيه. عشان كذا القاعدة: كل أداة تعطيها للنموذج، اسأل نفسك وش أسوأ شي ممكن يصير لو استُخدمت غلط.

هذا الموضوع بالذات درسه عبدالله عبدالرحيم بن سنكر الكندي في دورة Model Context Protocol: Advanced Topics من Anthropic، وأغلب الدروس العملية فيها تدور حول هالنقطة: تصميم الأدوات بحيث تكون ضيقة وواضحة، والتحقق من كل طلب قبل تنفيذه.

أسئلة تسألها المطوّر قبل ما توافق

• وش الأدوات اللي بيعرضها الخادم بالضبط؟ وأي منها يكتب أو يحذف؟
• هل الخادم يشتغل محلياً على جهاز واحد، أو عبر الإنترنت؟ وكيف يتم التحقق من هوية اللي يتصل فيه؟
• وين تنحفظ مفاتيح الوصول لأنظمتي؟ وهل تظهر للنموذج؟
• هل فيه سجل لكل أداة انطلبت ومين طلبها؟
• لو بغيت أوقف أداة معيّنة بكرة، كم تاخذ وقت؟

إذا جاوبك المطوّر على هالأسئلة بوضوح، فأنت في يد أمينة. وإذا تلعثم، فالمشكلة مو في البروتوكول.

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