Headless MCP في Salesforce: كيف تتبنى Headless 360 وتحسب العائد

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

ما هو headless MCP على Salesforce؟

Model Context Protocol معيار مفتوح بيخلّي نموذج الذكاء الاصطناعي يكتشف الأدوات والـ APIs والبيانات الخارجية ويستدعيها وقت التشغيل، فأي عميل متوافق يقدر يتكلم مع أي خادم متوافق من غير كود ربط مخصص. و"Headless" معناها إن مفيش شاشة في المنتصف: الشغل بيمشي عبر طبقة الـ API والوكيل بدل النقر في واجهة Lightning. مع بعض، إعداد headless MCP بيسمح لـ Claude أو Cursor أو Agentforce أو أي عميل متوافق مع MCP بقراءة السجلات وتشغيل الاستعلامات وتنفيذ عمليات الإعداد باستدعاء أدوات Salesforce مباشرة. الشخص بيحدد النية، والوكيل بيلاقي العملية الصحيحة وينفّذها.

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

ما هو Salesforce Headless 360؟

Salesforce قدّمت Headless 360 في TDX في أبريل 2026 كمبادرة لإتاحة كل إمكانية في المنصة كـ API أو أداة MCP أو أمر CLI، عشان المتصفح يبقى اختياريًا مش إجباريًا. وبحسب مدونة Salesforce Developers، بتغطّي أكتر من 60 أداة MCP، وأكتر من 30 مهارة برمجية، وأكتر من 4,000 API موجودة، وأكتر من 220 أمر CLI.

فرّق بين طبقتين، لأن الاتنين شايلين اسم Headless 360:

• خوادم MCP المستضافة القياسية بتتولّى شغل البيانات: SObject All و Reads و Mutations و Deletes، بالإضافة إلى Data 360 و Tableau Next. متاحة بشكل عام من أبريل 2026.
• Headless 360 MCP Server بيختصر شغل الإعداد والتكامل في أربع أدوات. في البيتا من يوليو 2026.

كيف يعمل Headless 360 MCP Server؟

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

• Discover - بحث دلالي في فهرس متجهي للـ APIs والمهارات، بيرجّع مرشحين مرتّبين للطلب.
• Describe - المواصفات التقنية للمهارة المختارة: المعاملات، والاعتماديات، والخطوات بالترتيب.
• Dispatch - بيستدعي مهارة، مع فرض التحكم في الوصول.
• Dispatch Read Only - بيشغّل عمليات القراءة فقط.

حلقة discover-describe-dispatch بتخلّي سياق النموذج صغيرًا بينما الكتالوج وراها بيكبر. البيتا انطلقت بحوالي 100 مهارة، مع آلاف مخطط لها.

ماذا يقدر headless MCP أن يفعل في Salesforce اليوم؟

عند الإطلاق، Headless 360 MCP Server بيغطّي:

• إدارة المستخدمين، بما فيها إنشاء المستخدمين وإلغاء تفعيلهم، وإعادة تعيين كلمات المرور، وإسناد الصلاحيات.
• تطوير Apex triggers.
• التكاملات المعتمدة على الأحداث عبر Change Data Capture و platform events و event relays.
• إعداد named credentials.

وخارج الإعداد، خوادم البيانات المستضافة بتخلّي الوكيل يعرض العملاء المحتملين ويشغّل SOQL ويحدّث الحقول بلغة طبيعية، و سطح MCP في Data 360 بيتيح أكتر من 200 API عشان الوكيل يبني البيانات الموحّدة ويربطها ويستعلم عنها بطلبات بلغة عادية. ونفس النمط بيمتد للأنظمة اللي حوالين Salesforce: تكامل هاتفي بيزامن سجلات المكالمات مع السجلات، أو محادثة WhatsApp، بيتحوّل لمجموعة إضافية من الإجراءات المحكومة اللي الوكيل بيشغّلها، مع بقاء Salesforce هو نظام السجل الرئيسي. بدل موصّل مخصص لكل سطح ذكاء اصطناعي، بتتيح خادمًا واحدًا محكومًا وأي عميل بيفهم MCP بيوصل له.

