MCP 2026-07-28: ماذا يعني البروتوكول عديم الحالة لنشر وكلاء B2B

لماذا يُغيّر هذا الإصدار حسابات النشر

Model Context Protocol (MCP) معيار مفتوح لربط وكلاء الذكاء الاصطناعي بالأنظمة الخارجية. في 28 يوليو 2026 يُصدِر أكبر مراجعة منذ الإطلاق — المواصفات النهائية يجعل طبقة البروتوكول عديمة الحالة، ويُقدّم امتدادات من الدرجة الأولى، ويُلغي ثلاث ميزات أضافت تعقيدًا دون أن تُبرّر وجودها في الإنتاج.

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

طبقة البروتوكول عديمة الحالة

التغيير الرئيسي: تُزال مصافحة initialize / initialized وترويسة Mcp-Session-Id. أصبحت الطلبات مكتملة بذاتها. تنتقل نسخة البروتوكول، ومعلومات العميل، والقدرات في _meta مع كل طلب، لا في جلسة تفاوضية يجب أن يتذكرها الخادم.

ما يُلغيه هذا في نشر B2B:

• موازنات الحمل للجلسات اللاصقة. يمكن لخوادم MCP البعيدة أن تعمل خلف موازنات حمل بسيطة بنظام round-robin. يستطيع أي مثيل خادم معالجة أي طلب لأنه لا تُتطلب حالة من جانب الخادم لتفسيره.
• مخازن الجلسات المشتركة. إذا توسّعت أفقيًا اليوم، يحتاج كل مثيل خادم MCP إلى الوصول إلى حالة الجلسة ذاتها — عادةً Redis أو قاعدة بيانات. يُزيل البروتوكول عديم الحالة هذه التبعية.
• بنية تحتية لإعادة تشغيل الجلسة. عندما تسقط جلسة وسط تدفق عمل، يجب على العميل إعادة التهيئة وإعادة تأسيس السياق. البروتوكول عديم الحالة لا توجد لديه جلسة تسقط؛ كل طلب يحمل ما يحتاجه.

تصبح بنية النشر أبسط: مجموعة من مثيلات خوادم MCP عديمة الحالة خلف موازن حمل، دون طبقة حالة مشتركة بينها. هذا هو الشكل ذاته لأي API HTTP عديم الحالة — مُختبَر في المعارك، وقابل للمراقبة، ورخيص التوسع.

نمط المقبض الصريح لتدفقات العمل ذات الحالة

عديم الحالة لا يعني اختفاء الحالة. التدفقات التي تمتد عبر استدعاءات أدوات متعددة — استقبال RFQ، والتفاوض على عرض سعر، وحجز توفّر — لا تزال تحتاج إلى استمرارية. يستبدل المواصفات النهائية حالة الجلسة المخفية بـ نمط المقبض الصريح: تُنشئ أداة مقبضًا (order_id، أو quote_id، أو basket_id) ويُمرّره النموذج كوسيطة عادية في الاستدعاءات اللاحقة.

هذا تحوّل ذو مغزى لنشر B2B لثلاثة أسباب.

الحالة مرئية للنموذج. اليوم، تعيش حالة الجلسة في بيانات النقل الوصفية التي لا يراها النموذج اللغوي أبدًا. مع المقابض الصريحة، يحمل النموذج المقبض ويُشير إليه في تفكيره. عندما يستدعي النموذج get_quote(quote_id="q-7f3a")، فإنه يعرف أي عرض سعر يُعامله. يُحسّن ذلك دقة اختيار الأدوات في تدفقات العمل متعددة الخطوات.

الحالة قابلة للتدقيق في السجلات. كل طلب يحمل مقبضه في متن الطلب، لا في ترويسة يُزيلها مسجّل التطبيق. يستطيع مسار التدقيق إعادة بناء حالة تدفق العمل الكاملة في أي نقطة بقراءة وسائط الطلب — دون الحاجة إلى المطابقة مع سجلات مخزن الجلسات.

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

كيف يُرسم هذا إلى تدفق عمل RFQ

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

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

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

الامتدادات: من الدرجة الأولى ومُنسّقة بشكل مستقل

