إصدار MCP بتاريخ 28-07-2026: إعادة النظر في التطبيقات والمهام وحوكمة البوابة في ظل أكبر مراجعة للبروتوكول منذ إطلاقه

في أواخر شهر يوليو، نشرنا تحليلنا حول حوكمة تطبيقات ومهام MCP عند البوابة — وسرعان ما فرض البروتوكول موعداً نهائياً لتكملة هذا المنشور. ففي 28 يوليو 2026، صدرت المواصفات النهائية لبروتوكول سياق النموذج (Model Context Protocol) في موعدها المحدد، وذلك بعد أن وصف القائمون على صيانته الإصدار المرشح — في ثماني كلمات نقتبسها مرة واحدة — بأنه "أكبر مراجعة للبروتوكول منذ إطلاقه" (إعلان الإصدار المرشح الرسمي). هذا النطاق يستحق الوصف. حيث أصبح الجوهر بلا حالة (stateless): اختفت جلسات البروتوكول وترويسة Mcp-Session-Id، وتم إلغاء مصافحة التهيئة، وأصبحت الطلبات تُوجَّه بناءً على ترويسات Mcp-Method و Mcp-Name، كما أصبحت نتائج القوائم وقراءة الموارد تحمل تلميحات التخزين المؤقت، وبات بإمكان التطبيقات التي تحتاج إلى حالة عبر الاستدعاءات إنشاء مقابض صريحة — مثل basket_id أو ticket_id — يتم إرجاعها بواسطة الأدوات وتمريرها مرة أخرى كمعاملات عادية، وهو نمط يوصي به القائمون على الصيانة بدلاً من الحالة المخفية في النقل لأن النموذج يمكنه رؤية المقبض وتمريره بين الأدوات (ملاحظات الإصدار). تم تقديم إطار عمل للإضافات ، مع معرفات بنظام DNS العكسي ومستودعات ذات إصدارات مستقلة — وتعد الميزتان اللتان حللهما منشورنا في يوليو من بين أوائل الميزات الرسمية: تطبيقات MCP (واجهة مستخدم تفاعلية يتم عرضها من جانب الخادم، ومعزولة في المضيف، حيث تمر استدعاءات الأدوات التي تبدأها التطبيقات عبر مسار الأدوات/الاستدعاء العادي) والمهام، التي انتقلت من النواة التجريبية إلى io.modelcontextprotocol/tasks مع دورة حياة معاد تصميمها تعتمد على الاستطلاع (poll-based) — مثل tasks/get و tasks/update و tasks/cancel التعاونية — وهو تغيير جذري صريح لأي شخص قام بالتطوير بناءً على واجهة برمجة التطبيقات التجريبية بتاريخ 25-11-2025 (تحليل الترحيل الخاص بـ WorkOS؛ ملاحظات التغييرات الجذرية الخاصة بـ BOVO). تم تعزيز التفويض ليتماشى مع ممارسات OAuth/OIDC المطبقة عبر ستة مقترحات تحسين (SEPs)، وتم إيقاف تسجيل العميل الديناميكي (Dynamic Client Registration) لصالح CIMD، واكتسب البروتوكول دورة حياة رسمية لإيقاف الميزات: حيث أصبحت الجذور (Roots) وأخذ العينات (Sampling) والتسجيل (Logging) و DCR مؤهلة للإزالة في موعد لا يسبق الإصدار الصادر في أو بعد 28 يوليو 2027، بينما يتبع بروتوكول النقل القديم HTTP+SSE — الذي تم إيقافه منذ عام 2025 — جدول الانتقال المنشور بشكل منفصل لسياسة دورة الحياة (سجل الميزات الموقوفة). كان الاعتماد منذ اليوم الأول: تدعم جميع حزم تطوير البرمجيات (SDKs) الأربع من المستوى الأول المواصفات الجديدة عند الإصدار، وكانت AWS وGoogle Cloud وMicrosoft وCloudflare من بين الجهات الداعمة للإطلاق، كما أن Claude وClaude Desktop من بين المضيفين الذين يقومون بالفعل بتشغيل تطبيقات MCP (منشور الإصدار؛ وثائق التطبيقات). لا تزال أطروحة منشورنا في شهر يوليو - بأن التطبيقات والمهام تفتح كل منها مساحة حوكمة يجب على البوابة إغلاقها - قائمة دون تغيير في المراجعة. لكن المواصفات النهائية تضيف فروقاً دقيقة لم تكن لدينا آنذاك، ثلاثة منها تغير الطريقة التي يجب أن تقرأ بها المؤسسة بيئة MCP الخاصة بها هذا الربع. هذا المنشور هو المراجعة الموعودة: ما الذي تغير بين المواصفات التي كُتب منشورنا بناءً عليها وتلك التي تم إصدارها للتو، وما قبل/بعد في رسم بياني واحد، وعمل الحوكمة الجديد الذي يخلقه كل تغيير.

