MCP يتحول إلى Stateless: شرح مواصفة 2026-07-28

ملخص: أكبر مراجعة لبروتوكول MCP منذ أن قدمته شركة Anthropic في نوفمبر 2024¹ ستصبح نهائية في 28 يوليو 2026 — أي بعد أسبوعين من اليوم². التغيير الأبرز هو انتقال MCP إلى نواة بروتوكول عديمة الحالة (stateless)، مما يلغي مصافحة الجلسة (session handshake) التي كانت تربط العميل بنسخة خادم واحدة، وبذلك يمكن لخادم MCP عن بُعد الآن التوسع خلف موازن أحمال (load balancer) عادي بنظام round-robin². وإلى جانبه، استقرت إضافة التفويض المدار من قبل المؤسسة (EMA) في 18 يونيو 2026، لتحل محل مطالبات موافقة OAuth لكل خادم بتسجيل دخول مؤسسي واحد مدعوم بالفعل من قبل سبعة خوادم MCP³. تم إطلاق نسخ بيتا من SDKs للغات Python و TypeScript و Go و #C في 29 يونيو 2026 حتى تتمكن الفرق من اختبار المراجعة الجديدة الآن، وصرح مسؤولو MCP بوضوح أن أي شيء يعمل حالياً لن يتوقف في 28 يوليو — فالاعتماد اختياري⁴. ومع ذلك، يشير باحثو الأمن في Akamai إلى مخاطر جديدة تعتمد على التنفيذ في النموذج عديم الحالة، وتطبيقات MCP Apps، وإضافة المهام (Tasks)⁵.

ما ستتعلمه

• ماذا تعني "عديمة الحالة" (stateless) فعلياً لبروتوكول MCP ولماذا تسمح للخوادم بالتوسع بدون جلسات ثابتة (sticky sessions)
• كيف يحل التفويض المدار من قبل المؤسسة محل مطالبات موافقة OAuth لكل خادم
• ماذا تضيف الإضافتان الرسميتان الجديدتان — MCP Apps و Tasks — إلى البروتوكول
• ما هي تغييرات التفويض الستة التي تؤثر على عملاء وخوادم OAuth الخاصة بك
• ما الذي يشير إليه باحثو الأمن في Akamai كسطح هجوم جديد
• ما يجب فعله فعلياً قبل إغلاق المواصفات في 28 يوليو

لماذا يهم هذا الآن

انتقل MCP من كونه تنسيق تكامل محلي لمستخدم واحد إلى ما تسميه SecurityWeek الآن "المعيار الفعلي" لربط وكلاء الذكاء الاصطناعي بأدوات الأعمال، في أقل من عامين⁵¹. إصدار المواصفات الحالي، 2025-11-25، تمت تسميته تيمناً بالذكرى السنوية الأولى لـ MCP. الإصدار القادم، 2026-07-28، هو أكبر مراجعة منذ الإطلاق، وقد مر بتسلسل زمني واضح يستحق المتابعة لأنه يخبرك بالوقت المتبقي المتاح:

اعتباراً من اليوم، تتبقى نافذة مدتها أسبوعان في فترة التحقق التي طلب فريق MCP من مطوري SDK ومنفذي العملاء استخدامها قبل إغلاق النص²⁴.

ماذا تعني "عديمة الحالة" فعلياً

بموجب المواصفات الحالية، يبدأ استدعاء أداة عبر Streamable HTTP بمصافحة initialize. يستجيب الخادم بترويسة Mcp-Session-Id يجب أن يحملها كل طلب لاحق، مما يربط هذا العميل بنسخة الخادم التي أصدرتها². لهذا السبب كانت عمليات نشر MCP الإنتاجية تحتاج إلى توجيه ثابت (sticky routing) ومخزن جلسات مشترك.

إصدار 2026-07-28 يزيل كلاً من المصافحة (SEP-2575) وترويسة الجلسة (SEP-2567)². تنتقل الآن نسخة البروتوكول ومعلومات العميل والقدرات في حقل _meta مع كل طلب بدلاً من تبادلها مرة واحدة عند الاتصال، وتسمح طريقة server/discover الجديدة للعميل بجلب قدرات الخادم مسبقاً. النتيجة العملية: يمكن لأي نسخة خادم الرد على أي طلب، لذا فإن خادم MCP عن بُعد الذي كان يحتاج إلى جلسات ثابتة، ومخزن جلسات مشترك، وفحص عميق للحزم عند البوابة يمكنه الآن العمل خلف موازن أحمال عادي بنظام round-robin بدلاً من ذلك².

