شرح MCP: كيف يعمل Model Context Protocol

تمكنت نماذج اللغة الكبيرة LLMs من استدعاء الأدوات منذ مدة، لكن Model Context Protocol (MCP) يوفر طريقة منظمة وموحدة للقيام بذلك.

ومع ذلك، لا يزال هناك التباس حول ماهية MCP فعلا.

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

لنوضّح ذلك.

إذا كنت تريد فقط أن ترى ما الذي يتيحه MCP عمليا، شاهد هذا الفيديو القصير:

ما هو البروتوكول؟

البروتوكول هو ببساطة مجموعة قواعد تحدد كيف يتواصل نظامان أو أكثر مع بعضهما.

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

تقوم الأنظمة البريدية بشيء مشابه. تتبع كل مكاتب البريد في أي بلد معين صيغة موحدة للعناوين لإرسال الرسائل.

أو يمكن التفكير فيه مثل USB-C لأدوات الذكاء الاصطناعي. قبل عشرين عاما، كان السوق مليئا بأنواع مختلفة من كابلات الشحن والبيانات. وهذا يشبه أنظمة الذكاء الاصطناعي التي كان لديها عدة طرق لتمرير الأدوات إلى نماذج اللغة. فقد عرّفت أطر عمل مثل LangChain وHaystack وPydantic AI صيغها الخاصة لدمج الأدوات، ما يعني أنه إذا أراد مطور كتابة مجموعة أدوات لـ Google Maps، فعليه فعل ذلك لكل تقنية محددة على حدة.

لجعل ذلك أوضح، لننظر إلى البروتوكول الأكثر شيوعا، HTTP (Hypertext Transfer Protocol)، الذي يشغّل مواقع الويب. يحدد HTTP، من بين أمور أخرى، كيف يطلب المتصفح (العميل) صفحة ويب من خادم ويب وكيف ينبغي للخادم أن يرد.

إليك مثالا على دورة طلب واستجابة HTTP:

1. يرسل المتصفح طلب HTTP

عندما تكتب https://example.com في متصفحك، يرسل المتصفح طلب HTTP منظما إلى خادم الويب:

فيما يلي معاملات HTTP والقيم المستخدمة في مثالنا:

"GET" – هذا هو الإجراء (طلب صفحة ويب).
"/index.html" – صفحة الويب المحددة المطلوب طلبها.
"HTTP/1.1" – إصدار البروتوكول المستخدم.
"Host: example.com" – اسم نطاق الموقع الإلكتروني.
"User-Agent: Mozilla/5.0" – معلومات عن المتصفح الذي يرسل الطلب.

يعرف خادم الويب كيف يفسر هذا الطلب لأن HTTP يوحّد هذه الصيغة. إنه يفهم هذه “اللغة”.

2. يرد الخادم باستخدام بروتوكول HTTP

يعالج الخادم الطلب ويرسل استجابة HTTP منظمة:

"HTTP/1.1 200 OK" – رمز الاستجابة (200 يعني النجاح).
"Content-Type: text/html" – نوع المحتوى الذي يتم إرساله.
"Content-Length: 512" – حجم الاستجابة.
HTML Content – محتوى صفحة الويب الفعلي (لا يوجد سوى عنوان "مرحبا بك في Example.com")

مهم: لا يقوم HTTP نفسه بـ تخزين صفحات الويب أو عرضها. إنه يحدد فقط القواعد التي يُسمح لمتصفحات الويب وخوادم الويب بالتواصل وفقها. يمكن لأي نظام يتبع هذه القواعد أن يتواصل عبر الإنترنت المعرّف بواسطة HTTP.

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

الآن، لنطبق طريقة التفكير نفسها على MCP (Model Context Protocol).

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

ما هذه “الأدوات”، قد تسأل؟

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

لنفترض أنك تسأل وكيل ذكاء اصطناعي:

“كم الساعة الآن في لندن؟”

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

إليك ما يحدث:

1. يرسل وكيل الذكاء الاصطناعي طلب MCP إلى خدمة الوقت (مثال)

"method": "tools.call" → يستدعي الذكاء الاصطناعي أداة خارجية.
"tool": "get_time" → اسم الأداة التي يريد استخدامها.
"args": { "location": "London" } → معاملات الإدخال المحددة.