Salesforce وسّعت Headless 360 تاني في 19 أغسطس 2026، وضافت عميل Slackbot MCP جنب خادم Data 360 وأكتر من 100 مهارة إضافية للوكيل، ونفس التحوّل ده بيظهر في سوق أدوات DevOps كمان: Agentia بتاعة Copado ضافت وضع headless MCP خاص بيها في سبتمبر 2026. احسب حساب البيتا مش الإتاحة العامة وانت بتقيّم: Headless 360 MCP Server نفسه لسه في مرحلة البيتا وقت كتابة المقال ده، حتى مع إن أجزاء جنبه زي Data 360 وعميل Slackbot بتتحرك أسرع.

هل headless MCP آمن؟

الوكيل اللي يقدر ينشئ مستخدمين وينشر Apex خطير بالظبط بقدر الصلاحيات اللي وراه، فده السؤال اللي بيفرق. الجزء المطمئن إن Headless 360 مش بيخترع نموذج ثقة جديد؛ هو بيركب على النموذج اللي Salesforce بتفرضه أصلًا. كل معاملة بتتنفّذ كمستخدم موثّق، محدودة عبر external client app بنطاق mcp_api و OAuth 2.0 مع PKCE، وكل إجراء محاط بأربع طبقات:

• الهوية - الوكيل بيتصرف كمستخدم موثّق، وعمره ما يتخطاه.
• الوصول - الـ profiles و permission sets و org-wide defaults وقواعد المشاركة وأمان مستوى الحقل كلها لسه سارية.
• نطاق الاستدعاء - المهارات المتاحة صراحةً بس هي اللي ممكن تتستدعى.
• الحوكمة - قواعد التحقق و transaction security policies وسلاسل الموافقة و governor limits كلها لسه بتشتغل.

النموذج بيوفّر الذكاء. والمنصة بتوفّر الهوية والوصول والإمكانيات والحوكمة، وهو السياق اللي بيخلّي الذكاء مفيدًا.

لو الشخص مش قادر يعمل حاجة في Salesforce، وكيله مش هيقدر يعملها عبر MCP برضه. Salesforce كمان بتسلّم الخوادم القياسية متعطّلة، وبتفصل القراءة والإنشاء/التحديث والحذف في خوادم مختلفة، فعمرك ما هتمنح الحذف بالغلط. فعّله عن قصد، لأن "احذف كل العملاء المحتملين" بيبقى على بعد أمر واحد أول ما تعمل كده. الوصول الأساسي لـ MCP المستضاف محتاج Enterprise Edition أو أعلى ومش مقفول ورا ترخيص Agentforce.

كيف تتبنّى headless MCP بأمان في الإنتاج؟

العروض التجريبية سهلة. الإنتاج هو اللي الفرق بتتحرق فيه. القواعد اللي بنطبّقها في Tekunda في كل إطلاق:

• ابدأ بالقراءة فقط. ادّي الوكلاء Dispatch Read Only أو خادم SObject Reads قبل ما أي مسار كتابة يشتغل.
• حدّد permission set مخصصًا. الوكيل بيرث صلاحيات مستخدمه، فادّيه مستخدمًا خاصًا به بأقل الصلاحيات، مش تسجيل دخول أدمن.
• اطلب موافقة على الكتابة. خلّي وضع الصلاحيات في العميل على "يحتاج موافقة" للإنشاء والتحديث والحذف لحد ما تثق في التدفق.
• سجّل كل dispatch. دوّن أي مهارة اشتغلت، وباسم مين، وعلى أي سجلات، عشان إجراء الوكيل يبقى قابلًا للتدقيق زي الإجراء البشري.
• جرّب في sandbox. عمرك ما تخلّي مهارة جديدة تلمس بيانات الإنتاج في أول تشغيل لها.