إزالة الجلسات على مستوى البروتوكول لا تعني أن التطبيق يجب أن يكون عديم الحالة. يصف مسؤولو MCP نمط المقبض الصريح (explicit-handle pattern): يقوم الخادم بإنشاء معرف (مثل basket_id أو browser_id) من استدعاء أداة، ويمرر النموذج هذا المعرف نفسه كمعامل عادي في الاستدعاءات اللاحقة، مما يجعل الحالة مرئية للنموذج بدلاً من كونها مخفية في بيانات النقل الوصفية².

يتم إعادة بناء طلبات الخادم إلى العميل — مثل طلب توضيح في منتصف الاستدعاء — حول نفس النموذج عديم الحالة. تحل الطلبات متعددة الجولات (Multi Round-Trip Requests) (SEP-2322) محل تدفق الأحداث المرسلة من الخادم (SSE) المفتوح باستمرار: يعيد الخادم InputRequiredResult مع الحقول التي يحتاجها، ويقوم العميل بجمع الإجابات، ويعيد إصدار الاستدعاء الأصلي مع inputResponses بالإضافة إلى رمز requestState مكرر يمكن لأي نسخة خادم التقاطه². تتبع ذلك ثلاثة تغييرات صغيرة ولكنها عملية: يتطلب Streamable HTTP الآن ترويسات Mcp-Method و Mcp-Name حتى تتمكن البوابات ومحددات المعدل من التوجيه دون فحص جسم الطلب (SEP-2243)؛ وتحمل نتائج القائمة/الموارد الآن حقول ttlMs و cacheScope المصممة على غرار Cache-Control في HTTP، ليعرف العملاء بالضبط مدة بقاء استجابة tools/list المخزنة مؤقتاً (SEP-2549)؛ كما تم توثيق انتشار W3C Trace Context في _meta رسمياً (SEP-414)، بحيث يمكن للتتبع الموزع تتبع استدعاء الأداة عبر العميل والخادم وأي شيء يستدعيه لاحقاً².

التفويض المدار من قبل المؤسسة: إنهاء إرهاق مطالبات الموافقة

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

أصبح التفويض المدار من قبل المؤسسة (EMA) مستقراً في 18 يونيو 2026 لإصلاح ذلك³. فهو يجعل مزود الهوية الخاص بالمؤسسة هو المرجع للوصول إلى خادم MCP: يحصل العميل على منح تفويض JWT لتوكيد الهوية (ID-JAG) من مزود الهوية (IdP) أثناء تسجيل الدخول الموحد ويستبدله بـ access token من خادم التفويض الخاص بخادم MCP، وبذلك لا يتم إعادة توجيه المستخدم أبداً عبر شاشة موافقة لكل خادم³. يقوم المسؤولون بتمكين الخادم مرة واحدة للمؤسسة؛ ويرث المستخدمون الوصول تلقائياً، بنطاق محدد للمجموعات والأدوار التي يشغلونها بالفعل.

حد مهم واحد: يحكم EMA الوصول على مستوى الاتصال — ما إذا كان بإمكان عميل المستخدم الوصول إلى خادم، وبأي نطاق — وليس ما يفعله العميل (agent) بمجرد دخوله إلى النظام. لا يفحص الامتداد حركة مرور MCP بعد إصدار التوكن وليس تفويضاً وقت التشغيل لاستدعاءات الأدوات الفردية، لذا لا تزال المؤسسات بحاجة إلى ضوابط منفصلة لما يفعله العميل بمجرد اتصاله⁶.

الاعتماد عند الإطلاق:

صاغ آرون باريكي من Okta، مدير معايير الهوية، الأمر كتحول في الحوكمة: "من خلال دمج بروتوكول Cross App Access في MCP كامتداد للتفويض المدار من قبل المؤسسة، فإننا نحول الهوية إلى مستوى حوكمة مركزي ونمنح فرق الأمن تحكماً صارماً في الامتثال والمستخدمين تجربة سلسة وآمنة."³ بينما وضع توم مور من Linear، رئيس الهندسة، التأثير المواجه للمستخدم بشكل أبسط: "تسجيل الدخول مرة واحدة وتهيئة جميع موصلات MCP الخاصة بك تلقائياً هو أمر سحري للغاية."³

