خارطة طريق MCP الجديدة: ماذا تعني لمن يبني عليها؟

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

أهم النقاط - تحدد خارطة الطريق خمس أولويات: مراسلة الوكلاء، ونقل واحد أصيل لـHTTP، وهوية الوكيل وأمن المؤسسات، وبُنى أدوات أولية أنظف، وSDKs تُولّد من المواصفة. - مقترحات المواصفة (SEPs) الواقعة داخل هذه المجالات تحصل على مراجعة أسرع. خارجها، توقّع طابوراً أطول ومعياراً أعلى. - وعود خارطة مارس وصلت إلى حد كبير في مواصفة 2026-07-28: نواة بلا حالة، ونتائج قوائم قابلة للتخزين المؤقت، والطلبات متعددة الجولات. - التغييران الأكثر احتمالاً للمساس بشيفرتك هما هوية الوكيل، عبر DPoP واتحاد هوية أحمال العمل، والاكتشاف التدريجي للأدوات في الفهارس الكبيرة. - تعامل مع خارطة الطريق كاتجاه، لا كالتزام. المشرفون يقولون ذلك بأنفسهم. لا توقف بناءك بانتظارها.

ماذا أعلن مشرفو MCP فعلاً؟

الحقائق أولاً. خارطة طريق MCP المحدثة، المؤرخة 22 أغسطس 2026، تنظم دورة المواصفة المقبلة حول خمس مناطق ذات أولوية، ولكل منها مشرفون أساسيون مسمّون ومجموعة عمل واحدة أو أكثر وراءها:

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

2. توحيد النقل الأصيل لـHTTP وتقويته: اعتماد Streamable HTTP كربط وحيد، على أن يعمل في النهاية فوق stdio للخوادم المحلية، مع توسيع التخزين المؤقت ليشمل ETags.

3. هوية الوكيل وأمن جاهز للمؤسسات: إنهاء DPoP، أي إثبات الحيازة، وتحديد مسار واضح لهوية الوكلاء والتفويض مبني على معايير IETF القائمة.

4. بُنى أولية محسّنة: إعادة تصميم شكل نتيجة tools/call، وجهد جديد للاكتشاف التدريجي كي يتعلم العملاء فهرس الخادم حسب الحاجة.

5. تجربة تطوير أفضل في SDK: عقد للامتدادات، وتجربة لتوليد حزمة SDK من المستوى 1 وأدلة البدء السريع الخاصة به مباشرة من المواصفة.

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

تحدد خارطة طريق MCP المنشورة في 22 أغسطس 2026 خمس مناطق ذات أولوية للأشهر الستة إلى الاثني عشر المقبلة: مراسلة الوكلاء، ونقل HTTP أصيل، وهوية الوكيل، وبُنى أدوات أولية محسّنة، وSDKs مولّدة من المواصفة. تحصل المقترحات داخل هذه المجالات على مراجعة معجلة، أما المقترحات خارجها فتواجه طابوراً أطول.

لماذا تهم خارطة الطريق هذه؟

لأن السابقة أوفت. خرائط الطريق في المشاريع مفتوحة المصدر الشابة كثيراً ما تكون وثائق طموح تشيخ بهدوء. هذه لديها سجل. حددت خارطة مارس 2026 أربع أولويات، ووصل معظمها بعد خمسة أشهر في إصدار مواصفة 2026-07-28:

الاعتماد هو ما يمنح خارطة الطريق وزنها. بحلول يوليو 2026، كانت حزم SDK من المستوى 1 للبروتوكول تسجل قرابة نصف مليار تنزيل شهرياً، وتجاوز كل من TypeScript SDK وPython SDK مليار تنزيل إجمالي. عندما يخبرك بروتوكول بهذا الحجم إلى أين يتجه، تستحق الخارطة القراءة.

المصدر: خارطة طريق MCP في مارس وأغسطس 2026، وإعلان مواصفة 2026-07-28.

وعدت خارطة طريق MCP في مارس 2026 بتطوير النقل، وتواصل الوكلاء، ونضج الحوكمة، والجاهزية للمؤسسات. بعد خمسة أشهر، أطلقت مواصفة 2026-07-28 نواة بروتوكول بلا حالة، وامتداد Tasks، والطلبات متعددة الجولات، وسياسة إيقاف رسمية بمهلة دنيا تبلغ اثني عشر شهراً.

ماذا يعني ذلك إذا كنت تبني على MCP؟

