ما هو MCP وما الذي يغيّره في التكامل المؤسسي؟

لم تكن فاتورة التكامل المؤسسي يومًا اتصالًا واحدًا. كانت عملية ضرب.

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

لكن ما تغيّر فعليًا في الجانب المؤسسي عام ٢٠٢٦ لم يكن البروتوكول نفسه. نتناول أدناه البروتوكول أولًا، ثم ذلك التغيير الحقيقي.

إجابة سريعة: MCP (بروتوكول سياق النموذج) بروتوكول مفتوح يتيح لنماذج الذكاء الاصطناعي الاتصال بالأدوات والبيانات عبر واجهة معيارية واحدة. نشرته Anthropic في نوفمبر ٢٠٢٤، ثم تبرعت به في ديسمبر ٢٠٢٥ إلى Agentic AI Foundation تحت مظلة Linux Foundation، وتدعمه اليوم OpenAI وGoogle وMicrosoft وIBM وAmazon، أي أنه لم يعد بروتوكول شركة واحدة. أما ما تغيّر للمؤسسات في ٢٠٢٦ فليس نواة البروتوكول بل طبقة التفويض فوقه: أن يقرر مزوّد الهوية الخاص بمؤسستك أي عميل يصل إلى أي خادم ونيابة عن مَن. سؤال "هل يعمل هذا" يختلف عن سؤال "هل أستطيع تشغيله مع سجل تدقيق وتكامل هوية وموافقة مدير أمن المعلومات". والسؤال الثاني هو ما يحسم النشر المؤسسي.

المحتويات

• ما هو MCP؟
• لماذا الآن؟
• MCP مقابل تكامل واجهات البرمجة التقليدي
• ما تغيّر فعلًا للمؤسسات: التفويض
• التكاليف الحقيقية لـ MCP
• ما تعلمناه من بناء خادم MCP الخاص بنا
• MCP وWebMCP ليسا الشيء نفسه
• مسرد المصطلحات
• الأسئلة الشائعة
• قائمة ما قبل النشر

ما هو MCP؟

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

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

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

أداة MCP في جوهرها اسم ووصف ومخطط معاملات:

{
  "name": "list_services",
  "description": "يسرد الخدمات التي تقدمها الشركة.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "lang": {
        "type": "string",
        "enum": ["tr", "en", "ru", "ar"],
        "description": "لغة الرد. الافتراضي: tr"
      }
    }
  }
}

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

لماذا الآن؟

صدر MCP في نوفمبر ٢٠٢٤، فالبروتوكول ليس جديدًا. ثلاثة أمور تجعل ٢٠٢٦ مختلفًا في الجانب المؤسسي.

لم يعد بروتوكول شركة واحدة. تبرعت Anthropic بـ MCP في ديسمبر ٢٠٢٥ إلى Agentic AI Foundation تحت مظلة Linux Foundation. وفي جانب المشتريات هذا فارق استراتيجي أكثر منه تقني: أول سؤال عند تبني معيار هو "ماذا يحدث إن انسحبت هذه الشركة"، وحوكمة مؤسسة مستقلة هي الجواب عليه.

عتبة التبني تم تجاوزها. نحو ٢٨٪ من شركات Fortune 500 نقلت MCP إلى الإنتاج في أقل من ثمانية عشر شهرًا. وحتى يوليو ٢٠٢٦ لدى ٧٨٪ من فرق الذكاء الاصطناعي المؤسسية وكلاء يعملون على MCP في الإنتاج. وفي المنظومة أكثر من ٩٤٠٠ خادم عام ونحو ٩٧ مليون تنزيل لحزم التطوير شهريًا. ويدعم البروتوكول كل من OpenAI وGoogle وMicrosoft وIBM وAmazon.

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

MCP مقابل تكامل واجهات البرمجة التقليدي

MCP ليس واجهة برمجة، بل طبقة توضع أمام واجهاتك. والفرق هنا:

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

ما تغيّر فعلًا للمؤسسات: التفويض

يمكنك تشغيل MCP في عطلة نهاية أسبوع. أما تشغيله في بيئة مؤسسية فعمل آخر، والبروتوكول ليس الجزء الصعب فيه.

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