1. ما قبل وما بعد: ما الذي تغير فعلياً

كُتب منشورنا في شهر يوليو بناءً على عالم 25-11-2025: بروتوكول ذو حالة (جلسات ثابتة، مصافحة تهيئة، رؤوس معرف الجلسة التي كان على البوابات تتبعها)، والمهام كميزة أساسية تجريبية، وتطبيقات MCP التي تتطور بشكل منفصل كملحق بموجب عملية ملحقات لا تزال غير رسمية، والإشعارات عبر تدفق HTTP GET قديم، وقصة تفويض لا تزال تتمحور حول تسجيل العميل الديناميكي. يستبدل الإصدار النهائي بتاريخ 28-07-2026 كل ركيزة من تلك الركائز، والتأثير العملي على طوبولوجيا الإنتاج فوري: خادم MCP عن بُعد كان يحتاج إلى جلسات ثابتة ومخزن جلسات مشترك يمكنه الآن العمل خلف موازن تحميل عادي بنظام التوزيع الدوري (round-robin) مع قوائم أدوات قابلة للتخزين المؤقت - لقد تمت إعادة تشكيل البروتوكول ليناسب بنية HTTP التحتية العادية، وهو بالضبط ما تعنيه "درجة المؤسسات" على مستوى طبقة النقل (إعلان إصدار المرشح (RC)). يقدم الرسم البياني والجدول أدناه التغيير في لمحة سريعة؛ هناك ثلاثة صفوف تستحق العلامة التي وضعناها عليها. انتقال المهام إلى الملحق هو تغيير جذري - واجهة برمجة التطبيقات التجريبية بتاريخ 25-11-2025 التي وصفها منشورنا لا تستمر، وتحتاج الخوادم الداخلية المبنية عليها إلى تدقيق الآن. عمليات الإيقاف التدريجي لطيفة ولكنها مؤرخة، مع توقيتات لكل ميزة - بموجب دورة حياة "نشط ← متوقف ← مُزال" الجديدة، تستمر الجذور (Roots) وأخذ العينات (Sampling) والتسجيل (Logging) وDCR في العمل لمدة اثني عشر شهراً على الأقل وتصبح مؤهلة للإزالة في موعد لا يسبق المراجعة الصادرة في أو بعد 28 يوليو 2027، بينما يتبع نقل HTTP+SSE القديم، المتوقف منذ عام 2025، قاعدة الانتقال الخاصة بسياسة دورة الحياة ويجب تتبعه في جدول الإزالة المنشور بشكل منفصل (سجل الميزات المتوقفة المعياري). ويقع تعزيز التفويض جزئياً على جانب العميل - الدفاع ضد هجمات الخلط الذي تعطي الأولوية له التحليلات الأمنية (SEP-2468) هو عمل يخص العميل، وهو أمر مهم فيما يتعلق بمن يقوم بتنفيذه فعلياً داخل المؤسسة، وهي نقطة يعود إليها القسم 3.