يُقدّم المواصفات النهائية الامتدادات كمفهوم من الدرجة الأولى. تحصل الامتدادات على مُعرّفات DNS عكسية (مثلًا com.example.workflow)، وتمتلك مستودعات ext-* خاصة بها، ولها مُشرفون مُفوّضون، وتُنسّخ بشكل مستقل عن البروتوكول الأساسي.

الامتدادان الأوّلان ملموسان:

• MCP Apps — واجهات HTML يُولّدها الخادم تُسلَّم في iframe معزول. يستطيع خادم MCP أن يُسلّم واجهة يعرضها العميل، ما يُتيح سطوح موافقة بشرية في الحلقة دون أن يبني العميل واجهة أمامية مخصصة.
• Tasks — أعمال طويلة التشغيل بمقابض مهام. تستطيع أداة أن تُعيد مقبض مهمة فورًا ويستطلع العميل اكتمالها، بدلًا من إبقاء الاتصال مفتوحًا لدقائق.

بالنسبة لنشر B2B، تهم MCP Apps حيث يجب أن يوافق إنسان على معاملة قبل أن يُكمل الوكيل — أمر شراء فوق حدّ، أو عرض سعر بخصم غير قياسي. يمكن أن يُسلَّم سطح الموافقة مع وحدة MCP بدلًا من طلب واجهة أمامية منفصلة. وتهم Tasks للتدفقات التي تتجاوز مهلة طلب واحد: عرض سعر مورّد يستغرق 90 ثانية لتوليده، أو مزامنة كتالوج تستغرق دقائق.

الإلغاءات: Roots وSampling وLogging

ثلاث ميزات مُلغاة (تُترك للتعليقات فقط لمدة 12 شهرًا؛ الإزالة تتطلب عملية معايير منفصلة):

• Roots ← استُبدلت بوسائط الأدوات و URIs للموارد. كانت Roots طريقة يُخبر بها العملاء الخوادم بمواضع نظام الملفات؛ يُعبَّر عن القصد ذاته الآن كوسائط لأدوات تقرأ الملفات.
• Sampling ← استُبدل بالتكامل المباشر مع مزوّد LLM. الخوادم التي تحتاج استدعاءات LLM تُجرئها مباشرة إلى المزوّد، بدلًا من طلب العميل إجراء ذهاب-وإياع sampling.
• Logging ← استُبدل بـ stderr و OpenTelemetry. ينتقل تسجيل الخادم إلى المخرجات القياسية للعملية والتتبّع الموزّع، لا إلى قناة تسجيل MCP.

إلغاء Logging هو الأكثر صلة بنشر B2B. نمط تسجيل التدقيق — حيث يُسجَّل كل استدعاء أداة مع الطلب والاستجابة والكمون والنتيجة — يتماشى الآن مع OpenTelemetry بدلًا من قناة تسجيل خاصة بالبروتوكول. يعني هذا أن سجلات خادم MCP تتكامل مع خطوط أنابيب المراقبة القائمة (Datadog، وCloudWatch، وHoneycomb) دون نقل مخصص.

قابل للتوجيه والتخزين المؤقت والتتبّع

ثلاث إضافات تؤثر على عمليات الإنتاج:

• ترويسات Mcp-Method و Mcp-Name تُتيح توجيه البوابات دون فحص المتن. تستطيع بوابة التوجيه حسب الطريقة واسم الأداة على مستوى الترويسة — دون تحليل JSON في طبقة التوجيه.
• ttlMs و cacheScope على نتائج القائمة/الموارد تمنح الوسطاء عقد تخزين مؤقت قياسي. تستطيع استجابة قائمة كتالوج أن تُعلن TTL مدته 5 دقائق، وأي بوابة في المسار تستطيع احترامه.
• انتشار W3C Trace Context موثّق لتوافق OpenTelemetry. ينتشر التتبّع الذي يبدأه عميل الوكيل عبر خادم MCP إلى استدعاءات النظام العلوي، فيظهر تدفق عمل RFQ واحد كتتبّع واحد عبر كل نظام يلامسه.