الأمان اللي Salesforce بتفرضه أرضية، مش استراتيجية. الخطر مش في البروتوكول؛ الخطر في الصلاحيات الواسعة زيادة عن اللزوم على المستخدم المتصل، والوكيل اللي بيتصرف باسم المستخدم ده لسه يقدر يعمل ضررًا واسعًا وبسرعة. لو بتربط كذا وكيل مع بعض، أو عايز سطح إجراءات واحدًا يغطّي Salesforce والـ ERP والهاتف والأجهزة اللي حواليه، تصميم التسليم بين الوكلاء بيفرق بقدر الصلاحيات - شوف تنفيذ إجراءات CRM من مركز وكلاء واحد و إيه اللي بيخلّي التسليم بين الوكلاء يشتغل في الإنتاج. ولما تحب الإطلاق ده يتصمّم ويتحكم صح، فريق خدمات Salesforce عندنا بيعمل الشغل ده بالظبط.

ما الذي يجب أن تتضمنه قائمة مراجعة الأمان للتطبيقات المتصلة بـ MCP؟

لو بتحزّم برمجيات لـ AppExchange، إتاحة الإمكانيات عبر MCP مش بتعفيك من مراجعة أمان AppExchange؛ بالعكس بترفع الرهان. نسختنا المختصرة، من تجربتنا في عبور المراجعة بنفسنا:

1. افرض CRUD و FLS والمشاركة في كل نقطة دخول Apex الوكيل يقدر يوصل لها، مش الواجهة بس.
2. اقضِ على حقن SOQL بمتغيرات الربط، ومطلقًا مش SOQL ديناميكي مبني من نصوص.
3. شفّر البيانات أثناء النقل بـ TLS 1.2 أو أعلى، وفي حالة السكون بـ AES-256.
4. حدّد named credentials و connected apps على الحد الأدنى، وأثبت ده.
5. اضبط security headers وأعلام الكوكيز (X-Content-Type-Options و X-Frame-Options و Strict-Transport-Security و Secure و HttpOnly).
6. افحص قبل التقديم بـ Salesforce Code Analyzer بالإضافة إلى ماسح زي Checkmarx أو OWASP ZAP أو Burp Suite، ووثّق كل نتيجة إيجابية خاطئة.
7. وثّق تخزين البيانات والمصادقة وكل تكامل خارجي الوكيل بيستخدمه.

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

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

كيف تحسب العائد على الاستثمار لإطلاق headless MCP؟

احسبه قبل ما تبني. Salesforce بتنشر حاسبة عائد Agentforce اللي بتتوقع توفير التكاليف والكفاءة على مدى تلات سنين وبتقدّر الـ Flex Credits اللي حالة الاستخدام هتستهلكها، وهي وحدة الاستهلاك اللي Salesforce بتحاسب بيها على استخدام الوكلاء. هي نقطة بداية معقولة، لكنها شغالة على افتراضات عامة، والنموذج اللي تقدر تدافع عنه بيستخدم أرقامك إنت.

ثبّته بإطار بسيط، كله موحّد على رقم شهري: (الساعات الموفّرة لكل عملية x الحجم الشهري x التكلفة الكاملة للساعة) - (الإنفاق الشهري على Flex Credits + تكلفة البناء موزّعة على فترة الاسترداد + الحوكمة الشهرية). حوّل الـ Flex Credits لتكلفتها بالعملة عشان كل حد يبقى فلوس في الشهر. Headless MCP بيحرّك جانب "الساعات الموفّرة" أكتر حاجة في مهام الإعداد والبيانات المتكررة متعددة الخطوات، الشغل اللي كان بيعني عشرات النقرات عبر كذا شاشة، لأنه بيشيل ضريبة الواجهة: الشغل اللي عمره ما كان محتاج شاشة بقى بيتنفّذ كاستدعاء مباشر. ونفس الحسبة بتنطبق على وكلاء الصوت بالذكاء الاصطناعي على تكامل هاتفي: اعمل نموذجًا للدقايق اللي اتحوّلت وساعات الموظفين اللي اتحرّرت حسب الحجم ووقت المعالجة والـ Flex Credits اللي كل تفاعل آلي بيستهلكها.

