ما هو بروتوكول MCP وكيف سيغير طريقة عمل الذكاء الاصطناعي؟

سنبدأ مباشرة في هذا المقال، لأن الموضوع يثير ضجة كبيرة والجميع يتحدث عنه. بروتوكول MCP (Model-Context-Protocol) هو، باختصار شديد، بروتوكول أو طريقة للتواصل بين نماذج اللغة الكبيرة (LLMs) والخدمات الأخرى. لفهم هذا المفهوم، دعنا نرجع قليلًا إلى الوراء ونتحدث عن بدايات نماذج اللغة الكبيرة والذكاء الاصطناعي.

بدايات نماذج اللغة الكبيرة (LLMs) والقيود الأولى

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

ظهور الأدوات (Tools) وتطور نماذج اللغة

جاء المطورون وقرروا أن هذا الوضع غير مقبول، وأرادوا إضافة “أدوات” (Tools) وربطها بنماذج اللغة الكبيرة لجعلها أكثر ذكاءً وقدرة على تنفيذ مهام محددة. فكرة الأدوات في نماذج اللغة تشبه تمامًا واجهة برمجة التطبيقات (API).

مثال توضيحي: ربط Figma بمشروعك

لنفترض أنك تعمل كمطور واجهة أمامية (Frontend) ولديك تصميم على Figma وتريد ربط رموز التصميم (Design Tokens) بمشروعك. باستخدام الأدوات، يمكنك الآن ربط نموذج اللغة بأداة معينة. هذه الأداة ستخبر النموذج بالاتصال بـ Figma، وتصدير رموز التصميم، ثم إدراجها في مشروعك في مسار محدد، وتثبيت حزمة معينة لترجمة هذه الرموز وتحويلها إلى CSS أو Sass. هذه هي فكرة الأدوات.

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

المشكلة التي ظهرت مع تعدد التطبيقات

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

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

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

الحل: بروتوكول MCP

هنا ظهر بروتوكول MCP ليقول: “هذا الوضع لا يمكن أن يستمر”. تم تقديمه كبروتوكول قياسي يربط بين نماذج اللغة الكبيرة ومزودي الخدمات. نحن كمبرمجين، نفضل الأشياء القياسية التي يتفق عليها الجميع ولها إرشادات وتوثيق واضح، تمامًا مثل REST API.

مقارنة مع REST API

عندما تتواصل مع خرائط جوجل (Google Maps)، هل تصل إلى قاعدة بياناتهم مباشرة؟ بالطبع لا. مزود الخدمة مثل جوجل يوفر لك نقطة نهاية (Endpoint) بدوال قياسية (GET, POST, PUT, DELETE). إذا أردت البحث عن أماكن، فأنت تتصل بنقطة النهاية باستخدام الدالة المحددة. المنطق البرمجي الداخلي، الاتصال بقاعدة البيانات، كل هذا لا علاقة لك به. جوجل هي من تقوم بالصيانة والتطوير.

هنا يأتي دور MCP. تمامًا كما أنك لا تشغل بالك بالمنطق الداخلي لـ REST API، مع MCP لن تشغل بالك بالمنطق البرمجي لربط الخدمات.

مقارنة مع بروتوكول SMTP

فكر في الأمر مثل بروتوكول SMTP لإرسال البريد الإلكتروني. لديك خياران:

1. الطريق الصعب: بناء خادم بريد إلكتروني من الصفر، وتثبيت نظام تشغيل، وقاعدة بيانات، وبرامج مثل Sendmail، والتعامل مع الإعدادات والأمان والتوسع.
2. الطريق السهل: استخدام مزود خدمة بريد إلكتروني عبر SMTP. كل ما تحتاجه هو إعدادات بسيطة (اسم المضيف، المنفذ، اسم المستخدم، وكلمة المرور)، والمزود يتكفل بكل شيء آخر.

MCP يتبع نفس الفكرة. سيكون هناك خوادم (Servers) ومزودو خدمات يقدمون الخدمات التي تحتاجها، وبدلًا من استخدام SMTP أو REST، ستستخدم بروتوكول MCP للاتصال بها عبر إعدادات بسيطة.

كيف يعمل بروتوكول MCP؟

