كيف تُعِدّ خادم MCP لـ Salesforce داخل سير عمل الـ DevOps

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

ما هو خادم MCP لـ Salesforce؟

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

وهذا التأطير مهم في الـ DevOps: الخادم هو حدود سياستك. وكل ما تعرضه سيحاول النموذج استخدامه يومًا ما.

أي خادم MCP لـ Salesforce تختار؟

Salesforce DX MCP Server. يعمل محليًا ببيانات اعتماد سبق أن صرّحت بها عبر Salesforce CLI. الأنسب للمطوّرين في أعمال البيانات الوصفية والبيانات والاختبارات. الحزمة: @salesforce/mcp.
خوادم MCP المستضافة من Salesforce. نقاط نهاية سحابية عبر OAuth لمن لا يريد تثبيت سطر الأوامر. راجع إعلان Salesforce عن دعم MCP للاطلاع على المنظومة كاملة، بما فيها خوادم Heroku وMuleSoft.
خادم MCP الخاص بمنصة الـ DevOps عندك. هذا هو المهم في أعمال الإصدار، لأن النشر يعيش هناك لا داخل البيئة. خادم Serpent الأصلي يعرض إجراءات خط الإنتاج مثل plan_deploy وcreate_pull_request وresolve_metadata_conflict وtrigger_pipeline لعملاء Claude وCursor وWindsurf وCodex وCline وGitHub Copilot وAgentforce.

معظم الفرق تنتهي بتشغيل خادمين: واحد لعمل البيئات وآخر لعمل الإصدار، لأنهما يجيبان أسئلة مختلفة.

كيف تُعِدّ خادم Salesforce DX MCP؟

صرّح بالبيئات أولًا. شغّل sf org login web لكل بيئة. لا يصل خادم MCP إلا إلى بيئات يعرفها سطر الأوامر بالفعل، وهذه أول ضوابطك وأرخصها.
أضف الخادم إلى إعدادات عميلك. أبسط مدخل يبدو هكذا: {"mcpServers":{"Salesforce DX":{"command":"npx","args":["-y","@salesforce/mcp","--orgs","DEFAULT_TARGET_ORG","--toolsets","orgs,metadata,data"]}}}
حدّد نطاق البيئات صراحةً. الوسيط --orgs إلزامي، ويقبل DEFAULT_TARGET_ORG وDEFAULT_TARGET_DEV_HUB وأسماء مستخدمين أو ألقابًا صريحة، إضافة إلى ALLOW_ALL_ORGS. وتوثيق Salesforce نفسه يشير إلى القيمة الأخيرة بأنها تحتاج حذرًا، فخذ بالتنبيه.
ضيّق مجموعات الأدوات. الوسيط --toolsets يختار مجموعات وظيفية بدل تحميل كل شيء. هناك أكثر من خمس عشرة مجموعة، منها orgs وmetadata وdata وusers وtesting وdevops وcode-analysis. تفعيل all ممكن لكنه غير مستحسن، لأن كل أداة تُحمَّل تستهلك سياقًا كان النموذج سيستخدمه في التفكير.
اترك الأدوات غير المعتمدة عمومًا مغلقة. الأدوات موسومة بـ GA أو غير GA، والأخيرة تحتاج --allow-non-ga-tools. لا تفعّل هذا الوسيط في مستودع يستنسخه غيرك.

كيف ينبغي أن تعمل المصادقة؟

الخوادم المحلية ترث بيانات اعتماد سطر الأوامر، وهذا مريح ويعني أن نطاق تأثير الوكيل يساوي نطاق المطوّر. أما الخوادم المستضافة فتستخدم OAuth مع PKCE عبر External Client App، وهو النموذج الصحيح حين تريد هوية منفصلة بصلاحيات خاصة بها.

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

أي الإجراءات يجب أن تبقى خلف موافقة بشرية؟

هذا ما يستحق النقاش داخل فريقك، لا النقل من مدونة. وإليك حدًا أساسيًا صالحًا للعمل:

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

والنقطة التصميمية الأهم أن الموافقة يجب أن تعيش داخل الخادم لا داخل التوجيه النصي. فالنموذج الذي يُطلب منه أن يسأل أولًا سيسأل في الغالب الأعم، و"الغالب الأعم" ليس ضابطًا. خادم Serpent يشغّل فحوصًا قبلية ويشترط موافقة بشرية قبل تنفيذ أي نشر، فتصبح الحدود مفروضة من المنصة لا من حسن النية.

كيف يبدو هذا داخل خط إنتاج حقيقي؟

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

ابدأ بمستودع واحد وبيئة اختبار واحدة، ولا توسّع مجموعات الأدوات إلا حين تفشل مهمة حقيقية لغياب أداة. وتجد في أدلة Salesforce DevOps تفصيلًا أوسع لجانب خط الإنتاج.

FAQ

هل أحتاج Salesforce CLI لاستخدام MCP؟

نعم لخادم Salesforce DX المحلي، لأنه يستخدم بيانات اعتماد سطر الأوامر. أما الخوادم المستضافة فتعتمد على OAuth ولا تحتاج تثبيتًا محليًا.

هل يستطيع خادم MCP النشر إلى الإنتاج؟

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

أي مجموعات الأدوات أفعّل أولًا؟

ابدأ بـ orgs وmetadata وdata، ثم أضف testing حين تريد للوكيل تشغيل اختبارات Apex، وأضف أدوات الـ devops بعدما تثق بالدورة المقتصرة على القراءة.

هل MCP مناسب للبيئات الخاضعة للتنظيم؟

يمكن أن يكون كذلك إن كانت للوكيل هوية خاصة وصلاحيات بالحد الأدنى وسجل تدقيق وبوابة بشرية على عمليات الكتابة. عامله كأي مستخدم تكامل آخر، فهذا ما هو عليه.