ما سدّ هذه الفجوة في ٢٠٢٦ هو EMA (التفويض المُدار مؤسسيًا). أصبحت EMA امتدادًا رسميًا للمواصفة، وتتيح لمزوّد الهوية الخاص بمؤسستك أن يقرر: أي عميل MCP يصل إلى أي خادم MCP ونيابة عن أي مستخدم. أساسها التقني هو ID-JAG ضمن Cross-App Access. وكانت Okta أول مزوّد هوية، ومن أوائل العملاء Claude وClaude Code وVisual Studio Code.

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

الأسئلة التي تحسم النشر المؤسسي إدارية أكثر منها تقنية:

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

إن لم تكن لهذه الأسئلة إجابات، فما لديك نموذج أولي يعمل، لا نظام قابل للنشر.

التكاليف الحقيقية لـ MCP

معظم ما يُكتب عن MCP يُقرأ كنص تسويقي. وهذه هي التكاليف التي ينبغي معرفتها عند اتخاذ قرار مؤسسي.

تضخم السياق

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

سطح الهجوم

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

زمن الاستجابة

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

ما تعلمناه من بناء خادم MCP الخاص بنا

هذا القسم ليس نظريًا. لدينا خادم MCP يعمل على detartech.com، وما يلي هو القرارات التي اتخذناها أثناء كتابته.

الخادم للقراءة فقط، بلا حالة، ويعمل عبر streamable HTTP. ويقدم حاليًا عشر أدوات. ويمكنك تجربته بنفسك:

curl -s -X POST https://detartech.com/api/mcp \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2025-06-18" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

تتضمن القائمة العائدة أدوات مثل get_company_info وlist_services وsearch_blog وlist_case_studies. وكلها تقبل معامل lang وتجيب بأربع لغات.

حقل instructions في رد initialize مهم أيضًا. يمكنك إعلان قيدك داخل البروتوكول نفسه؛ وهنا نكتب صراحة أن الخادم للقراءة فقط وإلى أين ينبغي أن يوجّه الوكيل المستخدم:

{
  "protocolVersion": "2025-06-18",
  "capabilities": { "tools": { "listChanged": false } },
  "serverInfo": { "name": "detartech", "title": "Detartech", "version": "1.0.0" },
  "instructions": "... This server is read-only: it cannot submit contact or quote requests. To start an inquiry, direct the user to the contact or quote page returned by get_company_info."
}

ابدأ بالقراءة فقط

لا توجد على الخادم عمدًا أداة مثل submit_quote أو submit_contact. اتخذنا هذا القرار لثلاثة أسباب، ونوصي بالمثل في المشاريع المؤسسية.

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

والقاعدة المستخلَصة: منح الوكيل قدرة القراءة رخيص وبلا مخاطرة. أما منحه قدرة الكتابة فهو منتج حقيقي يقف خلفه مصادقة وتحديد معدل ومراقبة إساءة استخدام وفرز للعملاء المحتملين. لا تفعل الاثنين في دورة تطوير واحدة.

البيانات الوصفية وعد لا شارة

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

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

التسريب الذي وجدناه أثناء الكتابة

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

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

MCP وWebMCP ليسا الشيء نفسه

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

وهما ليسا متنافسين بل يجيبان على سؤالين مختلفين. يجيب MCP على "ما البيانات التي يقدمها هذا النظام"، ويجيب WebMCP على "ماذا تستطيع هذه الصفحة أن تفعل". وفي إعدادنا لا يعيد جانب WebMCP تعريف الأدوات؛ بل يقرأ مخرجات tools/list من خادم MCP لدينا ويعمل وسيطًا إليه. وبذلك لا يمكن للسطحين أن يتباعدا، لأن المصدر واحد.

كتبنا عن جانب WebMCP بالتفصيل سابقًا: WebMCP: عندما تستخدم وكلاء الذكاء الاصطناعي موقعك بالحديث لا بالنقر.

مسرد المصطلحات