الأثر الفوري على المطورين غير متساو. مجالان من الخمسة سيغيران شيفرتك خلال عام. أما الثلاثة الأخرى فتغير طريقة حوكمة البروتوكول وصيانته من حولك. إليك ترجمة كل مجال إلى أثر عملي.

مراسلة الوكلاء: نهاية الاستطلاع

عمل الوكلاء الحقيقي لا يلائم نموذج الطلب والرد. الوظائف تستمر دقائق، والخوادم تنتهي بينما العميل لا ينظر، والحل الوحيد المتاح للعميل اليوم هو الاستطلاع، وهو مكلف وقبيح. تعطي خارطة الطريق الأولوية لأحداث يبدأها الخادم: قنوات واشتراكات وwebhooks، بحيث يستطيع الخادم إخبار عميلك عندما ينتهي العمل. ومراجعة تركيب هذه القدرات لا تقل أهمية. Tasks وsubscriptions/listen وإشعارات التقدم معرضة اليوم لأن تصبح ثلاثة أجوبة مختلفة على «الخادم لم ينته بعد»، ويريد المشرفون لها أن تشترك في دورة حياة واحدة ونموذج إلغاء واحد وواجهة أخطاء واحدة. إذا كنت تبني أدوات طويلة التشغيل، فهذا هو المجال الذي يستحق مراقبته على Discord.

نقل واحد يتحدث في كل مكان

جعل إصدار 2026-07-28 خادم MCP البعيد عبء عمل HTTP عادياً. تريد خارطة الطريق الآن محو الانقسام بين البعيد والمحلي: Streamable HTTP كربط وحيد، يعمل عبر stdin وstdout للخوادم المحلية، مع استخدام HTTP/2 للتعددية بينما تحتفظ العملية الفرعية بضماناتها الأمنية وضمانات دورة الحياة. اليوم تحتاج كل ميزة أصلية لـHTTP إلى تصميم ثان خاص بـstdio وإلا فلن تعمل محلياً، كما تحافظ SDKs على خطي نقل. نموذج نقل واحد يعني قدراً أقل من ذلك. ويتسع التخزين المؤقت أيضاً: ETags فوق تلميحات ttlMs وcacheScope التي وصلت في يوليو، بحيث يمكن إصدار نسخ من نتائج استدعاءات الأدوات بدلاً من جلبها من جديد.

هوية الوكيل: التغيير الذي سيلدغ أولاً

يفترض تفويض MCP وجود شخص أمام متصفح لحظة منح الموافقة. على نحو متزايد، المتصل هو وكيل: عبء عمل سحابي له هويته الخاصة، يعمل نيابة عن مستخدم غير حاضر، أو ينشئ وكلاء فرعيين ينبغي أن يملكوا صلاحيات أضيق من وكيلهم الأب. Honeycomb، كما ورد في إعلان إصدار يوليو، تنسب بالفعل ما يقارب 20% من استعلاماتها التفاعلية الشهرية إلى الوكلاء. وفي الوقت نفسه، ما زال عدد كبير من خوادم MCP في الإنتاج يعتمد على مفاتيح API ملصقة ورموز تحديث طويلة العمر، وهي الممارسة نفسها التي صُمم هذا العمل لإنهائها. الخطة هي إنهاء DPoP واعتماده، مع مسار تفويض قياسي عبر اتحاد هوية أحمال العمل (SEP-1933)، ومنحة ID-JAG التي تقف وراء التفويض المُدار مؤسسياً، وتبادل الرموز وفق RFC 8693، بالتنسيق مع مجموعتي عمل OAuth وWIMSE في IETF.

بُني نموذج تفويض MCP لإنسان يوافق على الوصول في متصفح، لكن الوكلاء أصبحوا هم الجهات المتصلة. تعطي خارطة الطريق الأولوية لـDPoP ولمسار تفويض قياسي مبني على اتحاد هوية أحمال العمل وتبادل الرموز وفق RFC 8693، كي تتمكن الخوادم من التعرف على هويات الوكلاء من دون مفاتيح API ملصقة أو رموز طويلة العمر.

نتائج الأدوات والاكتشاف التدريجي