بالنسبة لنشر B2B يُشغّل خوادم MCP لـ NetSuite وHubSpot وكتالوج مورّد، يعني هذا: تستطيع بوابة التوجيه حسب اسم الأداة دون تحليل المتن، وتخزين استجابات الكتالوج مؤقتًا لـ TTL مُعلن، وتتبّع طلب عرض سعر واحد من الوكيل إلى ERP إلى API المورّد في شجرة spans واحدة.

تعزيز التفويض للشكل واحد-إلى-متعدد

يُحسّن المواصفات النهائية OAuth و OpenID Connect لشكل النشر الذي تستخدمه أنظمة وكلاء B2B فعلًا: عميل واحد (الوكيل) يتصل بخوادم متعددة (NetSuite، وHubSpot، وBigCommerce، وكتالوج مورّد). تُعالَج إعادة تحميل الرموز، وإدارة النطاقات، ومعالجة بيانات اعتماد الخوادم المتعددة في المواصفات بدلًا من تركها لكل تكامل يحلّها بشكل مستقل.

يهم هذا لأن أنظمة وكلاء B2B لا تتصل بنظام واحد. يربط وكيل RFQ نموذجيًا بـ ERP (NetSuite)، و CRM (HubSpot)، ومنصة تجارة إلكترونية (BigCommerce)، وكتالوجين أو ثلاثة لمورّدين — لكل منها تدفق OAuth خاص به، وعمر رمز، ومجموعة نطاقات. يُقدّم البروتوكول الآن نمطًا قياسيًا لإدارة هذا التعقيد، بدلًا من أن تُطبّق كل وحدة MCP دورة حياة بيانات اعتماد خاصة بها.

Update — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — the stateless thesis validated in production

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server before version 1.1.0 — the first maximum-severity CVE in the MCP ecosystem. The vulnerability is an authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity — and it validates the core thesis of this article. The stateless protocol layer the July 28 final specification introduced exists precisely to eliminate the server-side session state that this attack exploits. The attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. The explicit-handle pattern this article describes — where stateful workflows mint handles that travel in the request body, not in a server-side session — is the architecture that closes this vulnerability class. The vulnerability affects only the stateful streamable-HTTP transport mode; the stateless protocol core is not affected.

For B2B deployments, the implication is direct: if your MCP servers run stateful streamable-HTTP with Mcp-Session-Id, they carry the session-hijacking attack surface that CVE-2026-16496 exploits. Migrating to the stateless protocol core (Control 1 in the MCP Security Hardening Checklist) eliminates the attack surface at the architecture level, not the patch level. The 12-month SSE deprecation window is now a security deadline, not just an operational one.

الأمان: ثلاث أسطح هجوم جديدة ونقطة بيانات للدفاع متعمق

أدخل التصميم عديم الحالة ثلاثة أسطح هجوم جديدة حدّدها backslash.security في تحليلهم الصادر في نفس يوم المواصفات النهائية:

• اختطاف المقابض. المقابض الصريحة تحل محل حالة الجلسة من جانب الخادم، لكن المقبض وسيطة عادية. إذا كان فضاء المقابض قابلاً للتنبؤ أو كان النقل يفتقر إلى حماية التكامل، فإن المهاجم الذي يلاحظ أو يخمّن مقبضًا يمكنه حقنه في طلباته الخاصة — منتحلًا هوية مالك تدفق العمل. الحل هو التوليد التشفيري للمقابض (عشوائية، غير قابلة للتخمين) وربط المقابض بالمُتصِّل المُصدَّق عليه، وليس فقط بمتن الطلب.
• فجوة نطاق نظام الملفات. إلغاء Roots يُزيل إعلان حدّ نظام الملفات من جانب العميل. الأدوات التي تقرأ الملفات تتلقى الآن المسارات كوسائط، لكن بدون حد Roots، قد تصل الأداة إلى مواقع في نظام الملفات لم يكن العميل ينوي كشفها أبدًا. الحل هو التحقق من المسار لكل أداة مقابل قائمة سماح صريحة، وليس الاعتماد على حد بمستوى البروتوكول لم يعد موجودًا.
• عرض HTML لـ MCP Apps. امتداد MCP Apps يتيح للخوادم تسليم واجهات HTML في iframes معزولة. العزل هو حد أمني، لكن محتوى HTML يأتي من الخادم — خادم MCP مخترق أو خبيث يمكنه تسليم واجهة تحاول الهروب من العزل أو تصيّد المستخدم. الحل هو معاملة HTML لـ MCP Apps كمحتوى غير موثوق: سياسة أمان محتوى (CSP) صارمة، لا وصول same-origin، وتأكيد المستخدم قبل عرض أسطح التطبيقات من الخوادم الجديدة.