مع MCP، أصبح مسار العمل أبسط. لنفترض أن لديك عدة تطبيقات:

• التطبيق الأول: يحتاج إلى خرائط جوجل، وسلاك، والتعامل مع نظام الملفات.

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

مثال: خادم MCP لخرائط جوجل

هذا مثال لخادم MCP رسمي من جوجل. الأدوات المتاحة فيه تشمل:

• GeocodeTool
• ReverseGeocodeTool
• SearchPlacesTool
• PlaceDetailsTool

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

تفصيل مصطلح MCP

MCP هو اختصار لـ Model-Context-Protocol:

• Model (نموذج): يشير إلى نموذج الذكاء الاصطناعي، سواء كان نموذج صور، أو تحويل نص إلى كلام، أو غيره.
• Context (سياق): هو جوهر أي نموذج لغة كبير، وينقسم إلى عدة أنواع:
  • Tools (أدوات): هي الإجراءات التي يمكن تنفيذها، مثل الاتصال بقاعدة بيانات، أو إنشاء ملف، أو حذفه. عندما تتصل بخادم MCP، يمكنك أن تطلب منه قائمة بجميع الأدوات المتاحة.
  • Resources (موارد): هي المرفقات مثل الملفات (PDF) أو قواعد البيانات.
  • Sampling (أخذ العينات): هي الطريقة التي يستعلم بها النموذج من النماذج الأخرى.
  • Prompts (التوجيهات): هي الأوامر التي تكتبها في واجهة العميل.
• Protocol (بروتوكول): هو ما يربط العميل بالخادم.

مكونات النظام البيئي لبروتوكول MCP

وفقًا للتوثيق الرسمي، يتكون النظام البيئي لـ MCP من:

• Host (المضيف): هو تطبيق نموذج اللغة أو الواجهة التي تتفاعل معها (مثل Claude Desktop, ChatGPT, Cursor IDE).
• MCP Client (عميل MCP): هو ما يدير الاتصال بين الخوادم داخل المضيف.
• MCP Server (خادم MCP): هو الذي يحتوي على المنطق البرمجي، والأدوات، والموارد (مثل خادم خرائط جوجل).
• Protocol (البروتوكول): هو ما يدير الاتصال بين العميل والخادم. من مميزاته أنه يدعم طلبات الانعكاس (Reflection Requests)، التي تسمح لعميل MCP بطلب معلومات من خادم MCP، مثل قائمة الأدوات والموارد المتاحة.

لماذا لا نستخدم GraphQL؟

قد يتساءل البعض، لماذا لا نستخدم GraphQL؟ من منظور نماذج اللغة، هي تدعم الأدوات والموارد، بينما GraphQL يدعم الكيانات (Entities) والحقول (Fields). لجعله يعمل، سنحتاج إلى إضافة طبقة إضافية فوق GraphQL لتمكينه من طلب الأدوات والموارد.

الوضع الحالي لـ MCP

يوفر الموقع الرسمي لـ MCP العديد من حزم تطوير البرمجيات (SDKs) للغات مثل Python وJavaScript وC#.

عملاء MCP المتاحون حاليًا:

• Claude Desktop
• Claude Code
• Cursor
• Zed

خوادم MCP المتاحة:

• File System: للتعامل مع الملفات والمجلدات.
• Postgres, SQLite: للاتصال بقواعد البيانات.
• Google Drive: للتعامل مع ملفات جوجل درايف.
• وغيرها الكثير…

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

مثال عملي من السوق: إذا كنت تريد بناء وكيل ذكاء اصطناعي يقوم بالبحث في الويب، يمكنك البحث في السوق عن خادم Brave Search. ستجد خادم MCP جاهزًا، كل ما عليك هو إنشاء حساب في Brave، والحصول على مفتاح API، ووضعه في الإعدادات للاتصال.

{
  "name": "brave-search",
  "displayName": "Brave Search",
  "description": "Search the web with the Brave Search API.",
  "author": "Brave",
  "icon": "https://brave.com/static-assets/images/brave-logo-sans-text.svg",
  "mcp_version": "0.1.0",
  "tools": [
    "search",
    "search_local"
  ]
}

الخلاصة

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

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