يُعالج هنا مصدران للالتباس. الأول هو أن tools/call يعيد content وstructuredContent معاً، ما أنتج تطبيقات متباينة لأن مؤلف الخادم لا يستطيع معرفة أي شكل سيعرضه العميل للنموذج. سيعاد تصميم هذا العقد. والثاني هو الحجم: اتصل بخادم لديه مئة أداة، وسيدفع النموذج تكلفة السطح كله قبل أن يطرح المستخدم سؤالاً واحداً، كما تسوء عملية اختيار الأدوات كلما كبرت القائمة. فاتورة الرموز ليست نظرية. في اختبار Cloudflare في فبراير 2026، استهلك عرض API يضم 2,500 نقطة نهاية كتعريفات لأدوات MCP نحو 1.17 مليون رمز، مقابل نحو 1,000 فقط عبر استدعاء الشيفرة. الاكتشاف التدريجي هو الحل المقترح: نقطة دخول صغيرة تكشف أجزاء إضافية من الفهرس كلما ضاقت المحادثة، ومتصلة بعمل التخزين المؤقت أعلاه. كتبت عن متى يجعل هذا الحمل الإضافي API عادية خياراً أفضل. الاكتشاف التدريجي هو محاولة MCP لتضييق الفجوة.

SDKs مولّدة من المواصفة

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

ماذا ينبغي أن تفعل الآن؟

أربعة أشياء، مرتبة حسب الإلحاح:

1. هذا الأسبوع: توقف عن بناء عمل جديد على الواجهات الموقوفة. أُعلن إيقاف Roots وSampling وLogging ونقل HTTP+SSE القديم في مواصفة 2026-07-28، مع مهلة دنيا تبلغ اثني عشر شهراً. ما زالت تعمل. لكن التطبيقات الجديدة لا ينبغي أن تتبناها.

2. هذا الشهر: اجعل خادمك صديقاً للتخزين المؤقت. نتائج القوائم تحمل بالفعل ttlMs وcacheScope، وETags قادمة. الخادم الذي يرسل تلميحات معقولة للتخزين المؤقت اليوم يسبق عملية هجرة واحدة.

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

4. إذا أردت التأثير في البروتوكول: اكتب SEP الخاصة بك داخل مجال ذي أولوية. اطرحها أولاً مع مجموعة العمل المعنية، واجلب دعم تلك المجموعة. المقترحات المتسقة مع خارطة الطريق تحصل على مراجعة معجلة، أما المقترحات خارجها فتدخل الطابور.

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

أوقفت مواصفة MCP بتاريخ 2026-07-28 استخدام Roots وSampling وLogging ونقل HTTP+SSE القديم، مع مهلة دنيا تبلغ اثني عشر شهراً. يؤكد إعلان الإصدار أنها تستمر في العمل خلال هذه الفترة، لكن التطبيقات الجديدة لا ينبغي أن تتبناها.

الصورة الأكبر

ابتعد خطوة وسترى بروتوكولاً ينضج على الملأ. جرى التبرع بـMCP إلى Agentic AI Foundation المحايدة للمورّدين تحت Linux Foundation في ديسمبر 2025، مع OpenAI وBlock كمؤسسين مشاركين. ومنذ ذلك الحين حصل البروتوكول على سُلّم المساهمين ودورة حياة للميزات وسياسة إيقاف، والآن بيان علني يحدد أين يذهب اهتمام المشرفين. إطار الامتدادات يؤدي هنا عملاً هادئاً لكنه حقيقي أيضاً: يسمح SEP-2133 لأي مجموعة العمل بالتجربة داخل مستودع experimental-ext- قبل تقديم مقترح رسمي، فتُختبر الأفكار من دون زعزعة النواة.

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

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

هل أصبح MCP مستقراً بما يكفي للبناء عليه الآن؟

نعم، بشرط الانضباط في الهجرة. أدخلت مواصفة 2026-07-28 سياسة إيقاف رسمية بمهلة دنيا تبلغ اثني عشر شهراً، وتصل SDKs مع ملاحظات هجرة للتغييرات الكاسرة. سيستمر البروتوكول في الحركة، لكنه يخبرك الآن قبل عام عندما يكون شيء تعتمد عليه في طريقه إلى الاختفاء.

ماذا حدث لجلسات MCP؟

أُلغيت في مواصفة 2026-07-28. اختفت مصافحة initialize وترويسة Mcp-Session-Id (SEP-2575 وSEP-2567). كل طلب يصف نفسه الآن، ويحمل إصدار البروتوكول وقدرات العميل داخل _meta، ويحل استدعاء server/discover الاختياري محل المصافحة للعملاء الذين يريدون معرفة القدرات مسبقاً. يمكن لأي طلب أن يصل إلى أي نسخة خلف موازن حمل بالتناوب.

هل ينبغي أن أنتظر المواصفة التالية قبل أن أبدأ البناء؟

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