ما هو بروتوكول MCP (Model Context Protocol)؟ دليل للمؤسسات

ما المشكلة التي يحلها بروتوكول MCP؟

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

يستبدل MCP ذلك ببروتوكول واحد. يُغلَّف النظام مرة واحدة كخادم MCP، فيستطيع أي تطبيق متوافق أن يكتشف ما يقدمه ويستخدمه. والخادم نفسه الذي يعمل مع مساعد على سطح المكتب يعمل أيضا مع بيئة تطوير أو منصة مساعدين للمؤسسات.

ولا يحل MCP محل واجهات البرمجة (API). فخادم MCP يقف عادة أمام واجهة قائمة ويحوّلها إلى صيغة يستطيع تطبيق الذكاء الاصطناعي اكتشافها واستدعاءها بأمان. ما يوحّده MCP هو الحوار بين جانب الذكاء الاصطناعي وجانب الأدوات.

من أطلق MCP ومن يديره اليوم؟

طوّر ديفيد سوريا بارا وجاستن سبار سمرز بروتوكول MCP في Anthropic، وأُطلق مفتوح المصدر في 25 نوفمبر 2024. وشمل الإطلاق المواصفة وحزم التطوير، ودعم خوادم MCP المحلية في تطبيقات Claude لسطح المكتب، ومستودعا مفتوح المصدر لخوادم مرجعية لأنظمة مثل Google Drive وSlack وGitHub وGit وPostgres.

وفي 9 ديسمبر 2025 تبرعت Anthropic بالبروتوكول لمؤسسة Agentic AI Foundation، وهي صندوق موجَّه تحت مظلة مؤسسة Linux شاركت في تأسيسه Anthropic وBlock وOpenAI، مع احتفاظ مشرفي المشروع بتوجيهه التقني. وبحلول ذلك الوقت أفاد مشرفو MCP بدعمه في ChatGPT وClaude وCursor وGemini وMicrosoft Copilot وVisual Studio Code وغيرها.

تُرقَّم إصدارات المواصفة بالتاريخ. والإصدار الحالي وقت كتابة هذا المقال هو 2026-07-28، وقد جعل البروتوكول عديم الحالة: كل طلب يحمل إصدار البروتوكول وقدراته بنفسه، ويستطيع العميل سؤال الخادم عمّا يدعمه عبر طلب اكتشاف.

كيف يعمل MCP؟ المضيف والعميل والخادم

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

تستخدم الرسائل صيغة JSON-RPC 2.0. تتواصل الخوادم المحلية عادة عبر stdio، إذ تُشغَّل كعملية فرعية على الجهاز نفسه. أما الخوادم البعيدة فتستخدم Streamable HTTP الذي يدعم أساليب المصادقة المعتادة مثل رموز الحامل ومفاتيح الواجهة، وتوصي وثائق MCP باستخدام OAuth للحصول على الرموز.

• الاكتشاف: يسأل العميلُ الخادمَ عن إصدارات البروتوكول والقدرات التي يدعمها.
• السرد: يستدعي العميل tools/list فيحصل على اسم كل أداة ووصفها ومخطط مدخلاتها بصيغة JSON Schema.
• الاختيار: يسلّم المضيف تعريفات الأدوات إلى النموذج اللغوي، فيقرر هل يحتاج أداة.
• الاستدعاء: يرسل العميل tools/call مع اسم الأداة ووسائطها، فينفذ الخادم الاستدعاء الفعلي للواجهة.
• الإرجاع: تعود النتيجة إلى النموذج سياقا لخطوته التالية أو لإجابته النهائية.

ما الفرق بين MCP والإضافات واستدعاء الدوال؟

استدعاء الدوال (Function calling) قدرة في جانب النموذج: يعيد النموذج طلبا منظما لاستدعاء دالة وصفتَها له. أما MCP فيقع في طبقة أبعد، إذ يوحّد طريقة نشر أوصاف الدوال واكتشافها وتنفيذها عبر حدود العمليات والشبكات، فتعمل الأداة نفسها مع أي مضيف متوافق.

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

هل بروتوكول MCP آمن؟ المخاطر التي يجب ضبطها

MCP بروتوكول لا نموذج أمني. هو يحدد كيف توصف الأدوات وتُستدعى، أما هل الاستدعاء مناسب فمسؤولية التطبيق المضيف. وتنص المواصفة على أنه ينبغي دائما وجود إنسان في الحلقة قادر على رفض استدعاء الأدوات، وعلى أن العميل يجب أن يعامل الأوصاف الإضافية للأدوات، كادعاء أن أداة للقراءة فقط، على أنها غير موثوقة ما لم تأتِ من خادم موثوق.

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

• الموافقة على الأدوات: اشترط موافقة بشرية على كل أداة تكتب أو تحذف أو ترسل خارج المؤسسة، ولا تثق بوصف الخادم لمدى خطورة أدواته.
• حماية بيانات الاعتماد: خزّن رموز الخادم ومفاتيحه مشفرة، واحصرها في مستأجر أو فريق واحد، وفضّل OAuth حين يدعمه الخادم، ولا تضع الأسرار في التعليمات أبدا.
• أقل صلاحية ممكنة: أعطِ الخادم حساب خدمة مخصصا بالصلاحيات التي تحتاجها أدواته فقط.
• حقن التعليمات: قد تحمل أوصاف الأدوات ونتائجها أوامر موجهة إلى النموذج، فعاملها على أنها بيانات.
• سلسلة التوريد: تحقق ممن يطوّر الخادم وكيف يُحدَّث وما الذي يستطيع الوصول إليه قبل تثبيته.
• التدقيق: سجّل كل استدعاء أداة ووسائطه وقرار الموافقة ونتيجته.

كيف تستخدم Botify بروتوكول MCP؟

تستطيع بوتيفاي تسجيل أي خادم MCP لكل مستأجر عبر عنوان HTTP الخاص به. وإن احتاج الخادم مفتاح واجهة، يُختم المفتاح في خزنة بيانات الاعتماد بتشفير AES-256-GCM ولا تعيده الواجهة البرمجية أبدا. وتُخصَّص أسماء أدوات كل خادم مسجَّل لذلك التسجيل وحده، فلا تتصادم خوادم مستأجرين مختلفين.

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

هل يمكن ربط نظام ERP مثل Odoo بمساعد عبر MCP؟

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

تتصل Botify بـ Odoo مباشرة، فلا يحتاج Odoo نفسه إلى خادم MCP من طرف ثالث، وتخضع إجراءاته للسياسات والموافقات وسجل التدقيق نفسها التي تحكم كل نظام آخر. أما أنظمة ERP الأخرى فيمكن الوصول إليها عبر MCP بتسجيل خادمها في Botify كما سبق. وتتصل Botify بخوادم MCP عبر HTTP، لذا يجب استضافة الخادم الذي لا يدعم إلا stdio خلف نقطة HTTP أولا.

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