الإجابة المختصرة
MCP (بروتوكول سياق النموذج) هو معيار مفتوح يحدّد طريقة موحّدة يتواصل بها تطبيق يستضيف نموذجًا أو وكيلًا (العميل) مع خادم يعرض أدوات وبيانات ومطالبات جاهزة. بدل أن تبني تكاملًا مخصّصًا لكل نظام خارجي يحتاجه كل وكيل، يتحدّث الوكيل بلغة واحدة مع أي خادم يدعم البروتوكول، ويتحدّث الخادم بنفس اللغة مع أي عميل.
المشكلة التي يحلّها MCP
قبل وجود معيار موحّد، كان ربط وكيل بعدد من الأنظمة (بريد، CRM، قاعدة بيانات، أداة بحث) يعني بناء تكامل مخصّص لكل زوج «وكيل – نظام». مع تعدّد الوكلاء وتعدّد الأنظمة، يتحوّل هذا إلى مشكلة M×N: عدد التكاملات المطلوبة يتناسب مع حاصل ضرب عدد الوكلاء في عدد الأنظمة. MCP يستبدل هذه الشبكة من التكاملات المتفرّقة بواجهة قياسية واحدة: يبني مزوّد كل نظام خادم MCP مرّة واحدة، ويستفيد منه أي وكيل يدعم البروتوكول دون كتابة كود تكامل خاص لكل حالة.
أدوار العميل والخادم
في بنية MCP طرفان رئيسيان. العميل هو الجزء المدمج داخل تطبيق الوكيل، وهو المسؤول عن اكتشاف الخوادم المتاحة والتواصل معها نيابة عن الوكيل. الخادم هو الطرف الذي يعرض قدرات محدّدة — أدوات يمكن استدعاؤها، بيانات يمكن قراءتها، أو تعليمات جاهزة يمكن استخدامها — ويستجيب لطلبات العميل وفق مواصفة البروتوكول. وكيل واحد قد يتصل بعدّة خوادم في آن واحد، كل خادم متخصّص بنظام مختلف.
الأدوات والموارد والتعليمات
- الأدوات (Tools): قدرات قابلة للاستدعاء لتنفيذ إجراء أو جلب نتيجة، مشابهة لمفهوم أدوات الوكيل عمومًا.
- الموارد (Resources): بيانات أو محتوى يمكن للعميل قراءته وتمريره كسياق إضافي للنموذج، دون أن يكون استدعاء إجرائيًا.
- التعليمات الجاهزة (Prompts): قوالب تفاعل معدّة مسبقًا يعرضها الخادم ليستخدمها العميل أو المستخدم مباشرة.
هذا الفصل بين ثلاثة مفاهيم يمنح الخادم مرونة في عرض قدراته: نظام إدارة معرفة قد يعرض مواردَ للقراءة فقط، بينما نظام CRM قد يعرض أدواتٍ للقراءة والكتابة معًا.
خادم بعيد مقابل محلي
قد يعمل خادم MCP محليًا على نفس الجهاز الذي يعمل عليه العميل، وهو ما يناسب أدوات نظام التشغيل أو الملفات المحلية. أو قد يعمل بعيدًا عبر الشبكة كخدمة يستضيفها طرف آخر، وهو الشائع عند ربط الوكيل بنظام سحابي مؤسسي. الفرق الجوهري ليس في القدرات المعروضة بل في سطح الهجوم: خادم بعيد يضيف طبقة اتصال شبكي وهوية ومصادقة يجب تأمينها، بينما الخادم المحلي يعتمد على عزل الجهاز نفسه.
اعتبارات الأمان
الاتصال بخادم MCP قرار ثقة، تمامًا كأي تكامل خارجي آخر — البروتوكول نفسه لا يجعل الخادم آمنًا تلقائيًا. أهم الاعتبارات:
- التفويض (Authorization): يجب أن يمنح الخادم فقط الصلاحيات اللازمة، وأن تتحقّق هوية العميل والمستخدم قبل تنفيذ أي أداة كتابة.
- تحديد النطاق (Scoping): لا تمنح خادمًا واحدًا صلاحية على كل الأنظمة إن كان يحتاج جزءًا محدودًا منها فقط.
- الثقة بالخادم: تشغيل خادم من طرف ثالث يعني تفويضه بمعالجة طلبات نيابة عن وكيلك؛ تحقّق من مصدره قبل ربطه ببيانات حسّاسة.
- حقن التعليمات عبر مخرجات الأداة: مخرجات أي أداة أو مورد قد تحتوي نصًّا مصمَّمًا لخداع النموذج (prompt injection عبر المحتوى المسترجَع)، لذا يجب معاملة مخرجات الخادم كبيانات غير موثوقة لا كتعليمات مباشرة.
MCP مقابل تكامل مخصّص
| المعيار | MCP | تكامل مخصّص مباشر |
|---|---|---|
| جهد البناء لكل مصدر جديد | يُبنى خادم واحد يستفيد منه أي عميل داعم | تكامل منفصل لكل زوج وكيل-نظام |
| إعادة الاستخدام | عالية عبر وكلاء وعملاء متعدّدين | محدودة بالتكامل نفسه |
| التحكّم الدقيق بالسلوك | حسب ما يعرضه الخادم من أدوات وموارد | تحكّم كامل لأنك تكتب المنطق مباشرة |
| ملاءمة نظام فريد وداخلي بالكامل | مفيد إن أردت إتاحته لعدّة عملاء لاحقًا | غالبًا أبسط إن كان مستخدَمًا من وكيل واحد فقط |
| اعتبارات الأمان | تضيف طرفًا ثالثًا (الخادم) يجب تقييم الثقة به | السطح محدود بما تكتبه أنت وتتحكّم فيه بالكامل |
متى تستخدم MCP بدل تكامل مباشر
MCP مفيد بوضوح حين يحتاج أكثر من وكيل أو تطبيق الاتصال بنفس النظام الخارجي، أو حين تريد الاستفادة من خوادم جاهزة بناها آخرون بدل إعادة بناء التكامل من الصفر. أما إن كان التكامل خاصًّا تمامًا بمنطق داخلي لن يستخدمه إلا وكيل واحد، فتكامل مباشر عبر أداة مخصّصة قد يكون أبسط وأسهل ضبطًا. في WKIL، دعم MCP موثّق ضمن توثيق الوكلاء وضمن دليل النشر لمن يريد ربط وكيله بخوادم متوافقة مع البروتوكول.