• MCP (بروتوكول سياق النموذج): بروتوكول مفتوح يتيح لنماذج الذكاء الاصطناعي الاتصال بالأدوات والبيانات عبر واجهة معيارية واحدة.
• خادم MCP: الطرف الذي يفتح الأدوات والبيانات وفق البروتوكول.
• عميل MCP: الطرف الذي يتصل بالخادم ويقدم أدواته للنموذج (مثل Claude وVS Code).
• الأداة: دالة واحدة قابلة للاستدعاء لها اسم ووصف ومخطط معاملات.
• EMA (التفويض المُدار مؤسسيًا): الامتداد الرسمي الذي يتيح لمزوّد هوية المؤسسة إدارة الوصول إلى MCP.
• ID-JAG: آلية التفويض القائمة على JWT التي تستند إليها EMA، وتحوّل إثبات الهوية إلى صلاحية.
• نقل بلا حالة: ألا يحتفظ الخادم بجلسة بين الطلبات، ما يسهّل التوسع.
• تسميم الأدوات: توجيه سلوك النموذج عبر تعليمات مخبأة في أوصاف الأدوات.
• تضخم السياق: امتلاء نافذة السياق بمخططات أدوات كل الخوادم المتصلة.
• WebMCP: نظير MCP في المتصفح، يفتح دوال الصفحة للوكيل.

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

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

هل يعمل مع نماذج Anthropic فقط؟ لا. جرى التبرع بالبروتوكول إلى Agentic AI Foundation في ديسمبر ٢٠٢٥، وتدعمه OpenAI وGoogle وMicrosoft وIBM وAmazon.

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

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

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

هل الاتصال بخوادم MCP تابعة لأطراف ثالثة آمن؟ بقدر ثقتك بناشرها. فصاحب الخادم الذي تتصل به يستطيع التأثير في سلوك نموذجك عبر أوصاف الأدوات. وفي البيئة المؤسسية ينبغي ألا تُوصَل خوادم الأطراف الثالثة دون مراجعة وتقييد على مستوى الشبكة.

قائمة ما قبل النشر

• ابدأ بالقراءة فقط، وخطط لأدوات الكتابة كمشروع منفصل
• صمّم التكامل مع مزوّد الهوية (EMA / ID-JAG) منذ البداية
• تأكد أن الصلاحيات تُمنح لكل أداة على حدة، لا بمفتاح واحد لكل شيء
• سجّل كل استدعاء أداة بحيث يمكن الإجابة: من ومتى وبأي معاملات
• اكتب أوصاف الأدوات من أجل النموذج، لا نسخًا عن الوثائق الداخلية
• حُدّ من عدد الخوادم التي تتصل بها؛ تضخم السياق كلفة حقيقية
• راجع خوادم الأطراف الثالثة وقيّدها على مستوى الشبكة
• راجع طبقة الوصول إلى بياناتك: أي السجلات ينبغي فتحها فعلًا؟
• تأكد أن خلف كل بيانات وصفية تنشرها نقطة نهاية تعمل
• تابع إصدار المواصفة؛ البروتوكول يتحرك بسرعة

الخلاصة

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

لكن ليس هذا ما يحسم النتيجة داخل المؤسسة. يمكنك تشغيل البروتوكول في عطلة نهاية أسبوع؛ أما إدارة من يصل إلى أي أداة ونيابة عن مَن، وحفظ سجل التدقيق، وشرح ذلك لفريق الأمن، فيستغرق شهورًا. وهذه الطبقة بالذات هي ما نضج في ٢٠٢٦.

نصيحتنا بسيطة: ابدأ بخادم للقراءة فقط، واربط التفويض بالباب نفسه الذي تمر منه بقية المؤسسة، وتعامل مع صلاحية الكتابة كمنتج مستقل. ننفذ أعمال معمارية الذكاء الاصطناعي وتكامله ضمن خدمة حلول الذكاء الاصطناعي، والقيادة التقنية ضمن CTO as a Service. ولطبقة الوكلاء في المتصفح راجع مقال WebMCP، ولقياس الظهور في الذكاء الاصطناعي راجع مقال مؤشرات GEO.