MCP: ليس حلاً سحرياً، لكنه جيد

الكشف عن MCP: بروتوكول موحد لاستدعاء الأدوات

تعريف MCP

MCP هو بروتوكول تقني مفتوح مصمم لتوحيد الطريقة التي تتفاعل بها نماذج اللغة الكبيرة (LLMs) مع الأدوات والخدمات الخارجية. فكر في الأمر كمترجم عالمي داخل عالم الذكاء الاصطناعي، مما يمكّن نماذج الذكاء الاصطناعي من ‘التحدث’ مع مجموعة واسعة من الأدوات الخارجية. يوفر لغة وهيكلًا مشتركين لنماذج LLM لطلب واستخدام الوظائف التي تقدمها التطبيقات والخدمات المختلفة.

الحاجة إلى MCP

قبل ظهور MCP، كان استدعاء أدوات الذكاء الاصطناعي يعاني من تحديين رئيسيين:

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

يعالج MCP نقاط الألم هذه من خلال توفير إطار عمل موحد لنماذج LLM للتفاعل مع الأدوات الخارجية، وتبسيط عملية التطوير وتمكين قدر أكبر من قابلية التوسع.

فهم وظائف MCP

يمكن تصور البنية التقنية لـ MCP كنظام يتكون من ثلاثة مكونات أساسية: MCP Host و MCP Client و MCP Server. تعمل هذه العناصر بشكل تآزري لتسهيل الاتصال السلس بين نماذج الذكاء الاصطناعي والعالم الخارجي.

لفهم دور MCP، ضع في اعتبارك بيئة مؤسسة حديثة. في هذا القياس:

• يمثل المستخدمون كبار المديرين التنفيذيين، المسؤولين عن فهم احتياجات المستخدمين واتخاذ القرارات النهائية.
• نماذج اللغة الكبيرة (LLMs) (مثل Claude أو GPT) تفهم تعليمات المديرين التنفيذيين، وتخطط خطوات المهام، وتحدد متى تستخدم الخدمات الخارجية، وتدمج المعلومات لتقديم الإجابات.
• تعمل أنظمة الوكيل كمساعدين شخصيين أو سكرتارية تنفيذية، وتقوم بتنفيذ المهام حسب التعليمات.
• يعمل MCP كمنصة اتصالات موحدة أو نظام وصول إلى خدمات المؤسسة يستخدمه السكرتارية. لا يتخذ قرارات ولكنه يتبع التعليمات بدلاً من ذلك، ويتواصل مع مختلف مزودي الخدمة بتنسيق وبروتوكول موحدين.

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

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

MCP: مجموعة أدوات مبنية على استدعاء الدالة

من الضروري أن نفهم أن MCP ليس بديلاً عن استدعاء الدالة التقليدي؛ بل هو مكون تكميلي يعزز قدراته.

استدعاء الدالة هو الآلية الأساسية التي تتفاعل بها نماذج LLM مع الأدوات أو واجهات برمجة التطبيقات الخارجية. إنها قدرة أساسية لنماذج LLM، وتمكنها من تحديد متى تكون الأداة مطلوبة ونوع الأداة المطلوبة.

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

تتضمن عملية استدعاء الأداة الكاملة مجموعة من ‘استدعاء الدالة + الوكيل + نظام MCP’.

جوهر الأمر هو أن LLM يعبر عن الحاجة إلى استدعاء أداة معينة من خلال استدعاء الدالة. يتبع الوكيل التعليمات لتنفيذ استدعاء الأداة، بينما يوفر MCP مواصفات موحدة لاستدعاء الأداة.

ضع في اعتبارك القياس التالي: رئيس (مستخدم) يريد القهوة. في المكتب (MCP Host)، يوجه مدير المكتب (LLM) السكرتير (الوكيل) لشراء أمريكانو (استدعاء الدالة). يتحقق السكرتير من قائمة الموردين ويجد أن مورد قهوة أمريكانو قد اندمج مع Meituan أو نظام الشراء الموحد للشركة (تم تنفيذ MCP Server). ثم يحدد السكرتير موقع المورد في نظام الشراء (MCP Client) ويقدم طلبًا.

في السابق، بدون MCP، عندما يصدر LLM استدعاء دالة، يترجم الوكيل ويتصل مباشرة بواجهة برمجة التطبيقات لاستدعاء الأداة. تتطلب كل واجهة برمجة تطبيقات وضع استدعاء منفصلاً وقائمة أدوات محددة ووضع استدعاء للوكيل لتفسيره. باستخدام MCP، يمكن طلب العديد من واجهات برمجة التطبيقات مباشرة من خلال MCP Client الخاص بالمورد، مما يوفر وقت وجهد الوكيل. ومع ذلك، يظل استدعاء الدالة لـ LLM دون تغيير، ولا يزال بالتنسيق {tool: ‘buy coffee’, ‘type’: ‘Americano’}.

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