أين مكان شريك Salesforce PDO أو شريك Agentforce؟

تبنّي headless MCP بأمان مشروع حوكمة بقدر ما هو مشروع بناء. الـ Salesforce PDO (Product Development Outsourcer) بيبني تطبيقات تجارية على المنصة، وبيحزّمها صح، وبيعدّيها من مراجعة أمان AppExchange. المهارات دي بتنطبق مباشرة على headless MCP: الـ ISV اللي بيتيح منتجه كأدوات MCP محتاج حد يقدر يصمّم سطح الأدوات، ويفرض نموذج المستخدم المشغّل، ويعدّي المراجعة من أول مرة. وشريك Agentforce بيعمل نفس الحاجة لوكيل داخلي، بربط الأدوات الأربع بمنطق أعمال حقيقي مش عرض تجريبي. ولما تقيّم أي منهما، وازن تلات حاجات:

1. هل بيصمّموا نموذج الصلاحيات الأول، ولا بيركّبوه بعد ما العرض التجريبي يشتغل؟
2. هل يقدروا يورّوك شغل وكلاء حقيقي بلا واجهة على مؤسسة محكومة، مش شرائح عرض؟
3. هل بيتولّوا التكامل والتحزيم ومراجعة الأمان، ولا بيسيبوك في نص الطريق؟

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

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

هل headless MCP هو نفسه Agentforce؟

لا. Agentforce هو منتج الوكلاء من Salesforce؛ و headless MCP (Headless 360) هو سطح الأدوات اللي الوكيل بيستدعيه. تقدر تشغّله من Agentforce أو من عميل خارجي زي Claude أو Cursor.

هل Headless 360 MCP Server متاح بشكل عام؟

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

هل الوكيل اللي بيستخدم headless MCP بيتخطى أمان Salesforce؟

لا. بيتنفّذ كمستخدم موثّق بنطاق mcp_api، و CRUD وأمان مستوى الحقل وقواعد المشاركة و permission sets كلها بتتفرض. ادّي الوكيل مستخدمًا بأقل الصلاحيات.

هل محتاج ترخيص Agentforce عشان أستخدم headless MCP؟

الوصول الأساسي لـ MCP المستضاف محتاج Enterprise Edition أو أعلى ومش مشروط بترخيص Agentforce، مع إن شروط المحاسبة ممكن تتغير بإشعار مسبق.

هل محتاج مراجعة أمان منفصلة لتطبيق متصل بـ MCP؟

حزم AppExchange لسه بتمر بمراجعة الأمان القياسية. MCP مش بيضيف عملية منفصلة، لكنه بيوسّع السطح، فلازم CRUD و FLS والمشاركة والوصول بأقل الصلاحيات يصمدوا عند كل نقطة دخول.

هل محتاجين كود عشان نتبنّاه؟

مش للاستخدام الأساسي. بتفعّل خادم MCP المستضاف من Setup وتوصّل عميلًا متوافقًا مع MCP. حوكمة الإنتاج هي المكان اللي التخطيط بيدفع فيه ثمنه.

نبدأ منين؟

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

Headless MCP هو الطريق اللي الشغل المدفوع بالوكلاء بيوصل بيه لـ Salesforce، وهو في البيتا فعلًا. لو عايز السطح ده يتحرك بسرعة من غير ما توسّع سطح الهجوم عندك، ده شغل البناء والأمان اللي Tekunda بتعمله كل يوم. احجز مكالمة تحديد نطاق قصيرة.