كما في HTTP، يتبع هذا الطلب صيغة صارمة بحيث تعرف أي أداة متوافقة مع MCP بالضبط كيف تفسره.

2. يرد خادم الوقت الخاص بـ MCP

تتبع الأداة الخارجية (خادم الوقت) قواعد الاستجابة في MCP وترسل:

"status": "success" → يؤكد أن الطلب عولج بشكل صحيح.
"result" → يحتوي على بيانات الوقت الفعلية.

الآن يستطيع وكيل الذكاء الاصطناعي أخذ هذه البيانات وصياغة رد فعلي للمستخدم على النحو التالي:

“الوقت الحالي في لندن هو 12:20 مساء (GMT).”

للتلخيص وإزالة الالتباس:

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

“MCP قاعدة بيانات.” → لا، MCP لا يخزن البيانات. إنه يساعد وكلاء الذكاء الاصطناعي على التحدث إلى قواعد البيانات أو APIs.

“MCP مثل API.” → ليس تماما. API هو طريقة محددة للتفاعل مع نظام واحد، بينما يحدد البروتوكول (مثل MCP أو HTTP) طريقة عامة تستطيع أنظمة مختلفة كثيرة التواصل بها. MCP لغة يمكن لنظام ذكاء اصطناعي استخدامها للتفاعل مع APIs فعلية كثيرة (الوقت، قواعد البيانات، Stripe، Slack، إلخ).

لماذا MCP مثير للاهتمام

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

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

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

مع MCP، بمجرد أن يكون إطار العمل قائما، قد تصبح إضافة تكامل جديد (مثل دمج Google Drive) مجرد اتصال بخادم Google Drive MCP ببضعة أسطر من الشيفرة. لن تواجه مشكلات توافق لأنكما تستخدمان البروتوكول نفسه: MCP.

لنقارن النهجين لرؤية الفروق بوضوح أكبر.

التكامل القياسي مقابل استخدام Model Context Protocol (MCP)

لجعل هذه المقارنة ملموسة، لنستعرض إضافة وصول إلى ملفات Google Drive إلى AI Agent، أولا يدويا ثم باستخدام أداة متوافقة مع MCP.

التكامل القياسي

1. ابحث عن مكتبة وعدّلها: تبحث عن عميل Google Drive API أو مشروع مفتوح المصدر. توفر Google مكتبات عملاء (مثل Google Drive API for Python)، وتضيفها إلى مشروعك. لا يزال عليك التأكد من أنها تعمل مع بيئة الذكاء الاصطناعي لديك.

2. نفّذ المنطق: تكتب دوال، مثلا، للبحث عن الملفات أو جلب مستند من Drive. عندما يحتاج الذكاء الاصطناعي إلى شيء، يجب أن يستدعي هذه الدوال. تقوم بتنسيق طلب الذكاء الاصطناعي إلى استدعاءات API الخاصة بـ Google Drive. بعد الحصول على استجابة من Google، تستخرج المحتوى لتمريره مرة أخرى إلى سياق الذكاء الاصطناعي.

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

4. الصيانة: بمرور الوقت، إذا حدّثت Google واجهة API أو المكتبة، يجب عليك تحديث الشيفرة. إذا وجدت خطأ في المكتبة، قد تضطر إلى تصحيحه أو البحث عن مصدر آخر. تصبح عمليا المسؤول عن صيانة تكامل Google Drive هذا داخل تطبيق الذكاء الاصطناعي لديك.

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

تكامل MCP

لنر الآن كيف ستبدو هذه العملية عند استخدام MCP.

أولا، لنعرّف المفاهيم الأساسية:

Client – تطبيق ذكاء اصطناعي (ChatGPT، تطبيق Claude، Quickchat AI) ينشئ اتصالا بخادم واحد أو أكثر ويطلب معلومات أو إجراءات لتنفيذ مهام يطلبها المستخدم.