تحديات تطوير MCP والمشهد السوقي

معضلة التطوير

منذ فبراير، شهد مجتمع تطوير الذكاء الاصطناعي ‘اندفاعًا ذهبيًا لـ MCP’. في غياب متجر تطبيقات رسمي، اندمجت آلاف الأدوات طواعية مع بروتوكول MCP في غضون ثلاثة أشهر.

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

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

تم الترحيب بظهور MCP في البداية من قبل تطبيقات العميل المحلية، لكن تطبيقات العميل السحابي ومطوري خادم MCP واجهوا تحديات.

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

بالنسبة لمستخدمي العميل المحليين، يمثل MCP ثورة، حيث يقدم صندوق أدوات قابل للتوسيع بلا حدود يسمح للمستخدمين بتوسيع قدرات مساعدي الذكاء الاصطناعي الخاصين بهم باستمرار.

استفادت تطبيقات العميل المحلية مثل Cursor و Claude Desktop من MCP لتمكين المستخدمين من إضافة أدوات ديناميكيًا بناءً على الاحتياجات الفردية، وتحقيق توسع غير محدود في قدرات مساعد الذكاء الاصطناعي.

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

ومع ذلك، تتضاءل جاذبية MCP عند التفكير في تطوير جانب الخادم (MCP Server) وعملاء السحابة. استخدمت الإصدارات المبكرة من MCP آلية وصلة مزدوجة للخوادم السحابية (عن بُعد)، باستخدام اتصال SSE طويل لدفع الرسائل أحادي الاتجاه من الخادم إلى العميل واتصال HTTP قصير لإرسال الرسائل.

عمل هذا النهج بشكل جيد لتقديم ملاحظات المستخدمين وتدخلهم في الوقت المناسب ولكنه خلق سلسلة من التحديات الهندسية في بيئات جانب الخادم.

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

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

ثانيًا، MCP لديه قيود في مجال التطبيقات السحابية. تعمل وكلاء الذكاء الاصطناعي السحابيون (وكلاء جانب الخادم) عادةً في خدمات عديمة الحالة، وتعالج المهام بعد القبول وتحرر الموارد عند الانتهاء. يتطلب استخدام MCP Client على جانب الخادم إنشاء ارتباط SSE مؤقتًا، وإرسال طلب استدعاء أداة، وتلقي النتيجة من SSE، ثم إغلاق ارتباط SSE، وهو نهج غير فعال يزيد من التعقيد ويقلل من الأداء. يجب أن يكون طلب RPC واحد كافيًا في هذا السيناريو.

من الناحية العملية، غالبًا ما تعتمد التطبيقات السحابية التي تستخدم MCP على مجموعات الأدوات المعدة مسبقًا ولا تستخدم قدرة توقيع MCP الخاصة بالاكتشاف الديناميكي للأداة والتحميل المرن.

يحد وضع تفاعل البيانات للبيئات السحابية من القدرة على استخدام الأدوات بحرية كما هو مقصود من MCP. فهو يستلزم عملية موحدة للغاية لاستدعاء أدوات محددة ومشفرة، مما يضحي بالمرونة.

أظهر فريق MCP استجابة لتعليقات المستخدمين. بعد تلقي تعليقات من مطوري جانب الخادم، قام MCP بتحديث البروتوكول الخاص به في 26 مارس، واستبدل نقل SSE الأصلي بنقل HTTP قابل للتدفق. يدعم البروتوكول الجديد كلاً من سيناريوهات الخدمة عديمة الحالة التي تتطلب طلبات استدعاء أداة واحدة فقط ومتطلبات الدفع في الوقت الفعلي التي تم تلبيتها سابقًا من خلال روابط HTTP + SSE المزدوجة.

تشير هذه التحسينات إلى أن مشكلات MCP الحالية تنبع من قيود التصميم الأولية ولكنها ليست مستعصية على الحل.

اضطراب السوق

التحدي الآخر الذي يواجه MCP هو انخفاض قابلية استخدام العديد من التطبيقات في السوق.

يشهد سوق MCP الحالي دورة ضجيج تكنولوجي نموذجية. على غرار فوضى متجر التطبيقات المبكر، أقل من 20٪ من آلاف أدوات MCP المتاحة حاليًا لها قيمة عملية. تعاني العديد من التطبيقات من مشكلات خطيرة، تتراوح من أخطاء التكوين البسيطة إلى عدم قابلية الاستخدام الكامل. يتم التسرع في طرح بعضها في السوق دون اختبار كافٍ، بينما البعض الآخر عبارة عن منتجات تجريبية لم تكن مخصصة للاستخدام العملي أبدًا.

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

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

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

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

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

