بنية MCP: شرح تقني شامل مع مخططات توضيحية

بنية MCP هي المجموعة الأساسية من المكونات وقواعد الاتصال التي تجعل MCP (بروتوكول سياق النموذج Model Context Protocol) ممكنًا. يُعد MCP معيارًا مفتوح المصدر، وبنية MCP هي البنية التحتية الأساسية التي يعمل عليها.

تحتوي أي بنية MCP على ثلاثة مكونات أساسية وتُبنى حولها: المضيف، والعميل، والخادم. وغالبًا ما يوصف إطار الاتصال في MCP بأنه يتكون من طبقة بيانات وطبقة نقل. طبقة البيانات هي مجموعة القواعد التي تحدد كيفية تنسيق الرسائل (تُرسل طلبات MCP بتنسيق JSON-RPC 2.0). أما طبقة النقل فتنقل هذه الرسائل، مستخدمةً Streaming HTTP للاتصالات الخارجية.

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

مخطط لبنية MCP: يتبادل تطبيق ذكاء اصطناعي الطلبات مع خادم MCP، الذي يوفّر الأدوات والموارد والموجّهات.

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

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

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

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

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

التطبيق المضيف هو منصة التنسيق المركزية، ويتصل بنموذج لغوي كبير. ويمكن لأدوات معروفة مثل Perplexity وClaude Desktop أن تعمل كمضيفين ضمن نظام MCP.

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

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

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

مخطط لمضيف MCP، مثل Perplexity، ينسّق ثلاثة عملاء MCP، يتصل كل منهم بخادم MCP خاص به، مثل قاعدة بيانات أو ملفات أو واجهة API خارجية.

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

يمكن لخوادم MCP توفير الوصول إلى ثلاث فئات من العناصر الأساسية:

الأدوات: وهي في جوهرها وظائف برمجية خارجية. فإذا نظرت إلى النهج التقليدي القائم على واجهات API، فقد يسترجع تطبيق لتحليلات الويب البيانات باستخدام طلب منسّق إلى خادم خارجي. أما في بنية MCP، فتكون جميع الوظائف الخارجية التي يقدمها المزوّد متاحة عبر اتصال واحد، وتُنشأ الطلبات وفق قواعد تنسيق قياسية.
الموارد: الموارد هي مصادر بيانات توفّر سياقًا للقراءة فقط، ومخططات قواعد البيانات مثال جيد على ذلك. إذ يتيح خادم MCP مصادر المعلومات المختلفة المتاحة للمضيف. وإذا استعلم المضيف من قاعدة البيانات، كأن يجري بحثًا بلغة SQL ينشئه نموذج لغوي كبير، فإن ذلك يُعد طلب أداة.
الموجّهات: وهي قوالب موجّهات قابلة لإعادة الاستخدام تساعد النماذج اللغوية الكبيرة على أداء مهام محددة. يستدعي المستخدم أو المضيف موجّهًا بدلًا من أداة لأن المهمة تتطلب تعليمات جاهزة لإنجازها. وغالبًا ما تُخزَّن المهام المعدّة مسبقًا في التطبيق المضيف، مثل خيار «مراجعة الكود» أو «تحليل البيانات»، كموجّهات يمكن للمستخدم اختيارها.

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

طبقة البيانات في بنية MCP هي مجموعة القواعد التي تحدد كيفية تنسيق الطلبات والاستجابات والإشعارات. واللغة القياسية للرسائل هي JSON-RPC.

تتبع كل بنى MCP عملية أساسية تتكون من: (1) التهيئة والاكتشاف من جانب المضيف، و(2) الاستجابة من خادم MCP، و(3) الاستدعاء من جانب المضيف (الذي يقرره النموذج اللغوي الكبير أحيانًا)، وتمثل كل مرحلة رسالة JSON منفصلة.

مخطط لطبقة بيانات MCP: يرسل المستخدم موجّهًا إلى التطبيق المضيف، حيث يعمل النموذج اللغوي الكبير مع عميل MCP؛ ويرسل العميل طلبًا إلى خادم MCP (الأدوات، والموارد، والموجّهات) ويتلقى نتيجة، ثم يعيد المضيف استجابة إلى المستخدم.

لنلقِ نظرة على آلية اكتشاف الأدوات من خلال مثالين (ويمكن تطبيقهما على الموارد أو الموجّهات أيضًا):

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