Server – قد يتصل كل خادم بشيء مثل قاعدة بيانات أو API (Google Drive) ويعرّف مجموعة من “الأدوات” أو البيانات التي يستطيع توفيرها. في هذه الحالة، الخادم هو برنامج يعرّض هذه الأدوات والقدرات إلى Client (تطبيق الذكاء الاصطناعي).

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

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

  عند تهيئة الخادم، تمنحه وصولا إلى النظام الهدف (Google Drive). ثم يعرّض الخادم مجموعة أدوات تقابل الإجراءات أو الاستعلامات التي يستطيع التعامل معها. إنه في الأساس محوّل API يتحدث MCP من جهة، ويتحدث خدمة النظام الأصلية من الجهة الأخرى.

  بمجرد تشغيل الخادم، ينتظر الطلبات.

• توصيل LLM (عميل) بخادم MCP. بعد ذلك، يحتاج تطبيق الذكاء الاصطناعي (جانب “العميل”) إلى الاتصال بذلك الخادم. عمليا، إذا كنت تستخدم منصة ذكاء اصطناعي تدعم MCP (مثل Claude Desktop)، فستضبطها بعنوان الخادم أو الأمر اللازم لتشغيله. بمجرد الاتصال، ينشئ العميل جلسة مع الخادم وفق مصافحة MCP. إذا كنت تستخدم واجهة Claude، فسترى أن Claude “متصل” بخوادم MCP معينة (قد تشير واجهة المستخدم إلى الموصلات المتاحة).

هذا ما يبدو عليه الأمر في واجهة Claude UI

• اكتشاف الأدوات المتاحة. بعد إنشاء الاتصال، أول ما ينبغي فعله هو معرفة ما يقدمه الخادم (أحيانا يحدث ذلك تلقائيا بعد الاتصال بالخادم). يرسل عميل MCP طلب tools/list إلى الخادم (وهذا محدد في البروتوكول). يرد الخادم بقائمة أدواته المتاحة، ولكل منها تفاصيل مثل الاسم والوصف ومخطط الإدخال.

  على سبيل المثال، قد يرد خادم بأن لديه الأدوات create_file(path, content), read_file(path), and search_files(query) متاحة. بعد ذلك يجعل العميل هذه المعلومات متاحة لـ LLM. في كثير من التطبيقات، سينسق العميل أوصاف الأدوات هذه ويدرجها في سياق النموذج (على سبيل المثال، إضافتها إلى موجه النظام: “لديك وصول إلى الأدوات التالية… [قائمة الأدوات]”).

إليك موجه نظام ذكاء اصطناعي مع رسالة المستخدم التي تطلب الوقت الحالي

بعد تطبيق أدوات MCP، يتم دمج أداة تسمى “get_current_time”، ما يتيح للذكاء الاصطناعي الوصول إلى مورد خارجي وجلب الوقت الدقيق في لندن

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

• استخدام أداة عبر MCP. عندما يحتاج الذكاء الاصطناعي إلى تنفيذ إجراء أو جلب بيانات، سيستدعي أداة عبر MCP. من منظور الذكاء الاصطناعي (خصوصا للنماذج مثل Claude التي تدعم استخدام الأدوات أصلا)، سيقرر في استدلاله: “يجب أن أستدعي الأداة X بهذه المعاملات.” يلتقط عميل MCP تلك النية ويرسل طلب tools/call بصيغة MCP إلى الخادم المناسب (خادم Google Drive MCP).

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

  ما تجدر ملاحظته هو أن خوادم MCP تتبع نهجا منظما للتعامل مع الأخطاء، ما يضمن أن AI Agents يستطيعون تفسيرها والتصرف بناء عليها بفعالية.

  لنفترض أن AI Agent يستخدم أداة MCP للعثور على ملف في Google Drive. إذا تضمن الطلب معرف ملف غير صالح (مثلا، سلسلة بطول خمسة أحرف بدلا من الصيغة المتوقعة)، فسيعيد خادم MCP رسالة خطأ:

  بدلا من الفشل ببساطة، يستطيع AI Agent أخذ هذه الاستجابة المنظمة وإعادة صياغتها كتغذية راجعة سهلة الفهم للمستخدم:

  “يبدو أن معرف الملف الذي قدمته قصير جدا. تكون معرفات ملفات Google Drive عادة بطول 28 حرفا. هل يمكنك التحقق مرة أخرى والمحاولة من جديد؟”

  يضمن هذا النهج ألا تؤدي الأخطاء إلى طرق مسدودة، بل تصبح فرصا ليوجه AI Agent المستخدم نحو حل ناجح.

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

  إذا طلب المستخدم إنشاء ملف Google Sheets جديد، فسيتم تمرير رد الخادم (الذي يحتوي على معرف الملف ورابط مولد) إلى النموذج. ثم سيرد النموذج على المستخدم بـ: “خبر جيد! ملف Google Sheets الجديد جاهز. يمكنك الوصول إليه هنا: [link].”

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