نقطة بيانات للدفاع متعمق: Claude Opus 5 مع تفعيل Auto Mode حقق معدل نجاح هجوم حقن مطالبة قائم على المتصفح بنسبة 0% عبر 129 سيناريو اختبار — أول نقطة بيانات ملموسة تُظهر أن حقن مطالبة وكيل المتصفح يمكن تقليله إلى صفر. يجمع Auto Mode بين مسبار حقن مطالبة في طبقة الإدخال ومصنّف إجراءات في طبقة الإخراج. لنشر MCP عديم الحالة حيث تستدعي وكلاء المتصفح أدوات MCP، فإن نمط مسح المدخلات + حظر المهام هو تنفيذ ملموس للدفاع متعمق يُسهّله التصميم عديم الحالة للبروتوكول: كل طلب مستقل بذاته، لذا يعمل المسبار والمصنّف على كل طلب بشكل مستقل، دون حالة جلسة لإفسادها.

ما الذي يتغيّر لوحدات MCP القائمة

إذا كنت تُسلّم وحدات MCP بالفعل — مثلًا نمط مُعالِج RFQ بـ 38 أداة حيث تُسجَّل الأدوات عبر MCP_CONFIGURATION وتُكوّن mixins النطاقات فوق عميل GraphQL مشترك — فإن البروتوكول عديم الحالة يُغيّر النشر، لا كود الوحدة.

تبقى تسجيل أدوات الوحدة، ومخططات الإدخال/الإخراج، وتحديد المعدل، وتسجيل التدقيق كما هي. ما يتغيّر:

• لا تهيئة جلسة عند الإقلاع. لا تشارك الوحدة في مصافحة initialize. تستقبل الطلبات مع _meta يحمل نسخة البروتوكول والقدرات، وتستجيب.
• الأدوات ذات الحالة تُنشئ مقابض. إذا كانت أداة اليوم تعتمد على جلسة من جانب الخادم لتتبّع تدفق عمل متعدد الخطوات، فعليها أن تُنشئ مقبضًا صريحًا وتُعيده. يُمرّره العميل في الاستدعاء التالي. بالنسبة لمُعالِج RFQ، فإن request_id وquote_id وhold_id هي المقابض بالفعل — النمط طبيعي للنطاق.
• ينتقل التسجيل إلى OpenTelemetry. إذا كانت الوحدة تسجّل عبر قناة تسجيل MCP، فانتقل إلى stderr و spans لـ OpenTelemetry. يبقى محتوى التدقيق (الطلب، والاستجابة، والكمون، والنتيجة)؛ يتغيّر النقل.
• التخزين المؤقت تصريحي. تستطيع نقاط نهاية القائمة والموارد أن تُعلن ttlMs وcacheScope على استجاباتها، ما يُتيح للوسطاء التخزين المؤقت دون تخمين.

الخلاصة لفِرق B2B

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

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

---

موزّع يُشغّل NetSuite وBigCommerce وثلاثة كتالوجات مورّدين يحصل على وكيل يستقبل RFQ بالبريد الإلكتروني أو البوابة، ويحلّ المنتجات والبدائل مقابل رسم الكتالوج، ويسعّر حسب طبقة العميل، ويحجز المخزون مع انتهاء صلاحية، ويكتب عرض السعر المقبول إلى NetSuite — مع تسجيل كل خطوة. هذا البناء هو المرحلة 2-3 من المنهجية ذات الأربع خطوات ويُسلّم عادةً خلال 5-8 أسابيع.

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