إذا كنت تقوم بالفعل بتشغيل خادم MCP باستخدام OAuth 2.1 و RFC 8707 resource indicators، فإن EMA هو طبقة المؤسسة فوق تدفق كل مستخدم، وليس بديلاً له — فمن المرجح أن تدعم كليهما.

امتدادان جديدان: تطبيقات ومهام MCP

2026-07-28 يضفي الطابع الرسمي أيضاً على إطار عمل الامتدادات (SEP-2133): تحصل الإمكانيات على معرفات DNS عكسية، وتعيش في مستودعات ext-* الخاصة بها مع مطورين مفوضين، وتصدر بنسخ مستقلة عن المواصفات الأساسية، مع مسار مخصص للانتقال من التجريبي إلى الرسمي². يتم شحن امتدادين كجزء من هذا الإصدار:

تطبيقات MCP (SEP-1865) تتيح للخادم شحن واجهة HTML تفاعلية يعرضها المضيف داخل iframe معزول (sandboxed). تعلن الأدوات عن قوالب واجهة المستخدم الخاصة بها مسبقاً حتى يتمكن المضيف من جلبها مسبقاً وتخزينها ومراجعتها أمنياً قبل تشغيل أي شيء، ولا يزال كل إجراء يتم بدؤه من واجهة المستخدم يمر عبر نفس مسار تدقيق JSON-RPC والموافقة كاستدعاء أداة مباشر².

المهام تنتقل من ميزة أساسية تجريبية في 2025-11-25 إلى امتداد كامل. يمكن للخادم الرد على tools/call بمقبض مهمة، ويقوم العميل بدفعها للأمام باستخدام tasks/get و tasks/update و tasks/cancel. إنشاء المهام موجه من قبل الخادم — العميل يعلن فقط عن الدعم — واختفى tasks/list تماماً لأنه لا يمكن تحديد نطاقه بأمان بدون جلسات على مستوى البروتوكول². أي شخص قام بالبناء ضد API المهام التجريبي في 2025-11-25 يحتاج إلى الانتقال إلى دورة الحياة الجديدة هذه.

تحصين التفويض: ستة تغييرات يجب معرفتها

بالإضافة إلى EMA، تعمل ستة SEPs على تشديد مواصفات التفويض الأساسية لتتماشى بشكل أوثق مع كيفية نشر OAuth 2.0 و OpenID Connect فعلياً²⁴:

• التحقق من iss (SEP-2468) — يجب على العملاء الآن التحقق من معلمة المصدر (issuer) في استجابات التفويض وفقاً لـ RFC 9207، مما يقلل من هجمات الخلط (mix-up attacks) الشائعة في نمط العميل الواحد والخوادم المتعددة في MCP.
• إعلان application_type (SEP-837) — يعلن العملاء عن نوع تطبيق OpenID Connect الخاص بهم أثناء تسجيل العميل الديناميكي، مما يصلح الفشل الشائع حيث كان خادم التفويض يفترض افتراضياً أن عميل سطح المكتب أو CLI هو "web" ويرفض URI لإعادة التوجيه الخاص بـ localhost.
• ربط أوراق الاعتماد (SEP-2352) — يربط العملاء أوراق الاعتماد المسجلة بخادم التفويض المصدر ويعيدون التسجيل عندما ينتقل مورد بين خوادم التفويض.
• طلبات refresh token (SEP-2207) — توثق المواصفات الآن كيفية طلب refresh tokens من خوادم التفويض بنمط OpenID Connect.
• تراكم النطاق أثناء التصعيد (SEP-2350) ولاحقة اكتشاف .well-known (SEP-2351) — توضيحان أصغر تم تشديدهما جنباً إلى جنب مع البقية.

بشكل منفصل، يتغير رمز الخطأ لمورد مفقود من رمز MCP المخصص -32002 إلى معيار JSON-RPC وهو -32602 Invalid Params (SEP-2164) — وهو أمر يستحق البحث (grep) عبر أي عميل يطابق القيمة القديمة الحرفية⁴.