فوائد استخدام MCP

لاحظ كيف يجرّد هذا النهج الكثير من التفاصيل: لم يتعامل العميل مع مفاتيح API أو رموز حالة HTTP، إذ يتولى خادم MCP ذلك.

النقطة الأساسية هي البساطة عند نقطة التكامل: نحن “نطلب” العملاء، ونحصل عليهم. منطق كيفية جلبهم مغلف في مكان آخر. هذا يعني أن المطور الذي يعمل على جانب الذكاء الاصطناعي لا يحتاج إلى كتابة استدعاءات HTTP جديدة لكل إجراء جديد، بل يستدعي الأدوات بالاسم فقط. يتولى شيفرة خادم MCP العمل الثقيل (المصادقة، واستدعاء نقاط نهاية Google Drive، وتنسيق الاستجابة)، وهي شيفرة قابلة لإعادة الاستخدام وموحدة.

إليك ملخصا للفوائد الرئيسية:

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

• موصلات قابلة لإعادة الاستخدام ومشتركة بدلا من مغلفات API لمرة واحدة. مع MCP، تكتب التكامل مرة واحدة ويمكنك إعادة استخدامه عبر مشاريع وأنظمة ذكاء اصطناعي كثيرة. على سبيل المثال، يمكنك إنشاء خادم MCP للويكي الداخلي لشركتك. يمكن لأي تطبيق ذكاء اصطناعي يدعم MCP الاتصال بذلك الخادم الواحد للاستعلام عن الويكي. لا تحتاج إلى إعادة تنفيذ “بحث الويكي” لكل chatbot ذكاء اصطناعي جديد أو لكل مورّد LLM مختلف. تمثل إعادة الاستخدام هذه تحولا عن الماضي، حيث كان كل فريق يكتب تكاملا مختلفا قليلا للـ API نفسه. يشجع MCP على مكتبة من الموصلات التي يمكن مشاركتها وتحسينها جماعيا.

• تكامل plug-and-play مع نماذج LLM مختلفة. MCP مستقل عن النموذج. لا يهتم البروتوكول بما إذا كان العميل Claude أو GPT-4 أو DeepSeek أو أي نموذج مستقبلي، ما دام العميل يستطيع التعامل مع واجهة MCP. في المستقبل، إذا أردت الانتقال إلى نموذج آخر، يمكنك فعل ذلك دون إعادة كتابة كل تكاملاتك.

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

هل ستصبح تكاملات API قديمة؟

لكل من تكاملات API التقليدية وMCP مكانه. قد يعتمد النهج الأفضل على طبيعة المشروع وخبرة الفريق والأهداف طويلة الأمد.

إذا كنت تحتاج فقط إلى التكامل مع خدمة خارجية واحدة أو خدمتين، وكانت التفاعلات بسيطة نسبيا، فغالبا ما يكون تكامل API المباشر أسرع حل. إذا كان تطبيق الويب لديك يحتاج فقط إلى التحقق من رمز دفع Stripe عند إتمام الشراء، فإن استدعاء Stripe API مباشرة بسيط وفعال. قد يكون إدخال MCP في هذا السيناريو مبالغة. يمكنك ربط AI Agent بأي REST API موثق باستخدام HTTP Action واحدة تمت مراجعتها، أو استخدام تكامل بنقرة واحدة مثل Google Sheets لتسجيل العملاء المحتملين وطلبات العروض التجريبية، دون تشغيل خادم MCP.

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

للحصول على مثال ملموس حول كيفية إتاحة أدوات MCP لـ AI Agent إنتاجي إلى جانب إجراءات API مخصصة، انظر كيف تجمع Quickchat AI Agents بين النهجين. وتوجد مناقشة أعمق حول متى تستخدم MCP أو AI Actions فردية أو “Generate from Text” في APIs for AI Agents: From MCP to Custom Endpoints. لتجربته بنفسك، اتبع الدليل خطوة بخطوة من أجل ربط AI Agent بخادم MCP بعيد بحيث يستدعي أداة مباشرة أثناء المحادثة.