2. ثلاث فروق دقيقة نضيفها إلى تحليلنا في يوليو

حيثما تحتاج التطبيقات إلى الاستمرارية، تحل المقابض الصريحة محل حالة النقل المخفية - وهي تعيش في النص. الخطوة الأنيقة للتصميم عديم الحالة هي أن السياق الذي يختار الخادم الاحتفاظ به ينتقل الآن كمقبض صريح يمرره النموذج كحجة عادية، وهو نمط يوصي به القائمون على الصيانة بدلاً من الحالة المخفية في النقل لأن النموذج يمكنه رؤية المقبض، والتفكير فيه، وربطه بين الأدوات (ملاحظات الإصدار الرسمية). الفروق الدقيقة في الحوكمة التي لم يكن بوسع منشورنا في يوليو صياغتها: المقبض (handle) في سياق النموذج هو أداة تشبه الصلاحيات في نص عادي — عبارة عن basket_id أو ticket_id يحدد حالة مباشرة على جانب الخادم، وتكون مرئية لكل ما يمكنه قراءة النص، وتستمر عبر عمليات الضغط أو لا، اعتماداً على بيئة التشغيل. يعتمد كون المقبض الذي تم التقاطه قابلاً لإعادة التشغيل على الخادم: يصبح المقبض حساساً أمنياً عندما يكون مجرد امتلاكه كافياً لاستعادة أو تعديل حالة جانب الخادم، لذا يجب على الخوادم التعامل معه ككيان غامض، وتفويض كل استخدام له مقابل صاحب الصلاحية الحالي، وتجنب تضمين أسرار فيه، وتسجيله أو حجب بياناته وفقاً للسياسة المتبعة. وبذلك، تنضم المقابض إلى بيانات الاعتماد في قائمة الأشياء التي يجب أن يربطها تتبع مستوى الطلب بأصحاب الصلاحية: من الذي أنشأ هذا المقبض، وبموجب سلطة من، وهل يقدمه المتصل ضمن سير العمل الذي أُنشئ من أجله. تحول المهام الصلاحية الزمنية من مشكلة نظرية إلى سلوك مصمم. لقد جادل عملنا الخاص بنشر التفويض بأن سير العمل الطويل يعيش لفترة أطول من منح صلاحياته؛ وتجعل إضافة المهام (Tasks) الرسمية ذلك هو الشكل المتوقع — يستمر العمل على جانب الخادم بينما يقوم العميل باستطلاع tasks/get — لذا فإن السؤال "هل التفويض الذي بدأ هذه المهمة لا يزال صالحاً عند اكتمالها؟" أصبح الآن له مكان قياسي ليُطرح فيه، وفي الإضافة نفسها، لا توجد إجابة إلزامية. لذا فإن سلامة نمط العمل غير المتزامن هي مسؤولية التطبيق: يجب على التنفيذات الاحتفاظ بارتباط بين كل مهمة وصاحب الصلاحية وسياق التفويض الذي أُنشئت تحته، ونسب التكلفة إلى المهمة، ونشر الإلغاء إلى العمل الجاري — مع تذكر أن tasks/cancel هو إجراء تعاوني، لذا يقر الخادم بالقصد ولكنه غير ملزم بإيقافه (إضافة المهام (Tasks)). التطبيقات هي واجهة للتصيد الاحتيالي مع ميزة منقذة. التحليلات الأمنية محقة في أن واجهة المستخدم المعروضة من جانب الخادم داخل إطار العميل الموثوق تخلق مساراً للتصيد الاحتيالي يستهدف المستخدم — وهي مشكلة الواجهة الموثوقة (تقييم Akamai) — ومحقة في أن المحتوى المعروض يجب أن يُعامل كغير موثوق به ويتم عزله في بيئة حماية (sandbox). الميزة المنقذة هي معمارية، مع وجود حدود تستحق الرسم بدقة: يتحدث التطبيق ومضيفه بلغة JSON-RPC الخاصة بـ MCP عبر postMessage، حيث تكون بعض الرسائل عمليات MCP عادية مثل tools/call، ومعظمها رسائل ui/* خاصة بالتطبيق (وثائق التطبيقات). يتم إعادة توجيه استدعاءات الأدوات التي يطلبها التطبيق بواسطة المضيف كطلبات tools/call عادية — لذا فإن النقرة التي تؤدي إلى إجراء على جانب الخادم هي ليست قناة جانبية؛ فهي تصل إلى نفس الطبقة الخاضعة للحوكمة مثل الاستدعاء المباشر، حيث توجد بالفعل الموافقة والسياسة والتدقيق. في المقابل، لا تغادر حركة مرور ui/* أبداً العميل الذي يقوم بالعرض، والذي يحتفظ بالتزامات بيئة الحماية والقائمة المسموح بها الخاصة به. تتدفق واجهة استدعاء الأدوات إلى نقطة الاختناق؛ بينما تبقى واجهة المستخدم عند الحافة — وكلاهما يحتاج إلى حوكمة، كل في مكانه.

3. ربع الترحيل: حيث تثبت البوابة قيمتها

هنا يأتي دور TrueFoundry، حيث تعمل المواصفات النهائية على صقل الدور الذي حددناه في منشور شهر يوليو للبوابة بدلاً من تغييره، وتحديداً لـ بوابة MCP: عندما يكون البروتوكول نفسه في مرحلة ترحيل، تصبح الطبقة التي تمر عبرها كل استدعاءات MCP الموجهة ثلاثة أشياء في آن واحد. المخزون. السؤال الأول في أي عملية ترحيل — من يشغل ماذا — لا يمكن الإجابة عليه من خلال الاستبيانات، بل يمكن استنتاجه من حركة المرور، لأن طلبات MCP الحديثة تحمل إصدار البروتوكول، وهوية العميل، والقدرات، وبيانات تعريف الطريقة في كل استدعاء. تحويل ذلك إلى مخزون ترحيل هو عمل يتعلق بالسجلات والتقارير، وليس مجرد خيار جاهز: توثيق المقاييس العام الحالي لـ TrueFoundry توثيق المقاييس يغطي خوادم MCP، والأدوات، والطرق، والمتصلين، وزمن الاستجابة، والإخفاقات، ومزيج حركة المرور — أي ركيزة الإسناد — ويعد الاحتفاظ بحقول إصدار البروتوكول والعميل ورأس الجلسة من سجلات الطلبات وعرضها فوق ذلك هو أول مخرجات التكوين لهذا الربع. نقطة التنفيذ الموحدة للجميع. إن تعزيز جانب العميل في المواصفات — التحقق من جهة الإصدار (SEP-2468)، وربط بيانات الاعتماد بجهة الإصدار، والانتقال من CIMD بعيداً عن DCR — هو عمل كان سيقوم به كل مستهلك لـ MCP بشكل منفصل وغير متسق. حيث تعمل البوابة كعميل MCP للمؤسسة وتطبق متطلبات 28-07-2026، يمكنها مركزة هذا الوضع مرة واحدة بحيث ترثه كل وكيل خلفها — وهو نفس منطق التوحيد الذي بنيناه في تحليلنا لـ OAuth على مستوى طبقة MCP لمعالجة الرموز المميزة، وهو مناسب تماماً لـ تكاملات Okta و Azure AD وإدارة بيانات الاعتماد المركزية التي توثقها TrueFoundry اليوم؛ يجب التحقق من دعم كل متطلب جديد للمواصفات مقابل إصدار البوابة المنشور. المكان الذي تحصل فيه الواجهات الجديدة على السياسات. هنا يهم الخط الموثق/الموصى به، لذا قمنا برسمه. توثق TrueFoundry حالياً مصادقة MCP المركزية، والتحكم في الوصول على مستوى الخادم والأداة، والموافقات على الأدوات، وضوابط ما قبل وما بعد استدعاء الأداة حواجز الحماية، وتتبع الطلبات، ومقاييس MCP — وهي ضوابط تنطبق على كل أداة/استدعاء يعبر البوابة، بما في ذلك الاستدعاءات التي يبدأها تطبيق MCP من خلال مضيفه. تعيش عمليات حماية التطبيقات (sandboxing) وقوائم السماح في عميل العرض؛ بينما تعد هوية دورة حياة المهمة، وتخصيص الميزانية لكل مهمة، والإلغاء الذي يصل إلى العمل الجاري، وربط المقبض بالهوية الرئيسية هي ضوابط الحوكمة التي يوصي بها هذا الإصدار — وهي بنية مرجعية للبناء على تلك الركيزة الموثقة، وليست ميزات منفصلة يتم شحنها. لم يتطلب أي من هذا تغيير المواصفات — وهو ما يمثل إثباتاً هادئاً يستحق الذكر بوضوح: لقد غيرت مراجعة 28-07-2026 حدود أمان البروتوكول بشكل كبير (اختفت الجلسات، وتم نقل المصادقة، وظهرت واجهات توسعة جديدة)، والمؤسسة التي كانت حوكمتها تعيش في طبقة البوابة تواجه الكثير من هذا التغيير كإجراء تكويني، بينما المؤسسة التي كانت حوكمتها تعيش في منطق الجلسة لكل خادم ورمز المصادقة لكل عميل تقوم الآن بترحيل ضوابطها جنباً إلى جنب مع بروتوكولها. إن القيمة الحقيقية لحوكمة نقطة الاختناق هي أن نقطة الاختناق تعيش أطول من إصدارات المواصفات التي تمر عبرها — وهذه هي أول مراجعة لـ MCP كبيرة بما يكفي لاختبار ذلك.

4. الحدود، بوضوح تام

المصادر والقيود. إن تغييرات المواصفات — النواة عديمة الحالة، وإطار عمل الإضافات، وإعادة تصميم المهام وحالتها التي تكسر التوافق، وآليات التطبيقات، ومقترحات تفويض MCP (SEPs)، وعمليات الإيقاف، والجداول الزمنية، وحقائق الاعتماد — موثقة كما ورد في منشورات إصدار MCP الرسمية، وصفحات المواصفات، وسجل الميزات الموقوفة، مع استخدام التحليلات المذكورة (WorkOS وStacktree وAkamai وAAIF وBOVO) للتفسير وتجربة الترحيل والتعليق الأمني؛ تمت إعادة صياغة كل شيء بالكامل مع اقتباس واحد يقل عن خمس عشرة كلمة منسوب إلى القائمين على الصيانة. المواصفات لم يمضِ على صدورها سوى أسبوع واحد عند كتابة هذا النص، وستستقر تفاصيل التنفيذ خلال الأشهر القادمة، لذا يجب على القراء اعتبار المواصفات الرسمية وسجل التغييرات المرجع المعتمد فوق أي ملخص، بما في ذلك ملخصنا. نحن نعيد زيارة منشورنا الصادر في يوليو، ولا نتراجع عنه — فإطار الحوكمة الخاص به لا يزال سارياً؛ وحيثما يختلف هذا المنشور، فإن هذا المنشور هو المعتمد. اهتمامنا هو ما أفصحنا عنه: نحن نبيع طبقة بوابة MCP التي يجادل هذا المنشور بأن الترحيل يصب في مصلحتها، والادعاء مقيد وفقاً لذلك — فالبوابة تحكم حركة المرور التي تعبرها فعلياً، وتوحد التزامات جانب العميل حيث تعمل كعميل MCP للمؤسسة، وتراقب ما توجهه؛ لكنها لا تقوم بترقية الخوادم نيابة عنك، ولا تجعل ترحيل المهام اختيارياً للمؤسسات التي اعتمدت واجهة برمجة التطبيقات التجريبية، ولا ترى حركة مرور ui/* الخاصة بمضيف التطبيق، ولا تغني عن عمل وضع الحماية (sandboxing) الذي تتطلبه التطبيقات في عميل العرض. هناك قيدان صريحان. أولاً، التحسينات الأمنية في المواصفات حقيقية وعلى مستوى البروتوكول — فقد تمت إزالة سطح الهجوم الخاص بتثبيت معرف الجلسة واختطافها على مستوى البروتوكول تماماً، ولا يمكن إصدار الطلبات التي يبدأها الخادم إلا أثناء معالجة الخادم لطلب العميل، بحيث يمكن تتبع كل استجابة وصولاً إلى شيء بدأه المستخدم أو وكيله — مما يعني أن بعض ما كانت البوابات تعوضه قد تم إصلاحه ببساطة؛ والإنصاف يقتضي القول إن قائمة مهام البوابة قد تغيرت، ولم تزدد فحسب. ثانياً، حوكمة الإضافات لا تزال في مهدها: فما هي الإضافات التي تسمح بها المؤسسة، لكل فريق، هو سطح سياسات ينشئه إطار العمل ولا يمتلك أحد ممارسة ناضجة له بعد — ونتوقع إعادة النظر في ذلك أيضاً. ما يسمح الأسبوع بالقول بوضوح: لقد قدم البروتوكول للتو عرضه ليكون بنية تحتية — عديم الحالة، وقابل للتوسيع، مع عمليات إيقاف مؤرخة، ومصادقة متوافقة مع المؤسسات — وبروتوكولات مستوى البنية التحتية تستحق حوكمة بمستوى البنية التحتية، وهي الأطروحة التي جادل بها منشورنا في يوليو، والتي قامت مواصفات يوليو، بكل امتنان، بجعلها أكبر.

المراجع

• المصادر الأولية — القائمون على صيانة MCP، "مواصفات 28-07-2026" (النواة عديمة الحالة؛ توجيه الرأس؛ تلميحات التخزين المؤقت؛ تغييرات التفويض؛ المهام وSEP-2663؛ الاشتراكات/الاستماع؛ الإيقاف؛ حالة حزمة تطوير البرمجيات (SDK) في اليوم الأول وتأييد الإطلاق)؛ منشور إصدار المرشح (release-candidate) (التوصيف المقتبس؛ مقترحات تفويض MCP الستة؛ MRTR وSEP-2260؛ نمط المعالجة؛ الطوبولوجيا عديمة الحالة)؛ سجل الميزات الموقوفة المعياري (أهلية الإزالة لكل ميزة، بما في ذلك الجدول الزمني المنفصل لـ HTTP+SSE)؛ توثيق تطبيقات MCP (لهجة JSON-RPC، رسائل ui/*، نموذج وضع الحماية، دعم العميل)؛ إضافة المهام (دورة الحياة، تحديث المهام/tasks/update، الإلغاء التعاوني). التحليلات — WorkOS (تحليل الترحيل)؛ Stacktree (تفاصيل سجل التغييرات؛ أعداد الاعتماد والموصلات)؛ أبحاث أمن Akamai (مسارات إساءة استخدام جديدة)؛ دليل ترحيل AAIF؛ BOVO (تجربة ترحيل المؤسسات).
• توثيق TrueFoundry — بوابة MCP (مخطط البنية الرسمي)؛ مصادقة وأمن MCP؛ ضوابط الحماية، بما في ذلك تدفق استدعاء الأدوات (مخطط رسمي)؛ الميزانيات; التحليلات.
• هذه المدونة — التحليل الذي أُجري في يوليو والذي تعيد هذه التدوينة تناوله; إدارة OAuth والرموز المميزة في طبقة MCP; بوابة MCP مقابل الوكيل مقابل الموجه; نواقل MCP في المؤسسات; تسميم الأدوات ودفاع البوابة; سجل MCP المركزي.

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

‍