تم إهمال ثلاث بدائيات حالية رسمياً — الجذور (Roots)، وأخذ العينات (Sampling)، والتسجيل (Logging) — (SEP-2577)، واستبدالها على التوالي بمعلمات الأدوات، أو URIs للموارد، أو تكوين الخادم؛ وتكامل API المباشر لمزود LLM؛ و stderr/OpenTelemetry. هذه عمليات إهمال للتعليقات التوضيحية فقط: تستمر الطرق في العمل في هذا الإصدار وفي كل إصدار مواصفات يتم نشره في غضون اثني عشر شهراً منه، بموجب سياسة دورة حياة الميزات الجديدة التي تتطلب فجوة لا تقل عن 12 شهراً بين الإهمال والإزالة².

ما يشير إليه باحثو الأمن في Akamai

تتعامل الأبحاث الأمنية المستقلة مع هذا كتحسين صافٍ مع مخاطر جديدة ومختلفة بدلاً من مجرد تحصين مباشر. ينسب تحليل Akamai، الذي أوردته SecurityWeek، الفضل للنواة عديمة الحالة (stateless) في إنهاء اختطاف الجلسات ومنع المطالبات غير المرغوب فيها التي يبدأها الخادم، مع ملاحظة أن "الحدود الأمنية الحرجة تعتمد الآن بالكامل على كيفية تنفيذ المطورين لها،" وفقاً لماكسيم زافودشيك، مدير أبحاث التهديدات الأول في Akamai⁵.

المخاوف المحددة التي أثارتها Akamai هي⁵:

• مقابض الحالة القابلة للتوقع (Predictable state handles). نظرًا لأن المقابض الصريحة (مثل basket_id) تحل محل الجلسات التي يديرها البروتوكول، فإن المعرف القابل للتوقع قد يسمح للمهاجم باختطاف سير عمل نشط، أو قراءة بيانات عميل آخر، أو إطلاق إجراءات غير مصرح بها عبر المستأجرين (cross-tenant).
• تسريب البيانات القائم على الترويسات (Headers) وهجمات عدم التزامن (Desync). ترويسات Mcp-Method و Mcp-Name الإلزامية الجديدة تزيد من مخاطر ارتباك البروتوكول، وإذا قام المطورون عن طريق الخطأ بتعيين قيم حساسة — مفاتيح API، أو رموز (tokens)، أو بيانات تعريف شخصية (PII) — في الترويسات، فستصبح هذه القيم مرئية لكل موازن أحمال (load balancer)، ووكيل (proxy)، ونظام تسجيل (logging) في المسار.
• تطبيقات MCP والـ XSS المخزن. لا تزال واجهة المستخدم التي يتم عرضها عبر الخادم في إطار iframe معزول (sandboxed) ترث مخاطر تطبيقات الويب الكلاسيكية، بما في ذلك حقن النصوص البرمجية عبر المواقع (XSS) المخزن.
• المهام (Tasks) كمتجه لهجمات حجب الخدمة (DoS). إنشاء مهمة هو أمر رخيص بالنسبة للعميل ولكن يمكن أن يكون مكلفًا للخادم لتشغيله؛ تحذر Akamai من أن المهاجم يمكنه إطلاق مهمة تستهلك موارد كثيرة ويفصل الاتصال فورًا، دون انتظار النتيجة أبدًا.

صياغة Akamai العامة: "التغييرات ليست مجرد تحسينات تدريجية. إنها تعيد تشكيل مكان استقرار المسؤوليات الأمنية بشكل أساسي" — من البروتوكول نفسه نحو المطورين ومشغلي المنصات الذين يبنون فوقه⁵. وهذا سبب وجيه لاعتبار 28 يوليو بمثابة حافز لمراجعة تطبيقات خادم MCP، وليس فقط إصدارات SDK.

ما ستتعلمه

مشرفو MCP صريحون بشأن نقطة واحدة: لا شيء يعمل حاليًا سيتعطل في 28 يوليو، ولا يوجد شيء مجبر على التغيير في ذلك اليوم أيضًا — إنه التاريخ الذي يتم فيه نشر نص المواصفات المعياري، وليس موعدًا للتحول الإجباري⁴. تقديم الإصدار 2026-07-28 هو خيار صريح للاشتراك في SDKs الخاصة بـ TypeScript و Go؛ والعملاء الذين يتحدثون المراجعة الجديدة يتراجعون تلقائيًا إلى مصافحة initialize عندما يصلون إلى خادم 2025-11-25 أقدم، لذا تستمر الخوادم القديمة والعملاء الجدد في العمل معًا⁴.