قائمة خوادم MCP المتاحة

إذا كنت تريد البدء مع MCP، فراجع أدلة خوادم MCP أدناه:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

يمكنك أيضا تشغيل واحد دون كتابة أي شيفرة: يمكن تحويل كل Quickchat AI Agent إلى خادم MCP باستخدام URL مستضاف يستدعيه Claude وChatGPT وCursor كأداة. يعمل الاتصال في الاتجاه الآخر أيضا: يستطيع Quickchat AI Agent استدعاء خادم MCP مستضاف لدى مورّد كأدواته، وهذه هي الطريقة التي يتحقق بها مساعد جدولة ذكاء اصطناعي مبني على خادم MCP من Calendly من التوفر الحقيقي ويحجز الاجتماعات من دردشة، والطريقة التي يجيب بها chatbot ذكاء اصطناعي لـ Notion من مركز مساعدة مباشر ويسجل طلبات الدعم مرة أخرى في قاعدة بيانات Notion.

يشغّل Quickchat AI أيضا خادم MCP بعيدا لحسابك الخاص. صِله بـ ChatGPT أو Claude أو Cursor أو Codex، ويمكنك إدارة AI Agents الخاصة بك من هناك: التحليلات، ونصوص المحادثات، وتحديثات knowledge base، وإنشاء Agents جدد، خلف تسجيل دخول OAuth واحد. يوجد شرح الإعداد لكل عميل في Manage Your AI Agent from ChatGPT, Claude, and Codex with MCP.

الأسئلة الشائعة

هل يعمل فقط مع Claude؟

MCP مستقل عن النموذج. لا يهتم البروتوكول بما إذا كان العميل Claude أو GPT-4 أو مشتقا محليا من LLaMA أو أي نموذج مستقبلي، ما دام العميل يستطيع التعامل مع واجهة MCP. هذا يعني أنك لا تكون مقيدا بمزود ذكاء اصطناعي واحد عند بناء تكاملات الأدوات لديك.

كيف يختلف MCP عن إعطاء النموذج كل المعلومات التي يحتاجها مسبقا؟ لماذا لا نملأ الموجه بالبيانات بدلا من ذلك؟

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

ماذا لو وصلنا عشرات الأدوات بالذكاء الاصطناعي؟ ألن يربك ذلك النموذج أو يجعله يسيء استخدامها؟

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

MCP مقابل Function Calling

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

MCP مقابل GPT Actions & Plugins

تشير GPT Actions/Plugins إلى منظومة OpenAI التي كان يمكنك فيها تمكين إضافات (مثل متصفح ويب، أو قارئ PDF) لـ ChatGPT، أو “GPTs” (وكلاء ChatGPT مخصصين) يمكنهم استخدام الأدوات. كانت هذه مثيرة للاهتمام، لكنها تطلبت تطويرا مخصصا لكل إضافة وكانت محدودة بمنصات OpenAI. إذا أردت إضافة ChatGPT لمهمة ما، كان عليك إنشاء API وملف manifest، والمرور بموافقة OpenAI أو على الأقل تمكينها يدويا. كانت كل إضافة في الأساس صومعة مستقلة، إضافة طقس، إضافة سفر، إلخ، ولكل منها نقاط نهاية ومنطق خاصان بها. يحسن MCP هذا المفهوم عبر توحيده وفتحه.

MCP مقابل RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) تقنية يُدعّم فيها LLM بقاعدة معرفة خارجية. عادة، يتضمن RAG قاعدة بيانات متجهية أو فهرس بحث: يُستخدم استعلام المستخدم لجلب مستندات أو بيانات ذات صلة (بالبحث الدلالي أو طرق أخرى)، وتُقدم تلك المستندات إلى النموذج كسياق إضافي “ليقرأه” عند صياغة إجابة. يتمحور RAG حول إعطاء النموذج معرفة لم تكن لديه أصلا، وهو مفيد خصوصا في الأسئلة والأجوبة الواقعية أو المعلومات الخاصة بمجال معين. ومع ذلك، RAG للقراءة فقط، إذ يسترجع النموذج مقاطع نصية، لكنه لا ينفذ إجراءات تتجاوز الاسترجاع.

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