يسأل مدير المبيعات لديك مساعد الذكاء الاصطناعي عن الصفقات التي تعثّرت هذا الربع، فيجيبه من جدول بيانات صدّره أحدهم يوم الاثنين. ويريد مدير العمليات وكيلاً يحدّث حالة الطلبات في NetSuite، فيسأل قسم تقنية المعلومات: من سيبني الموصّل، ومن سيصونه، وما الذي سيُسمح للوكيل بتغييره؟ وفي مكان ما من هذا النقاش يظهر اختصار جديد: MCP.
الجواب المختصر في مسألة MCP مقابل API هو أن MCP لا يحلّ محل واجهات API لديك، بل يعمل فوقها. فواجهة API هي الطريقة التي يتواصل بها نظام مع آخر؛ أما بروتوكول Model Context Protocol فهو طريقة موحّدة لوصف ما يستطيع النظام فعله، بحيث يتمكّن أي وكيل ذكاء اصطناعي من العثور على تلك القدرات واستخدامها. لربط وكلاء الذكاء الاصطناعي بنظام CRM أو ERP، ابدأ بخادم MCP الذي يوفّره المورّد لديك بالفعل، واعتمد على واجهة API حيث يقصر، واحتفظ بمنصة iPaaS حيث تدير تكاملاتك أصلاً. يشرح هذا الدليل كيف تتكامل هذه العناصر الثلاثة، وما الذي تتيحه فعلاً خوادم MCP من Salesforce وHubSpot وNetSuite وSAP، وكيف تسمح للوكيل بالكتابة في سجلاتك دون أن يُفسدها.
- MCP طبقة فوق واجهات API: فخادم MCP يستدعي عادةً واجهات API نفسها التي تستخدمها تكاملاتك أصلاً.
- أصبحت Salesforce وHubSpot وNetSuite توفّر خوادم MCP خاصة بها، وكلٌّ منها يعمل بصلاحيات الشخص الذي يُجري الاتصال.
- الوكيل الذي يستطيع الكتابة في نظام CRM أو ERP يحتاج إلى أدوات محدودة النطاق، وموافقة مسبقة على التغييرات ذات الأثر، وسجلّ لكل إجراء، أيّاً كانت طريقة الاتصال التي يستخدمها.
- يؤدي MCP وRAG مهمتين مختلفتين: يجيب RAG من المستندات، بينما يتيح MCP للوكيل الاستعلام والتصرّف داخل الأنظمة الحية.
MCP مقابل API: الجواب المختصر
واجهة API مكتوبة للمطوّرين. فهي تنشر نقاط نهاية، ويكتب المطوّر شيفرة تستدعيها بترتيب ثابت ولغرض معروف. ولا يستطيع وكيل الذكاء الاصطناعي استخدام واجهة API إلا عبر شيفرة كتبها أحدهم لهذا الوكيل تحديداً: تعريف دالة، وتدفّق مصادقة، ومعالجة للأخطاء، يُعاد بناؤها لكل أداة ذكاء اصطناعي تعتمدها.
أما MCP فمكتوب لعملاء الذكاء الاصطناعي. يصف خادم MCP أدواته، والبيانات التي يمكنه إرجاعها، والمدخلات التي تحتاجها كل أداة، بصيغة يستطيع أي عميل متوافق مع MCP قراءتها أثناء التشغيل: Claude وChatGPT وMicrosoft Copilot Studio ومساعدو البرمجة وأطر عمل الوكلاء. اربط الخادم مرة واحدة، وسيتمكّن كل عميل متوافق من اكتشاف ما يقدّمه. وقد قدّمت Anthropic بروتوكول MCP معياراً مفتوحاً في نوفمبر 2024، وفي ديسمبر 2025 نُقل إلى Agentic AI Foundation التابعة لـ Linux Foundation.
مثال على MCP مقابل API: مهمة واحدة بطريقتين
خذ طلباً واحداً: نقل صفقة في HubSpot إلى المرحلة التالية. عبر واجهة API، يكتب المطوّر شيفرة تسجّل الدخول، وتعثر على الصفقة، وتبحث عن معرّفات المراحل التي يستخدمها مسار المبيعات، ثم ترسل التحديث؛ ولا يملك المساعد إلا تشغيل تلك الشيفرة. وعبر MCP، يقرأ الوكيل المتصل بخادم HubSpot MCP قائمة الأدوات التي يقدّمها الخادم، ويختار الأداة التي تحدّث الصفقة، ويستدعيها مع الصفقة والمرحلة الجديدة. ويُجري الخادم استدعاء API نفسه في الخلفية، بهوية الشخص الذي أجرى الاتصال.
لماذا لا ندع النموذج يستدعي واجهة API مباشرة؟
يستطيع نموذج متمكّن أن يقرأ توثيق واجهة API أو مواصفات OpenAPI الخاصة بها ويكتب الاستدعاءات بنفسه، وهذا ينجح مع مطوّر واحد يجرّب شيئاً ما. أما في نظام أعمال، فالعمل المهم يحيط بالاستدعاء نفسه: تسجيل الدخول بهوية الشخص الصحيح، ورفض الإجراءات غير المسموح له بها، والالتزام بحدود معدّل الطلبات، وإرجاع أخطاء يستطيع الوكيل التصرّف بناءً عليها. يتولّى خادم MCP ذلك مرة واحدة، بشيفرة مُختبرة، بدلاً من ترك كل وكيل يرتجله مع كل طلب.
ما الذي يضيفه MCP فوق واجهة API، وما الذي لا يضيفه
يقدّم خادم MCP من الداخل ثلاثة أنواع من اللبنات الأساسية، مُعرَّفة في مواصفات MCP. الأدوات هي إجراءات يستطيع الوكيل استدعاءها، مثل البحث عن حساب أو إنشاء تذكرة. والموارد بيانات للقراءة فقط، مثل سجلّ أو مخطط قاعدة بيانات، يمرّرها التطبيق إلى النموذج سياقاً. والموجّهات تعليمات جاهزة يختارها المستخدم لبدء مهمة. ويعمل الخادم إما محلياً، على الجهاز نفسه الذي يعمل عليه عميل الذكاء الاصطناعي، أو عن بُعد عبر HTTP، حيث يخدم مستخدمين كثيرين ويوصي البروتوكول باستخدام OAuth لتسجيل الدخول.
نقطة لا تزال مقارنات كثيرة تخطئ فيها: MCP ليس بروتوكولاً يحتفظ بالحالة. فمنذ إصدار 2026-07-28 من البروتوكول، يحمل كل طلب إصدار البروتوكول والقدرات التي يحتاجها الخادم، فيعالج الخادم كل طلب بمفرده، تماماً كما تفعل واجهة REST API. أما الأوصاف التي تجعل MCP محتفظاً بالحالة وواجهات API عديمة الحالة فتشير إلى إصدارات سابقة.
يُغنيك MCP عن العمل المتكرّر. فبدونه، تحتاج كل أداة ذكاء اصطناعي تعتمدها شركتك إلى موصّل خاص بها لكل نظام. ومعه، يُبنى الموصّل مرة واحدة على شكل خادم MCP، وتتغيّر أدوات الذكاء الاصطناعي من حوله. كما يوحّد طريقة تسجيل دخول الوكيل: فخوادم MCP البعيدة تستخدم OAuth، فيتصرّف الوكيل بهوية شخص محدّد.
طريقة تصميم الأدوات أهم من عددها. فكل أداة يعرضها الخادم تُوصف للنموذج، وتلك الأوصاف تشغل السياق الذي يفكّر فيه النموذج؛ لذا فالخادم الذي يعكس كل نقطة نهاية في واجهة API يضع أمام الوكيل قائمة طويلة يختار منها، ويزيد فرص الاختيار الخاطئ. أما الخوادم الناجحة فتعرض مجموعة أصغر من الأدوات على مستوى إجراء عمل، مثل «تحديث حالة الطلب»، وتُجري استدعاءات نقاط النهاية خلف كل أداة.
ما لا يصلحه MCP هو كل ما يقع تحته. فإذا كان نظام CRM لديك مليئاً بالحسابات المكرّرة، فسيقرأ الوكيل التكرارات بسرعة أكبر فحسب. وإذا كانت واجهة API محدودة المعدّل، فسيرث خادم MCP هذا الحد. وإذا كانت قاعدة العمل التي تقرّر إن كان يمكن تعديل الطلب محفوظة في رأس أحدهم، فلن يعثر عليها أي بروتوكول. وإذا لم يكن لنظام ERP قديم أي واجهة API صالحة للاستخدام، فلا شيء يمكن لخادم MCP أن يغلّفه حتى يبني أحدهم واجهة. لهذا تكون مسألة الاتصال عادةً النصف الأصغر من أي مشروع لتكامل الذكاء الاصطناعي مع CRM؛ فالبيانات والقواعد تستغرق وقتاً أطول.
أين تقع منصات iPaaS
تدير شركات متوسطة الحجم كثيرة تكاملاتها عبر منصة iPaaS مثل MuleSoft أو Workato أو Boomi، وهذه المنصات تضيف دعماً لـ MCP. تحقّق مما تعرضه قبل أن تبني خططك عليها: فخادم MCP لإدارة منصة التكامل ليس كخادم يحوّل تكاملاتك إلى أدوات للوكلاء.
إذا كانت تكاملاتك موجودة أصلاً في منصة iPaaS، فابدأ منها: فمعالجة الأخطاء وإعادة المحاولات والمراقبة التي بناها فريقك لتلك التدفقات تنتقل معها. وإن لم تكن كذلك، فنادراً ما يستحق شراء منصة iPaaS لمجرد الوصول إلى MCP، لأن موردي أنظمة CRM وERP باتوا يوفّرون خوادم MCP خاصة بهم.
خوادم MCP التي يوفّرها نظاما CRM وERP لديك بالفعل
قبل أن يبني أحدٌ خادماً مخصّصاً، تحقّق مما يوفّره المورّد. إليك ما تقدّمه أربع منصات شائعة، كما وصفته وثائقها الرسمية عندما راجعناها في نوفمبر 2026.
Salesforce MCP
يأتي دعم Salesforce لـ MCP على شكل Salesforce Hosted MCP Servers، وهو تطبيق Salesforce للمعيار المتاح للجميع. تعمل الأدوات بصلاحيات المستخدم الذي أجرى المصادقة، وتنطبق أمان مستوى الحقول وصلاحيات الكائنات وقواعد المشاركة على كل استدعاء أداة. لا تزال بعض الخوادم القياسية في المرحلة التجريبية، والخوادم المستضافة مخصّصة للعملاء الذين لديهم Flex Credits، مع استخدام قد يُحتسب عليه رسوم، لذا تحقّق من الأمرين قبل أن تبني خططك على أحدها. وحيث تتوقف الخوادم القياسية، تتيح لك Salesforce إنشاء خوادم مخصّصة إلى جانبها؛ وبناء أحدها عمل من أعمال تطوير Salesforce، يخضع للاختبار ومراجعة الصلاحيات نفسيهما كأي تكامل مخصّص.
خادم HubSpot MCP
أصبح خادم HubSpot MCP البعيد متاحاً لجميع حسابات HubSpot في 13 أبريل 2026. فهو يقرأ سجلات CRM والمحتوى التسويقي والأنشطة، ويستطيع إنشاء وتحديث جهات الاتصال والشركات والصفقات والتذاكر وبنود الطلبات والمنتجات والأنشطة. أما عروض الأسعار والفواتير والطلبات فتبقى للقراءة فقط. تستخدم الاتصالات OAuth 2.1 مع PKCE، ويحترم كل إجراء صلاحيات المستخدم الحالية في HubSpot. وإذا كانت البيانات الحساسة مفعّلة في الحساب، تُحجب الأنشطة عن الخادم كلياً.
NetSuite MCP
تربط Oracle نظام NetSuite بعملاء الذكاء الاصطناعي عبر NetSuite AI Connector Service، الذي يعمل على MCP. ويخضع الوصول لصلاحيات الأدوار في NetSuite. يتيح تطبيق MCP Standard Tools SuiteApp للوكيل إنشاء السجلات وقراءتها وتحديثها، وتشغيل التقارير وعمليات البحث المحفوظة، والاستعلام باستخدام SuiteQL الذي يعمل للقراءة فقط. والخدمة نفسها ليست ميزة مدفوعة، وإن كان عميل الذكاء الاصطناعي الذي تربطه قد يكون كذلك.
خادم SAP MCP
دعم SAP موزّع على عدة منتجات بدلاً من خادم واحد. فالوكلاء المبنيون في Joule Studio يدعمون MCP وAgent2Agent، وتتضمن SAP Integration Suite بوابة MCP Gateway تعرض واجهات API وتدفقات التكامل الموجودة على شكل أدوات MCP. وتصف البنية المرجعية من SAP كيف تصل خوادم MCP من جهات خارجية إلى أنظمة SAP على BTP. وبالنسبة إلى معظم عملاء SAP، يعني ذلك أن الطريق إلى MCP يمر عبر طبقة التكامل الموجودة لديهم أصلاً. وإعداد هذا الطريق جزء من خدمات استشارات SAP لدينا.
ما المسموح للوكيل برؤيته
تتخذ جميع خوادم الموردين المذكورة أعلاه خيار التصميم نفسه: يتصرّف الوكيل بهوية الشخص الذي أجرى الاتصال، لا بهوية حساب خدمة مشترك. وهذا هو الإعداد الافتراضي الصحيح، ويستحق أن تحافظ عليه عندما تبني اتصالاتك الخاصة. فحساب التكامل ذو الصلاحيات الواسعة، إذا رُبط بمساعد ذكاء اصطناعي، يمنح كل موظف يستطيع محادثة المساعد صلاحيات ذلك الحساب.
وينطبق المبدأ نفسه على الاسترجاع. فالمساعد الذي يجيب من مستندات الشركة يجب ألا يرى إلا ما يُسمح للشخص السائل برؤيته. لشركة خدمات تقنية معلومات في المملكة المتحدة، بنينا منصة استرجاع على AWS تبحث عبر SharePoint وSalesforce وS3 في مكان واحد، وحقّقت تسريعاً بنسبة 60% في العمل مع مستندات الشركة. تُبقي المنصة الفهرس متزامناً مع كل نظام مصدر، وتطبّق صلاحيات الوصول الخاصة بكل مستخدم على كل إجابة. وهذا، لا البحث، هو الجزء الصعب في مشروع كهذا.
ولأمان MCP جانب على مستوى البروتوكول أيضاً: ما المسموح لكل أداة بفعله، وما المدخلات التي تقبلها، وكيف يمكن لأمر محقون في مستند أو رسالة بريد إلكتروني أن يدفع الوكيل إلى استدعاء أداة لا ينبغي له استدعاؤها. هذه المخاطر مكانها المراجعة نفسها التي يخضع لها أي نظام آخر يملك صلاحية الكتابة.
السماح للوكيل بالكتابة دون إفساد السجلات
القراءة هي الجزء السهل. أما السؤال الذي يطرحه كل مالك لنظام CRM أو ERP فهو: ماذا يحدث عندما يكتب الوكيل؟ وخيارات الموردين أنفسهم تشير إلى الجواب: ابدأ بنطاق ضيّق ووسّع الصلاحيات خطوة بخطوة.
- القراءة فقط أولاً. يجيب الوكيل عن الأسئلة ويصوغ التغييرات على شكل اقتراحات. فيرى الناس ما سيفعله قبل أن يفعل أي شيء.
- أدوات كتابة محدودة النطاق. بدلاً من أداة واحدة تستطيع تحديث أي حقل، امنح الوكيل أدوات لإجراءات محدّدة: تسجيل مكالمة، أو نقل مرحلة صفقة، أو إنشاء تذكرة.
- موافقة على التغييرات ذات الأثر. كل ما يتجاوز حداً متفقاً عليه، مثل سعر أو حد ائتماني أو عملية حذف، يُحال إلى شخص.
- إعادة محاولة آمنة. يجب ألا تُنشئ عملية كتابة أُعيدت بعد انتهاء المهلة سجلاً ثانياً. فكل إجراء يحمل مفتاحاً يجعل التكرار غير ضار.
- سجلّ لكل إجراء. ما قرأه الوكيل، وما غيّره، ونيابةً عن مَن.
- طريق للعودة. تُحفظ القيمة السابقة، بحيث يمكن التراجع عن تغيير خاطئ دون استعادة نسخة احتياطية.
لمقاول إنشاءات في الولايات المتحدة، يفرز وكيل الذكاء الاصطناعي للبريد الإلكتروني الذي بنيناه المستندات الواردة ويحفظها في Procore وSharePoint، وقد جعل استيعاب المستندات أسرع بنسبة 70–80%. والنمط الموضّح أعلاه هو ما يتيح لوكيل كهذا الكتابة في أنظمة تعتمد عليها الشركة، ومكانه الإصدار الأول من أي وكيل ذكاء اصطناعي، لا إصلاح يأتي بعد أول عملية كتابة خاطئة.
MCP مقابل RAG: مهمتان مختلفتان
المقارنة بين MCP وRAG ليست اختياراً بين بديلين. فالتوليد المعزّز بالاسترجاع (RAG) يعثر على المقاطع المناسبة في مستنداتك ويقدّمها للنموذج، فيستطيع الإجابة من معرفتك لا من بيانات تدريبه. أما MCP فيمنح الوكيل وصولاً إلى الأنظمة الحية، فيستطيع البحث عن سجلّ كما هو الآن والتصرّف بناءً عليه.
مساعد المبيعات يوضّح الفرق. «ما سياسة الخصم القياسية لدينا على التجديدات؟» سؤال من أسئلة RAG: فالجواب موجود في مستند سياسات. «أيٌّ من تجديداتي هذا الشهر يتجاوز ذلك الخصم؟» سؤال من أسئلة MCP: فالجواب موجود في نظام CRM. يحتاج معظم المساعدين المفيدين إلى الاثنين، وكلاهما يعتمد على الأساس نفسه: مسارات بيانات تُبقي المصادر محدّثة، وهي هندسة البيانات التي تقوم عليها أي منظومة ذكاء اصطناعي تجيب من بيانات الشركة.
متى تستخدم MCP أو API أو منصة iPaaS
نظام ERP قديم بلا واجهة API صالحة للاستخدام
أنظمة ERP القديمة هي الحالة الأصعب. فإذا كان النظام يتيح قاعدة بيانات دون واجهة API، فالمسار الأكثر أماناً هو نسخة قراءة متماثلة أو طبقة API صغيرة أمامه، مع تمرير عمليات الكتابة عبر طابور تعالجه منطق نظام ERP نفسه. ويمكن بعد ذلك تغليف هذه الطبقة على شكل خادم MCP كأي طبقة أخرى. أما أتمتة الشاشات عبر RPA فهي الملاذ الأخير: فهي تعمل، لكنها تتعطّل كلما تغيّرت الواجهة. وحيث يكون النظام نفسه هو عنق الزجاجة، قد يكلّف تحديث البرمجيات القديمة أقل على المدى الطويل من إبقاء غلاف حيّ حوله، لذا قارن بين الخيارين قبل الالتزام بأيٍّ منهما.
كيف تربط Crunch-IS وكلاء الذكاء الاصطناعي بنظامَي CRM وERP
معظم العمل في ربط وكلاء الذكاء الاصطناعي بنظام CRM أو ERP يقع تحت مستوى البروتوكول. تبدأ خدمات تكامل الذكاء الاصطناعي مع CRM لدينا بمراجعة نموذج البيانات، والسجلات المكرّرة والناقصة، واستخدام الحقول، وصلاحيات الوصول. ثم يعمل الوكلاء الذين نبنيهم تحت مستخدم CRM محدود النطاق، ويطبّقون صلاحيات الوصول الخاصة بكل شخص، ويسجّلون كل تغيير، بحيث يمكن تتبّع أي تحديث والتراجع عنه. ويبدؤون باقتراح التحديثات ليوافق عليها شخص، ولا تعمل أي خطوة بمفردها إلا بعد أن ينخفض معدّل أخطائها بما يكفي.
أما على جانب ERP، فكثيراً ما يكون الأساس طبقة API غير موجودة بعد. لشركة معدّات طاقة في المملكة المتحدة كانت خطوط أعمالها تعمل على Microsoft Dynamics 365 وSAP Business One وجداول البيانات، بنينا طبقة API مركزية ومنصة بيانات تزامن بينها جميعاً في الوقت الفعلي: وهو الأساس الذي يحتاجه الوكيل، أو خادم MCP، تحته. وتغطي خدمات تطوير ERP لدينا العمل نفسه لأنظمة SAP وNetSuite وOdoo.
ويُعدّ MCP أيضاً جزءاً من طريقة تنفيذنا للمشاريع. ففي تطبيق تصنيع متكامل مع SAP بناه فريق AI Pod، شغّل الفريق سير عمله الهندسي على MCP ومكتبات موجّهات قابلة لإعادة الاستخدام ووكلاء فرعيين متخصّصين، وأطلق المنتج الأولي (MVP) أسرع بنسبة 63% بفريق تنفيذ أصغر بنسبة 56%.
الخلاصة
لمسألة MCP مقابل API جواب أبسط مما توحي به الاختصارات. فـ MCP هو الطبقة التي تتيح لأي وكيل ذكاء اصطناعي العثور على ما تستطيع أنظمتك فعله واستخدامه؛ أما واجهات API تحته فلا تزال تؤدي العمل. ابدأ بخادم MCP الذي يوفّره مورّد نظام CRM أو ERP لديك، وأضف خادماً مخصّصاً فوق واجهة API حيث يحتاج الوكيل إلى منطق لا يعرضه المورّد، واحتفظ بمنصة iPaaS التي تدير تكاملاتك أصلاً.
نادراً ما يكون الاتصال هو ما يعيق المشروع. فالسجلات النظيفة، وقواعد العمل التي دوّنها أحدهم، وصلاحيات الكتابة التي تتّسع خطوة بخطوة، هي ما يحدّد إن كان يمكن الوثوق بوكيل داخل نظامَي CRM وERP لديك، وتستحق الثلاثة أن تُحسم قبل أن يبدأ أول وكيل العمل فعلياً.