عادةً ما يختار النموذج اللغوي الكبير أو المضيف الأدوات، وهي في الغالب وظائف لتطبيقات خارجية. أما الموارد والموجّهات فتُطلب عادةً بناءً على رغبة المستخدم أو من قِبل المضيف.

إليك شكل طلب tools/list إلى خادم MCP من تطبيق ملاحظات افتراضي:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

في هذا المثال، يحدد “id”:101 الطلب باستخدام معرّف كي يتمكن العميل من مطابقة الاستجابات، ويحتوي الحقل “params” على معلومات إضافية عن العميل، مثل اسم العميل (notes-app-client) وقدراته.

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

إليك الشكل الذي قد يبدو عليه الطلب:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

يُبلغ الحقل “method” خادم MCP بأن هذا استدعاء أداة، ويحدد “name” الأداة المطلوب استدعاؤها، ويوفّر “arguments” المدخلات المطلوبة.

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

يتضمن MCP مسارين للنقل:

الإدخال/الإخراج القياسي: يُستخدم عندما يعمل خادم MCP في البيئة المحلية نفسها التي يعمل فيها التطبيق المضيف. إذ يكتب العميل طلب JSON إلى الإدخال القياسي للخادم، فيقرأه الخادم، وينفّذ العملية المطلوبة، ثم يكتب الاستجابة إلى الإخراج القياسي.
Streamable HTTP: عندما يعمل خادم MCP خارج التطبيق المضيف، يرسل عميل MCP الطلبات إلى الخادم باستخدام HTTP POST. ويستجيب الخادم إما برسالة JSON واحدة أو بتدفق Server-Sent Events (SSE)، وهو قناة «استماع» مستمرة تتيح له إرسال رسائل متعددة بمرور الوقت.

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

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

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

كيف يبدو طلب MCP الكامل من البداية إلى النهاية عمليًا؟ هناك ثماني مراحل أساسية، تتضمن كل منها مكوّنًا مختلفًا من مكونات البنية.

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

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

اكتشاف الأدوات: يستخدم تطبيق الملاحظات (المضيف) عميل MCP الخاص به لطلب الأدوات المتاحة على الخادم عبر طلب tools/list. ويعيد الخادم أسماءها وأوصافها والمدخلات المتوقعة لها، بما في ذلك مدخلات الأداة add-task. وقد يحدث ذلك قبل أن ترسل موجّهك.
إدخال المستخدم: ترسل طلبًا إلى تطبيق الملاحظات القائم على نموذج لغوي كبير عبر روبوت الدردشة المدمج في التطبيق، مثل: «أنشئ مهمة في تقويمي لمراجعة مسودتي الجديدة بأولوية متوسطة».
معالجة النموذج: يرسل المضيف طلبك وتعريفات الأدوات ذات الصلة إلى النموذج اللغوي الكبير.
اختيار الأداة: يُنشئ النموذج اللغوي الكبير طلب أداة منظّمًا يحدد فيه الأداة ومدخلاتها: add-task مع title: Review the draft وpriority: Medium. ويتحقق المضيف مما إذا كان الإجراء مسموحًا به، ثم يمرر الطلب إلى عميل MCP، الذي يرسل رسالة JSON-RPC.
الطلب: يرسل عميل MCP طلب tools/call إلى خادم MCP الخاص به.
تنفيذ الأداة: يستدعي خادم MCP واجهة API الخاصة بتطبيق إدارة المهام لإنشاء مهمة جديدة بالعنوان والأولوية المحددين.
إرجاع النتيجة: يرسل الخادم النتيجة إلى عميل MCP، الذي يمررها إلى المضيف. ثم يضيفها المضيف إلى المعلومات المقدَّمة إلى النموذج اللغوي الكبير.
توليد الإجابة: يستخدم النموذج اللغوي الكبير النتيجة لتوليد إجابة للمستخدم، مثل: «أنشأتُ مهمة لمراجعة المسودة بأولوية متوسطة».

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

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

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

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

تنطوي بنية MCP على نقاط الضعف المحتملة التالية:

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

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

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

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

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

ما بنية MCP؟

مكونات بنية MCP: المضيفون والعملاء والخوادم

المضيف

العميل

الخادم

ما طبقة البيانات في بنية MCP؟

ما طبقة النقل في بنية MCP؟

ما بنية MCP متعددة المستأجرين؟

مخطط بنية MCP: شرح تفصيلي خطوة بخطوة

كيف تختلف بنية MCP عن بنية API التقليدية؟

هل بنية MCP آمنة؟

ما مستقبل بنية MCP؟