تتمتع محرروا التعليمات البرمجية مثل Cursor بوظائف تطوير مضمنة، مما يجعل معظم أدوات MCP الخارجية زائدة عن الحاجة.

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

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

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

MCP جيد، وليس حلاً سحرياً

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

تصف إحدى الانتقادات الأخيرة MCP بأنه بروتوكول معيب لأنه لا يملي أنماط التفاعل بين LLMs و MCP.

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

تنشأ المشكلة من عدم التطابق المعرفي - توقع بروتوكول اتصال لأداء مهام نظام ذكي. هذا يشبه إلقاء اللوم على USB لعدم تحرير الصور أو إلقاء اللوم على معايير 5G لعدم كتابة التعليمات البرمجية. MCP هو في الأساس ‘مقبس أداة’ موحد، مما يضمن توافق المكونات الإضافية بدلاً من إملاء الجهاز الذي سيتم استخدامه أو كيف.

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

غالبًا ما نسعى إلى حلول سحرية في التكنولوجيا، وحلول قابلة للتطبيق عالميًا. مثل مسلمة ‘لا يوجد حل سحري’ في هندسة البرمجيات، لا يوجد حل سحري لاستخدام أدوات الذكاء الاصطناعي. يحتاج نظام الذكاء الاصطناعي القوي إلى مكونات مصممة: LLMs للفهم والجيل، وأطر الوكيل للتخطيط والتنفيذ، و MCP التي تركز على واجهات الأدوات الموحدة.

يظهر MCP تصميم بروتوكول جيد - يركز على مشكلة واحدة ويحلها جيدًا، بدلاً من كل شيء. يساعده ضبط النفس على التقدم في تكامل الأدوات من جانب العميل.

كيانات مثل Qwen التابعة لـ Alibaba، و ‘Xinxiang’ التابعة لـ Baidu، و Kouzi Space التابعة لـ ByteDance تتبنى بروتوكول MCP، في محاولة لإنشاء أنظمة MCP بيئية داخلية أكثر كفاءة.

ومع ذلك، هناك اختلافات رئيسية في النشر: Baidu و ByteDance أكثر عدوانية. تحاول Baidu اتباع نهج C-end، ودمج العديد من نماذج الذكاء الاصطناعي والأدوات الخارجية من خلال ‘Xinxiang’ (Kokone) باستخدام بروتوكول MCP، في المقام الأول للأجهزة المحمولة، للاندماج في الحياة اليومية للمستخدم وتشجيع التبني.

يحتوي Kouzi Space التابع لـ ByteDance على أكثر من 60 مكونًا إضافيًا لـ MCP. يمكن الوصول إليه عبر صفحة ويب، كما أطلق IDE أصليًا للذكاء الاصطناعي، Trae، والذي يدعم MCP، ويستهدف في المقام الأول سيناريوهات الإنتاجية.

قامت Alibaba بدمج بروتوكول MCP في منتجات مثل Alipay، مما يتيح استدعاء أداة الذكاء الاصطناعي بنقرة واحدة، وفتحت المصدر لنموذج Qwen3، الذي يدعم بروتوكول MCP، مما يعزز قدرات الوكيل الخاص به.

أصدر مطورو Tencent Cloud مجموعة تطوير الذكاء الاصطناعي التي تدعم خدمات استضافة المكونات الإضافية لـ MCP. يتيح محرك المعرفة النموذجي الكبير في Tencent Cloud للمستخدمين استدعاء المكونات الإضافية لـ MCP. يتوافق وكيل البرامج الذكي لتطوير البرامج Craft الذي أطلقته CodeBuddy التابعة لـ Tencent Cloud مع نظام MCP البيئي المفتوح. بالإضافة إلى ذلك، أصدرت Tencent Maps و Tencent Cloud Storage MCP SERVER الخاص بهما.

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

في هذا النموذج، قد يصبح MCP ببساطة جزءًا من البنية التحتية الأساسية، بدلاً من واجهة تواجه المستخدم أو المطور. قد تتطلب خطة أكثر اكتمالًا هياكل مثل Agent to Agents (A2A) لتعزيز تخطيط المهام وكفاءة اختيار الأدوات من خلال زيادة مستويات التجريد.

من خلال إعادة MCP إلى دوره ‘البروتوكولي’، يمكننا التعرف على قوته الحقيقية لدفع التوحيد القياسي للصناعة - قد تكون هذه اللحظة الأكثر قيمة ‘لإزالة الغموض’ في تطور التكنولوجيا.