مع بقاء أسبوعين قبل قفل النص، تبدو قائمة المراجعة العملية كما يلي:

1. تثبيت نسخة بيتا من SDK في فرع (branch) وتشغيل حركة مرور حقيقية عليها — Python (mcp[cli]==2.0.0b1، مع إعادة تسمية FastMCP إلى MCPServer)، أو TypeScript (حزم محددة النطاق جديدة مثل @modelcontextprotocol/server، بالإضافة إلى v1-to-v2 codemod)، أو Go (v1.7.0-pre.1، مع الاشتراك عبر StreamableHTTPOptions.Stateless = true)، أو C# (2.0.0-preview.1 من ModelContextProtocol)⁴.
2. تثبيت الإصدارات (Pin versions) إذا كنت تعتمد على حزم MCP. إذا كنت تنشر مكتبة تعتمد على حزمة Python mcp، فأضف حدًا أقصى الآن (على سبيل المثال mcp>=1.27,<2) حتى لا يفاجئ إصدار v2 المستقر المستخدمين في المراحل اللاحقة⁴.
3. ابحث في عميلك عن رمز الخطأ الصريح -32002 وقم بتحديثه ليتوقع -32602 بدلاً من ذلك⁴.
4. إذا كنت خلف بوابة (gateway) أو موازن أحمال، فاختبر المسار عديم الحالة (stateless) وتأكد من أن توجيهك لا يعتمد على أي شيء لم يعد البروتوكول يوفره⁴.
5. إذا كنت تشحن لعملاء من الشركات الكبرى، فقم بتقييم "التفويض المدار من قبل المؤسسة" (Enterprise-Managed Authorization) و "الوصول عبر التطبيقات" (Cross App Access) من Okta الآن — هناك سبعة خوادم تدعمه بالفعل، وهو يعالج مشكلة احتكاك طلبات الموافقة التي أبطأت عمليات نشر MCP في المؤسسات³.
6. أبلغ عما يتعطل. صرح فريق MCP أن الأسابيع الأربعة القادمة من التعليقات (بدءًا من أواخر يونيو) ستشكل ما سيتم إصداره كنسخة مستقرة — تذهب المشكلات إلى المستودع الخاص بـ SDK الذي تختبره⁴.

الخلاصة

يعد إصدار MCP في 2026-07-28 تحولاً معمارياً حقيقياً — فإزالة الجلسات على مستوى البروتوكول هي نوع التغيير الذي تطلب فصلاً جذرياً، وقد وضع المطورون نظام حوكمة (سياسة إيقاف تشغيل رسمية، ومسار للإضافات) خصيصاً لضمان عدم الحاجة لتكرار ذلك. يحل نظام "Enterprise-Managed Authorization" نقطة احتكاك حقيقية لعمليات نشر MCP في الشركات الكبرى، ووجود Anthropic و Visual Studio Code و Okta خلفه منذ البداية يمنحه زخماً حقيقياً ليصبح معياراً افتراضياً بدلاً من مجرد إضافة اختيارية. لا شيء من هذا يعد حالة طوارئ: الخوادم الحالية ستستمر في العمل، واعتماد المراجعة الجديدة هو أمر اختياري وفقاً لجدولك الزمني الخاص. الموقف الأكثر فائدة هو ما تصفه Akamai: تعامل مع هذا كدعوة لمراجعة خيارات تنفيذ خادم MCP الخاص بك، وليس مجرد تحديث إصدار مجدول. نص المواصفات نفسه يثبت في غضون أسبوعين، لكن تقارير SecurityWeek تشير إلى أن مهلة التكيف الأمني الكاملة تصل إلى اثني عشر شهراً⁵ — وفي كلتا الحالتين، يرى باحثو Akamai أن هذا الإصدار ينقل المسؤولية الأمنية إلى من يبني فوقه. إذا كنت تقوم ببناء عملاء MCP أو خوادم، أو كنت جديداً على ماهية MCP في الواقع، فهذه هي اللحظة المناسبة لقراءة سجل التغييرات قبل اعتماده نهائياً.