--- title: 'MCP يتحول إلى Stateless: شرح مواصفة 2026-07-28' description: مواصفات MCP الصادرة في ٢٨ يوليو ٢٠٢٦ تتحول إلى stateless وتطلق خاصية Enterprise-Managed Authorization. إليك ما سيتغير، وما سيتعطل، والمخاطر الأمنية الجديدة التي يجب التخطيط لها. url: https://nerdleveltech.com/ar/mcp-stateless-protocol-enterprise-authorization language: ar date: '2026-07-14' category: llm-integration tags: - MCP - Model Context Protocol - AI agents - Enterprise-Managed Authorization - MCP Apps - agent security - OAuth - AI agent tooling markdown_url: https://nerdleveltech.com/ar/mcp-stateless-protocol-enterprise-authorization.md attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/ar/mcp-stateless-protocol-enterprise-authorization' terms: https://nerdleveltech.com/llms.txt --- # MCP يتحول إلى Stateless: شرح مواصفة 2026-07-28 **ملخص:** أكبر مراجعة لبروتوكول MCP منذ أن قدمته شركة Anthropic في نوفمبر 2024[^6] ستصبح نهائية في **28 يوليو 2026** — أي بعد أسبوعين من اليوم[^1]. التغيير الأبرز هو انتقال MCP إلى **نواة بروتوكول عديمة الحالة (stateless)**، مما يلغي مصافحة الجلسة (session handshake) التي كانت تربط العميل بنسخة خادم واحدة، وبذلك يمكن لخادم MCP عن بُعد الآن التوسع خلف موازن أحمال (load balancer) عادي بنظام round-robin[^1]. وإلى جانبه، استقرت إضافة **التفويض المدار من قبل المؤسسة (EMA)** في 18 يونيو 2026، لتحل محل مطالبات موافقة OAuth لكل خادم بتسجيل دخول مؤسسي واحد مدعوم بالفعل من قبل سبعة خوادم MCP[^3]. تم إطلاق نسخ بيتا من SDKs للغات Python و TypeScript و Go و #C في 29 يونيو 2026 حتى تتمكن الفرق من اختبار المراجعة الجديدة الآن، وصرح مسؤولو MCP بوضوح أن أي شيء يعمل حالياً لن يتوقف في 28 يوليو — فالاعتماد اختياري[^2]. ومع ذلك، يشير باحثو الأمن في Akamai إلى مخاطر جديدة تعتمد على التنفيذ في النموذج عديم الحالة، وتطبيقات MCP Apps، وإضافة المهام (Tasks)[^4]. ## ما ستتعلمه - ماذا تعني "عديمة الحالة" (stateless) فعلياً لبروتوكول MCP ولماذا تسمح للخوادم بالتوسع بدون جلسات ثابتة (sticky sessions) - كيف يحل التفويض المدار من قبل المؤسسة محل مطالبات موافقة OAuth لكل خادم - ماذا تضيف الإضافتان الرسميتان الجديدتان — MCP Apps و Tasks — إلى البروتوكول - ما هي تغييرات التفويض الستة التي تؤثر على عملاء وخوادم OAuth الخاصة بك - ما الذي يشير إليه باحثو الأمن في Akamai كسطح هجوم جديد - ما يجب فعله فعلياً قبل إغلاق المواصفات في 28 يوليو ## لماذا يهم هذا الآن انتقل MCP من كونه تنسيق تكامل محلي لمستخدم واحد إلى ما تسميه SecurityWeek الآن "المعيار الفعلي" لربط وكلاء الذكاء الاصطناعي بأدوات الأعمال، في أقل من عامين[^4][^6]. إصدار المواصفات الحالي، `2025-11-25`، تمت تسميته تيمناً بالذكرى السنوية الأولى لـ MCP. الإصدار القادم، `2026-07-28`، هو أكبر مراجعة منذ الإطلاق، وقد مر بتسلسل زمني واضح يستحق المتابعة لأنه يخبرك بالوقت المتبقي المتاح: | التاريخ | الحدث الهام | | ------------- | -------------------------------------------------------------- | | 21 مايو 2026 | إغلاق ونشر النسخة المرشحة للمواصفة `2026-07-28`[^1] | | 18 يونيو 2026 | استقرار إضافة التفويض المدار من قبل المؤسسة (EMA)[^3] | | 29 يونيو 2026 | إطلاق نسخ بيتا من SDKs للغات Python و TypeScript و Go و #C[^2] | | 28 يوليو 2026 | نشر النص النهائي لمواصفة `2026-07-28` | اعتباراً من اليوم، تتبقى **نافذة مدتها أسبوعان** في فترة التحقق التي طلب فريق MCP من مطوري SDK ومنفذي العملاء استخدامها قبل إغلاق النص[^1][^2]. ## ماذا تعني "عديمة الحالة" فعلياً بموجب المواصفات الحالية، يبدأ استدعاء أداة عبر Streamable HTTP بمصافحة `initialize`. يستجيب الخادم بترويسة `Mcp-Session-Id` يجب أن يحملها كل طلب لاحق، مما يربط هذا العميل بنسخة الخادم التي أصدرتها[^1]. لهذا السبب كانت عمليات نشر MCP الإنتاجية تحتاج إلى توجيه ثابت (sticky routing) ومخزن جلسات مشترك. إصدار `2026-07-28` يزيل كلاً من المصافحة (SEP-2575) وترويسة الجلسة (SEP-2567)[^1]. تنتقل الآن نسخة البروتوكول ومعلومات العميل والقدرات في حقل `_meta` مع كل طلب بدلاً من تبادلها مرة واحدة عند الاتصال، وتسمح طريقة `server/discover` الجديدة للعميل بجلب قدرات الخادم مسبقاً. النتيجة العملية: يمكن لأي نسخة خادم الرد على أي طلب، لذا فإن خادم MCP عن بُعد الذي كان يحتاج إلى جلسات ثابتة، ومخزن جلسات مشترك، وفحص عميق للحزم عند البوابة يمكنه الآن العمل خلف موازن أحمال عادي بنظام round-robin بدلاً من ذلك[^1]. إزالة الجلسات على مستوى البروتوكول لا تعني أن التطبيق يجب أن يكون عديم الحالة. يصف مسؤولو MCP **نمط المقبض الصريح (explicit-handle pattern)**: يقوم الخادم بإنشاء معرف (مثل `basket_id` أو `browser_id`) من استدعاء أداة، ويمرر النموذج هذا المعرف نفسه كمعامل عادي في الاستدعاءات اللاحقة، مما يجعل الحالة مرئية للنموذج بدلاً من كونها مخفية في بيانات النقل الوصفية[^1]. يتم إعادة بناء طلبات الخادم إلى العميل — مثل طلب توضيح في منتصف الاستدعاء — حول نفس النموذج عديم الحالة. تحل **الطلبات متعددة الجولات (Multi Round-Trip Requests)** (SEP-2322) محل تدفق الأحداث المرسلة من الخادم (SSE) المفتوح باستمرار: يعيد الخادم `InputRequiredResult` مع الحقول التي يحتاجها، ويقوم العميل بجمع الإجابات، ويعيد إصدار الاستدعاء الأصلي مع `inputResponses` بالإضافة إلى رمز `requestState` مكرر يمكن لأي نسخة خادم التقاطه[^1]. تتبع ذلك ثلاثة تغييرات صغيرة ولكنها عملية: يتطلب Streamable HTTP الآن ترويسات `Mcp-Method` و `Mcp-Name` حتى تتمكن البوابات ومحددات المعدل من التوجيه دون فحص جسم الطلب (SEP-2243)؛ وتحمل نتائج القائمة/الموارد الآن حقول `ttlMs` و `cacheScope` المصممة على غرار `Cache-Control` في HTTP، ليعرف العملاء بالضبط مدة بقاء استجابة `tools/list` المخزنة مؤقتاً (SEP-2549)؛ كما تم توثيق انتشار W3C Trace Context في `_meta` رسمياً (SEP-414)، بحيث يمكن للتتبع الموزع تتبع استدعاء الأداة عبر العميل والخادم وأي شيء يستدعيه لاحقاً[^1]. ## التفويض المدار من قبل المؤسسة: إنهاء إرهاق مطالبات الموافقة نموذج تفويض MCP القياسي موجه للمستخدم: يقوم كل موظف بتفويض كل خادم، شاشة موافقة OAuth واحدة تلو الأخرى. في عمليات النشر الكبيرة للمؤسسات، يعني هذا إعداداً يدوياً لكل أداة، وعدم وجود سجل تدقيق مركزي، وعدم وجود طريقة لمنع شخص ما من ربط حساب شخصي بخادم عمل[^3]. أصبح **التفويض المدار من قبل المؤسسة (EMA)** مستقراً في 18 يونيو 2026 لإصلاح ذلك[^3]. فهو يجعل مزود الهوية الخاص بالمؤسسة هو المرجع للوصول إلى خادم MCP: يحصل العميل على **منح تفويض JWT لتوكيد الهوية (ID-JAG)** من مزود الهوية (IdP) أثناء تسجيل الدخول الموحد ويستبدله بـ access token من خادم التفويض الخاص بخادم MCP، وبذلك لا يتم إعادة توجيه المستخدم أبداً عبر شاشة موافقة لكل خادم[^3]. يقوم المسؤولون بتمكين الخادم مرة واحدة للمؤسسة؛ ويرث المستخدمون الوصول تلقائياً، بنطاق محدد للمجموعات والأدوار التي يشغلونها بالفعل. حد مهم واحد: يحكم EMA الوصول على *مستوى الاتصال* — ما إذا كان بإمكان عميل المستخدم الوصول إلى خادم، وبأي نطاق — وليس ما يفعله العميل (agent) بمجرد دخوله إلى النظام. لا يفحص الامتداد حركة مرور MCP بعد إصدار التوكن وليس تفويضاً وقت التشغيل لاستدعاءات الأدوات الفردية، لذا لا تزال المؤسسات بحاجة إلى ضوابط منفصلة لما يفعله العميل بمجرد اتصاله[^5]. الاعتماد عند الإطلاق: | الطبقة | من يدعمها | | ----------- | ------------------------------------------------------------------------------------- | | مزود الهوية | Okta، عبر Cross App Access (XAA) — أول مزود هوية مدعوم[^3] | | العملاء | Anthropic (Claude، Claude Code، Cowork — طبقة MCP مشتركة)؛ Visual Studio Code[^3] | | الخوادم | Asana، Atlassian، Canva، Figma، Granola، Linear، Supabase؛ Slack تضيف الدعم بنشاط[^3] | صاغ آرون باريكي من Okta، مدير معايير الهوية، الأمر كتحول في الحوكمة: "من خلال دمج بروتوكول Cross App Access في MCP كامتداد للتفويض المدار من قبل المؤسسة، فإننا نحول الهوية إلى مستوى حوكمة مركزي ونمنح فرق الأمن تحكماً صارماً في الامتثال والمستخدمين تجربة سلسة وآمنة."[^3] بينما وضع توم مور من Linear، رئيس الهندسة، التأثير المواجه للمستخدم بشكل أبسط: "تسجيل الدخول مرة واحدة وتهيئة جميع موصلات MCP الخاصة بك تلقائياً هو أمر سحري للغاية."[^3] إذا كنت تقوم بالفعل بتشغيل خادم MCP باستخدام [OAuth 2.1 و RFC 8707 resource indicators](https://nerdleveltech.com/mcp-server-TypeScript-oauth-streamable-http-production-tutorial)، فإن EMA هو طبقة المؤسسة فوق تدفق كل مستخدم، وليس بديلاً له — فمن المرجح أن تدعم كليهما. ## امتدادان جديدان: تطبيقات ومهام MCP `2026-07-28` يضفي الطابع الرسمي أيضاً على **إطار عمل الامتدادات** (SEP-2133): تحصل الإمكانيات على معرفات DNS عكسية، وتعيش في مستودعات `ext-*` الخاصة بها مع مطورين مفوضين، وتصدر بنسخ مستقلة عن المواصفات الأساسية، مع مسار مخصص للانتقال من التجريبي إلى الرسمي[^1]. يتم شحن امتدادين كجزء من هذا الإصدار: **تطبيقات MCP** (SEP-1865) تتيح للخادم شحن واجهة HTML تفاعلية يعرضها المضيف داخل iframe معزول (sandboxed). تعلن الأدوات عن قوالب واجهة المستخدم الخاصة بها مسبقاً حتى يتمكن المضيف من جلبها مسبقاً وتخزينها ومراجعتها أمنياً قبل تشغيل أي شيء، ولا يزال كل إجراء يتم بدؤه من واجهة المستخدم يمر عبر نفس مسار تدقيق JSON-RPC والموافقة كاستدعاء أداة مباشر[^1]. **المهام** تنتقل من ميزة أساسية تجريبية في `2025-11-25` إلى امتداد كامل. يمكن للخادم الرد على `tools/call` بمقبض مهمة، ويقوم العميل بدفعها للأمام باستخدام `tasks/get` و `tasks/update` و `tasks/cancel`. إنشاء المهام موجه من قبل الخادم — العميل يعلن فقط عن الدعم — واختفى `tasks/list` تماماً لأنه لا يمكن تحديد نطاقه بأمان بدون جلسات على مستوى البروتوكول[^1]. أي شخص قام بالبناء ضد API المهام التجريبي في `2025-11-25` يحتاج إلى الانتقال إلى دورة الحياة الجديدة هذه. ## تحصين التفويض: ستة تغييرات يجب معرفتها بالإضافة إلى EMA، تعمل ستة SEPs على تشديد [مواصفات التفويض](https://modelcontextprotocol.io/specification/draft/basic/authorization) الأساسية لتتماشى بشكل أوثق مع كيفية نشر OAuth 2.0 و OpenID Connect فعلياً[^1][^2]: - **التحقق من `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) عبر أي عميل يطابق القيمة القديمة الحرفية[^2]. تم إهمال ثلاث بدائيات حالية رسمياً — **الجذور (Roots)، وأخذ العينات (Sampling)، والتسجيل (Logging)** — (SEP-2577)، واستبدالها على التوالي بمعلمات الأدوات، أو URIs للموارد، أو تكوين الخادم؛ وتكامل API المباشر لمزود LLM؛ و stderr/OpenTelemetry. هذه عمليات إهمال للتعليقات التوضيحية فقط: تستمر الطرق في العمل في هذا الإصدار وفي كل إصدار مواصفات يتم نشره في غضون اثني عشر شهراً منه، بموجب سياسة دورة حياة الميزات الجديدة التي تتطلب فجوة لا تقل عن 12 شهراً بين الإهمال والإزالة[^1]. ## ما يشير إليه باحثو الأمن في Akamai تتعامل الأبحاث الأمنية المستقلة مع هذا كتحسين صافٍ مع مخاطر جديدة ومختلفة بدلاً من مجرد تحصين مباشر. ينسب تحليل Akamai، الذي أوردته SecurityWeek، الفضل للنواة عديمة الحالة (stateless) في إنهاء اختطاف الجلسات ومنع المطالبات غير المرغوب فيها التي يبدأها الخادم، مع ملاحظة أن "الحدود الأمنية الحرجة تعتمد الآن بالكامل على كيفية تنفيذ المطورين لها،" وفقاً لماكسيم زافودشيك، مدير أبحاث التهديدات الأول في Akamai[^4]. المخاوف المحددة التي أثارتها Akamai هي[^4]: - **مقابض الحالة القابلة للتوقع (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 العامة: "التغييرات ليست مجرد تحسينات تدريجية. إنها تعيد تشكيل مكان استقرار المسؤوليات الأمنية بشكل أساسي" — من البروتوكول نفسه نحو المطورين ومشغلي المنصات الذين يبنون فوقه[^4]. وهذا سبب وجيه لاعتبار 28 يوليو بمثابة حافز لمراجعة تطبيقات خادم MCP، وليس فقط إصدارات SDK. ## ما ستتعلمه مشرفو MCP صريحون بشأن نقطة واحدة: **لا شيء يعمل حاليًا سيتعطل في 28 يوليو، ولا يوجد شيء مجبر على التغيير في ذلك اليوم أيضًا** — إنه التاريخ الذي يتم فيه نشر نص المواصفات المعياري، وليس موعدًا للتحول الإجباري[^2]. تقديم الإصدار `2026-07-28` هو خيار صريح للاشتراك في SDKs الخاصة بـ TypeScript و Go؛ والعملاء الذين يتحدثون المراجعة الجديدة يتراجعون تلقائيًا إلى مصافحة `initialize` عندما يصلون إلى خادم `2025-11-25` أقدم، لذا تستمر الخوادم القديمة والعملاء الجدد في العمل معًا[^2]. مع بقاء أسبوعين قبل قفل النص، تبدو قائمة المراجعة العملية كما يلي: 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]. 2. **تثبيت الإصدارات (Pin versions) إذا كنت تعتمد على حزم MCP.** إذا كنت تنشر مكتبة تعتمد على حزمة Python `mcp`، فأضف حدًا أقصى الآن (على سبيل المثال `mcp>=1.27,<2`) حتى لا يفاجئ إصدار v2 المستقر المستخدمين في المراحل اللاحقة[^2]. 3. **ابحث في عميلك عن رمز الخطأ الصريح `-32002`** وقم بتحديثه ليتوقع `-32602` بدلاً من ذلك[^2]. 4. **إذا كنت خلف بوابة (gateway) أو موازن أحمال**، فاختبر المسار عديم الحالة (stateless) وتأكد من أن توجيهك لا يعتمد على أي شيء لم يعد البروتوكول يوفره[^2]. 5. **إذا كنت تشحن لعملاء من الشركات الكبرى**، فقم بتقييم "التفويض المدار من قبل المؤسسة" (Enterprise-Managed Authorization) و "الوصول عبر التطبيقات" (Cross App Access) من Okta الآن — هناك سبعة خوادم تدعمه بالفعل، وهو يعالج مشكلة احتكاك طلبات الموافقة التي أبطأت عمليات نشر MCP في المؤسسات[^3]. 6. **أبلغ عما يتعطل.** صرح فريق MCP أن الأسابيع الأربعة القادمة من التعليقات (بدءًا من أواخر يونيو) ستشكل ما سيتم إصداره كنسخة مستقرة — تذهب المشكلات إلى المستودع الخاص بـ SDK الذي تختبره[^2]. ## الأسئلة الشائعة ### ماذا يعني أن يصبح MCP عديم الحالة (stateless)؟ تزيل مواصفات MCP `2026-07-28` مصافحة `initialize` وترويسة `Mcp-Session-Id` التي كانت تربط العميل سابقًا بمثيل خادم واحد. يحمل كل طلب الآن إصدار البروتوكول الخاص به، ومعلومات العميل، والقدرات في حقل `_meta`، بحيث يمكن لأي مثيل خادم الرد على أي طلب — مما يسمح للخوادم بالتوسع خلف موازن أحمال بسيط بنظام round-robin بدلاً من طلب جلسات ثابتة (sticky sessions)[^1]. ### متى سيتم إطلاق مواصفات MCP الجديدة؟ تم قفل النسخة المرشحة للإصدار في 21 مايو 2026، وسيتم نشر نص مواصفات `2026-07-28` النهائي في 28 يوليو 2026[^1]. ### ما هو تفويض MCP المدار من قبل المؤسسة (Enterprise-Managed Authorization)؟ هو امتداد، مستقر منذ 18 يونيو 2026، يسمح لمزود الهوية في المؤسسة بإدارة خوادم MCP التي يمكن للمستخدم الوصول إليها مركزيًا، ليحل محل طلبات موافقة OAuth لكل خادم بتدفق تسجيل دخول موحد (SSO). تم اعتماده من قبل Anthropic و Visual Studio Code و Okta وسبعة خوادم MCP حتى الآن[^3]. ### هل سيتعطل خادم MCP الحالي الخاص بي في 28 يوليو 2026؟ لا. صرح مشرفو MCP صراحةً أن التطبيقات الحالية ستستمر في العمل وأن اعتماد المراجعة الجديدة هو أمر اختياري — 28 يوليو هو موعد نشر نص المواصفات المعياري، وليس تاريخ تحول قسري[^2]. ### ما هي المخاطر الأمنية الجديدة التي تقدمها مواصفات MCP 2026-07-28؟ يشير باحثو الأمن في Akamai إلى معرفات مقابض الحالة القابلة للتوقع، وتسريب البيانات المحتمل من خلال ترويسات `Mcp-Method`/`Mcp-Name` الجديدة، ومخاطر XSS المخزن في امتداد تطبيقات MCP الجديد، ومخاطر حجب الخدمة من المهام (Tasks) رخيصة الإنشاء ومكلفة التشغيل. تصيغ Akamai هذا على أنه انتقال للمسؤولية الأمنية من البروتوكول نفسه إلى تطبيقات الخادم الفردية[^4]. ## الخلاصة يعد إصدار MCP في `2026-07-28` تحولاً معمارياً حقيقياً — فإزالة الجلسات على مستوى البروتوكول هي نوع التغيير الذي تطلب فصلاً جذرياً، وقد وضع المطورون نظام حوكمة (سياسة إيقاف تشغيل رسمية، ومسار للإضافات) خصيصاً لضمان عدم الحاجة لتكرار ذلك. يحل نظام "Enterprise-Managed Authorization" نقطة احتكاك حقيقية لعمليات نشر MCP في الشركات الكبرى، ووجود Anthropic و Visual Studio Code و Okta خلفه منذ البداية يمنحه زخماً حقيقياً ليصبح معياراً افتراضياً بدلاً من مجرد إضافة اختيارية. لا شيء من هذا يعد حالة طوارئ: الخوادم الحالية ستستمر في العمل، واعتماد المراجعة الجديدة هو أمر اختياري وفقاً لجدولك الزمني الخاص. الموقف الأكثر فائدة هو ما تصفه Akamai: تعامل مع هذا كدعوة لمراجعة خيارات تنفيذ خادم MCP الخاص بك، وليس مجرد تحديث إصدار مجدول. نص المواصفات نفسه يثبت في غضون أسبوعين، لكن تقارير SecurityWeek تشير إلى أن مهلة التكيف الأمني الكاملة تصل إلى اثني عشر شهراً[^4] — وفي كلتا الحالتين، يرى باحثو Akamai أن هذا الإصدار ينقل المسؤولية الأمنية إلى من يبني فوقه. إذا كنت تقوم ببناء [عملاء MCP](https://nerdleveltech.com/mcp-client-TypeScript-stdio-tools-tutorial) أو خوادم، أو كنت جديداً على [ماهية MCP في الواقع](https://nerdleveltech.com/mcp-servers-explained-claudes-new-ai-backbone-for-real-automation)، فهذه هي اللحظة المناسبة لقراءة سجل التغييرات قبل اعتماده نهائياً. [^6]: Anthropic, ["Introducing the Model Context Protocol"](https://www.anthropic.com/news/model-context-protocol), November 25, 2024. [^1]: Model Context Protocol Blog (David Soria Parra, Den Delimarsky), ["The 2026-07-28 MCP Specification Release Candidate"](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/), May 21, 2026. [^3]: Model Context Protocol Blog (Paul Carleton), ["Enterprise-Managed Authorization: Zero-touch OAuth for MCP"](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/), June 18, 2026. [^2]: Model Context Protocol Blog (Felix Weinberger, Max Isbey, Den Delimarsky), ["Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here"](https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/), June 29, 2026. [^4]: SecurityWeek (Kevin Townsend)، ["New Enterprise-Ready MCP Specification Brings New Security Challenges"](https://www.securityweek.com/new-enterprise-ready-mcp-specification-brings-new-security-challenges/)، ٢٦ يونيو ٢٠٢٦، نقلاً عن أبحاث Akamai الأمنية و Maxim Zavodchik، مدير أول لأبحاث التهديدات في Akamai. [^5]: InfoQ (Matt Saunders)، ["AI Model Context Protocol Adds Centralised Auth for Enterprise"](https://www.infoq.com/news/2026/07/mcp-ema-enterprise-auth/)، ٦ يوليو ٢٠٢٦.