لدى MCP تقويم إصدارات الآن: ما الذي تعنيه SEP-3398 وServer Cards وموجة أمن أكتوبر بالنسبة لنشر B2B

أهم النقاط

• مواصفة MCP تُصدر الآن وفق تقويم ثابت — SEP-3398، قُبل في 14 أكتوبر 2026، يقرر إصدارًا كل ستة أشهر في آخر ثلاثاء من مارس وسبتمبر، ونقل هدف ديسمبر 2026 إلى أواخر مارس 2027.
• Server Cards أصبحت نهائية — SEP-2127 دُمج بصفته Final في 6 أكتوبر 2026، ويمنح خوادم MCP وثيقة بيانات وصفية معيارية لاكتشاف وسائط النقل وإصدارات البروتوكول وإرشادات الاتصال قبل أن تُنشأ الاتصال.
• 31 إشعارًا أمنيًا خلال 28 يومًا في المستودعات الرسمية — وفق إحصاء State of MCP October من eSEOspace، بينهما إشعاران حرجان في MCP Inspector أُصلحا في الإصدار الأمني 1.0.3 بتاريخ 21 أكتوبر.
• بروكسي Smithery والهوية المُدارة أُطفئا في 31 أكتوبر 2026 — إشعار Smithery ذاته سحب عناوين run.tools وserver.smithery.ai للخوادم — وهو أوضح إثبات في الشهر بأن مسارات التوزيع المستأجرة هي خطر تشغيلي.
• خطط الشتاء كله على المواصفة 2026-07-28 — النواة عديمة الحالة غير متأثرة؛ الإصدار التالي في أواخر مارس 2027، وبذلك تصبح خطوات الترحيل قابلة للإدراج في التقويم بدل ردود الفعل على سجل التغييرات.

أُطفئ بروكسي MCP التابع لـSmithery وخدمة الهوية المُدارة في 31 أكتوبر 2026 — اليوم. وأنهت أي نشرَة وكلاء لا تزال تحل الخوادم عبر عناوين run.tools أو server.smithery.ai بالعمل معها؛ يُدرج إشعار Smithery ذاته ما توقف: عناوين الخوادم المستضافة، الـAPI، وConnect وToolbox، والحسابات، ومفاتيح الـAPI، وواجهة الـCLI. جسر الترحيل هو نُقطة نهاية المزوّد نفسها — mcp.linear.app/mcp بدلًا من linear.run.tools — والفرق التي لم تكن تملك واحدة اضطرت اليوم إلى كتابة واحدة.

في الأيام الـ28 ذاتها، اعتمد مشرفو MCP أول تقويم إصدارات ثابت للبروتوكول، ودمجوا معيار اكتشاف Server Cards بصفته Final، و— وفق إحصاء eSEOspace — سجّلوا 31 إشعارًا أمنيًا في مستودعات MCP الرسمية، اثنان منهما صُنفا حرجين في MCP Inspector.

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

هذه الورقة بنيت على MCP 2026-07-28: ماذا يعني البروتوكول عديم الحالة لنشر وكلاء B2B التي غطت النواة عديمة الحالة ونمط المقابض الصريحة وحسابات نشر مواصفة 28 يوليو. التركيز هنا على ما تغيّر حول تلك المواصفة في أكتوبر — الإيقاع، وطبقة الاكتشاف، وتدفق الإشعارات، وانقطاع التوزيع. وأطروحة عدم الحالة ذاتها لم يمسّها أي من ذلك.

سجل أكتوبر في نظرة واحدة

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

تقويم إصدارات قُبل ثم اكتمل

SEP-3398 هو SEP إجرائي، ووثائق SEP الإجرائية نادرًا ما تصل إلى العناوين — لكن هذه كان ينبغي أن تبلغها. قُبل في 14 أكتوبر ودُمج في 27 أكتوبر، وقد ثبّت إيقاع إصدارات MCP كتابةً: إصدارات مواصفة كل ستة أشهر، «عادة في آخر ثلاثاء من مارس ومن سبتمبر»، مع دورة عمل من ثمانية أشهر لكل إصدار — شهران من التخطيط، ونافذة مراجعة مشرفين أساسيين (Core Maintainer) مجدولة، ومرحلة استقرار — بحيث تتداخل الدورات المتعاقبة بمقدار شهرين. وأتمت فقرة الانتقال الباقي: انتقل هدف إصدار ديسمبر 2026 المقترح إلى أواخر مارس 2027.

لدى المشرفين هذه إدارة لسعة المراجعة. ولدى نشرَة B2B هذه بنية تحتية للتخطيط:

• نوافذ الإهمال صارت قابلة للتخطيط في التقويم. Roots وSampling وLogging ووسيط النقل المهجور HTTP+SSE كانت تحمل بالفعل نافذة تعليقات توضيحية مدتها 12 شهرًا من مواصفة 28 يوليو. التقويم الثابت يحوّل «12 شهرًا من 28 يوليو» إلى محطة على خارطة الطريق ذاتها لنوافذ إصدارات أنظمة ERP.
• العمل غير المكتمل يُلجأ إلى وقت لاحق، والتاريخ لا يتحرك. يجب أن تكون المقترحات المقيّدة بالإصدار Final ومُدمجة قبل soft freeze؛ والمقترحات غير المكتملة تؤجل إلى دورة لاحقة دون تحريك تاريخ الإصدار. هذا هو السلوك الذي تتوقعه الفرق من مزودي المنصات — قابلية الاستباق قبل الاكتمال.

والمقولة العملية الفورية هي التي استخلصها eSEOspace من بيانات أكتوبر: لم يُصدر أي إصدار جديد من المواصفة في أكتوبر — الأحدث ما يزال 2026-07-28، والتقويم ينقل التالي إلى أواخر مارس 2027. فالنواة عديمة الحالة التي تستهدفها نشرَتك اليوم صالحة طوال الشتاء.

Server Cards: اكتشاف توقف عن كونه ملف إعداد

SEP-2127 (MCP Server Cards) دُمج بصفته Final في 6 أكتوبر — قبل SEP التقويم — وأغلق النصف الثاني من مسألة النشر. عرفت المواصفة عديمة الحالة كيف يتحدث الوكيل مع الخادم بعد اتصاله. وتُعرّف Server Cards كيف يجد الوكيل الخادم دون إعداد يدوي: وثيقة بيانات وصفية معيارية تصف وسائط النقل وإصدارات البروتوكول وإرشادات الاتصال، يكشفها الخادم ويقرأها العملاء قبل أن تنفتح أي اتصال.

الآلية، من SEP نفسه: يكشف كل خادم بطاقته — ويمكن استضافة البطاقات على أي URI غير محجوز، مع <streamable-http-url>/server-card كموقع موصى به — تحت معرف الامتداد io.modelcontextprotocol/server-card. ويمكن لـ«AI Catalog» على مستوى النطاق أن يربط البطاقات ذات الصلة أو يضمّنها، وهو ما يجعل زحف الأدلة والاكتشاف التلقائي للخدمات ممكنًا دون لمس كل نُقطة نهاية يدويًا.

المقابل في B2B هو بطاقة الوكيل في A2A — .well-known/agent-card.json — التي تغطيتنا لـA2A تعاملها بالفعل كخط الأساس لاكتشاف آلة-إلى-آلة. وServer Card هي الفكرة ذاتها لخوادم البروتوكول، وهي تحذف الأثر الذي تحتفظ به معظم نشرات الوكلاء اليوم: القائمة المكتوبة يدويًا لعناوين نهاية الخوادم ومخططات أدواتها. وحين تصبح تلك القائمة بيانات وصفية قابلة للاكتشاف، تتغير الموقف التشغيلي في ثلاثة اتجاهات — الخوادم الجديدة تُعلن عن سطحها بنفسها؛ وتصبح العناوين القديمة قابلة للتدقيق (البطاقة التي لم تعُد تطابق الخادم العامل هي نتيجة بذاتها)؛ وتتوقف ترقيات المزوّدين عن اشتراط إعادة الضبط على جانب العميل.

دعم SDK والعملاء هو الخطوة التالية المعلَنة في SEP، فالخطوة العملية هي التصميم من الآن لذلك: ابنِ العناوين مع مراعاة موقع البطاقة، وأبقِ قائمة الخوادم جاهزة لتحوّلها إلى بيانات وصفية بدل الإعداد.

موجة أمن أكتوبر: الإشعارات جزء من إيقاع التشغيل

أحدّ صفوف سجل أكتوبر هي صفوف الأمن، وتُقرأ كيوم تصحيحات لدى مزوّد منصة لا كسجل تغييرات لمشروع هاوٍ. صدر إشعاران حرجان في MCP Inspector بتاريخ 21 أكتوبر، وكلاهما أُصلح في الإصدار الأمني 1.0.3:

• GHSA-6x67-4w4w-9f3w — يمكن لتطبيق MCP عن بُعد سرقة رمز وسم البروكسي وتنفيذ أوامر محلية إرادية (RCE). الإصدارات المتأثرة: Inspector من 0.20.0 إلى 1.0.2.
• GHSA-4fc4-wcmh-4g86 — يمكن لـcallback OAuth خبيث في MCP تبديل وسيط النقل إلى stdio وتنفيذ أوامر محلية إرادية (RCE). الإصدارات المتأثرة: من 0.13.0 إلى 1.0.2.

وخارج Inspector، إشعار TypeScript SDK لأكتوبر هو الأشد أثرًا في B2B: GHSA-jm63-cq47-j5jp — «نقل مشترك أو مثيلات خادم أوصلت رسائل عميل HTTP إلى عميل آخر» — صنف عالي الخطورة، متأثر من 2.0.0 وأُصلح في 2.3.0. تسرب بيانات بين العملاء عبر نقل مشترك بالفعل هو صنف العيوب التي لا تحتملها نشرَة B2B، وقد وقع في الحزمة الأساسية للـSDK لا في زاوية تجريبية.

تقول تواريخ الإصدار الحكاية المنصية بوضوح مماثل للشدة. صدر Python SDK 2.3.0 في 2 أكتوبر مع فحوصات ترويسات أشد صرامة عند تسجيل الأدوات؛ وصدر TypeScript SDK 2.4.0 في 23 أكتوبر مضيفًا دعم Skills-over-MCP (SEP-2640)؛ وصدر Kotlin 0.16.0 في 27 أكتوبر سادًّا ثغرات استنزاف الذاكرة وعمل SSE على أنه مهجور (الإصدار؛ الوصف وفق مراجعة eSEOspace لملاحظات الإصدار). وقد صدرت كل مكتبات SDK الرسمية الكبرى مرة على الأقل خلال الشهر، ووفق مراجعة eSEOspace فإن الموضوع المشترك هو التصلب: حدود صارمة لحجم الطلب وعدد الجلسات والذاكرة. وإحصاؤهم للإشعارات عبر المستودعات الرسمية — 31 في 28 يومًا — هو حصرهم الخاص، إلا أن الشكل الذي يصفه قابل للتحقق: مسار الإصدارات الأمنية أصبح متواصلًا لا متقطعًا.

قراءة المشغّل بسيطة. فإن كان لدى أموال MCP لديك سياسة تحديث لـSDK، فإن أكتوبر هو الشهر الذي اضطرت فيه السياسة إلى العمل مرتين. وإلا، فالإشعارات أعلاه هي ما يتراكم.

Smithery: انتهى عقد طبقة التوزيع

الحدث الثالث هو الذي يشعر به فريق التشغيل لديك اليوم. إشعار Smithery لا لبس فيه: في 31 أكتوبر 2026 أطفأت Smithery خدماتها لإدارة الاتصالات — أي أن كل عنوان خادم من run.tools وserver.smithery.ai، ومسار البروكسي المستضاف، والـAPI، والحسابات، ومفاتيح الـAPI، وواجهة الـCLI توقفت عن العمل. ويظل دليل smithery.ai متصلًا بوصفه دليلًا عامًا، ويشغّله الآن Arcade.dev.

الترحيل مباشر للخوادم ذات نقاط النهاية الأصلية من المزوّد — مثال Smithery نفسه هو وجّه إلى mcp.linear.app/mcp بدل linear.run.tools. وهو تمرير سريع للنشرات التي بُنيت على بروكسي بوصفه استراتيجية توزيع: لا عنوان أصلي من المزوّد، ولا عقد على ما يحل محله في مستوى التحكم لديك، ولا تدقيق على من يتصل بعد أن زال البروكسي الذي كان يسجل حركة البيانات.

يتعمم الدرس خارج مزوّد واحد: فإن كان العنوان الذي تحل عبره أسطول الوكلاء خوادم MCP يخص طرفًا ثالثًا، فإن دورة حياة ذلك العنوان هي تبعية لم تخترها ولم تتتبعها. وقد قدّم أكتوبر ذلك الإثبات في الشهر نفسه الذي وُحدت فيه بيانات الاكتشاف الوصفية للبروتوكول وثُبّت تقويم إصداراته. والموقف الدائم هو العناوين الأصلية من المزوّد، وفق إرشادات الترحيل من Smithery ذاتها، أو العناوين التي يشغّلها فريقك — فيما هو خط buy-vs-build الذي يرسمه تحليلنا لحماية خوادم MCP للحافة، ويبرهن سجلّنا هذا عليه في التوزيع.

قائمة التدقيق التشغيلية لنشرات B2B على MCP

التسمية التوضيحية: ستة ضوابط تحوّل إشارة أكتوبر إلى سياسة نشر — يستجيب كل منها لحدث مؤرخ من الشهر.

#	الضابط	حدث أكتوبر الذي يستجيب له	مظهره في النشر
1	ثبّت إصدار المواصفة	لا إصدار جديد من المواصفة في أكتوبر؛ الإصدار التالي أواخر مارس 2027	استهدف 2026-07-28 صراحةً؛ وشغّل مكتبات SDK تعلن دعم ذلك الإصدار؛ وراجع التثبيت عند كل محطة تقويمية
2	أدخل محطات الإصدار في التقويم	SEP-3398: آخر ثلاثاء من مارس ومن سبتمبر	ضَع soft freeze (قبل الإصدار بـ2.5 شهرًا) وhard freeze (قبلها بشهر) في خريطة طريق الفريق كنوافذ مراجعة، لا كمفاجآت
3	ابقَ على مسار الإصدارات الأمنية للـSDK	31 إشعارًا في أكتوبر؛ إشعاران حرجان في Inspector 1.0.3	ثبّت حدها الأدنى للمكتبات عند الإصدار الأمني (TS ≥ 2.3.0، Inspector ≥ 1.0.3)؛ واشترك في تدفقات الإشعارات للمستودعات الرسمية
4	فضّل العناوين الأصلية من المزوّد أو ما تشغّله بنفسك	نهاية دعم run.tools / server.smithery.ai لدى Smithery في 31 أكتوبر	أعدّ قائمة بكل عنوان غير أصلي من المزوّد في قائمة الخوادم؛ وأنهِ المسارات المعتمدة على البروكسي أو شغّلها بنفسك
5	صمّم من أجل بيانات Server Cards الوصفية	SEP-2127 أصبح Final في 6 أكتوبر، ودعم SDK/العملاء لاحقًا	صمّم العناوين مع مراعاة موضع البطاقة؛ وأبقِ قائمة الخوادم جاهزة لتصبح بيانات وصفية قابلة للاكتشاف لا إعدادًا
6	عامل الإدراج في السجل بوصفه غير مدققًا	52,141 خادمًا في السجل الرسمي، و66% منها يقدم عناوين بعيدة (وفق إحصاء eSEOspace)	الإدراج ليس إشارة أمانًا؛ وطبّق بوابة اعتماد الوحدات من قائمة ضبط الحوكمة قبل أن يتصل خادم من طرف ثالث

ماذا يترك هذا لنمط النشر 2026-07-28

النواة عديمة الحالة التي أرسته تحليلنا السابق هي جزء MCP الذي لم يمسه أكتوبر — وهي النقطة التي يستحق أن تُقال صراحةً. يعيد SEP-3398 جدولة الإصدارات القادمة؛ ولا يخل بمواصفة ثبّتها طوال الشتاء. وتضيف Server Cards اكتشافًا دون تغيير النقل. وتصلّب الإشعارات مكتبات SDK على إصدار البروتوكول ذاته. وإطفاء Smithery قرار تجاري من طرف ثالث، لا حدث بروتوكول.

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

قراءة ذات صلة

• MCP 2026-07-28: ماذا يعني البروتوكول عديم الحالة لنشر وكلاء B2B — التحليل الأم: النواة عديمة الحالة، ونمط المقابض الصريحة، وحسابات نشر مواصفة 28 يوليو، إضافة إلى مقترح Server Cards في حالته السابقة للنهائية
• أمن MCP: الوحدات المحوَّمة — طبقة الحوكمة التي تحوّل تدفقات الإشعار والاعتماد إلى ضوابط على مستوى الوحدة
• حماية خوادم MCP: شراء أم بناء — سؤال الحافة الذي يوسّعه سجل أكتوبر نحو التوزيع: أي أجزاء مسار الاتصال تخصك

---

نموذج تمثيلي: منصة وكلاء لدى موزع تربط NetSuite وBigCommerce وثلاثة كتالوجات موردين، وتشغّل كل وحدة MCP على عنوان أصلي من المزوّد أو تشغّله بنفسها، مثبتة على مواصفة 2026-07-28، مع محطات إصدار مارس/سبتمبر وتدفقات الإشعارات في دفتر التشغيل — بحيث يكون إطفاء من طريقة Smithery وإصدار أمني من طريقة 1.0.3 تذاكر اعتيادية لا انقطاعات. ويتبع هذا النموذج منهج Discovery → Governance → Automation → Expansion من أربع خطوات ويعمل خلال 5–8 أسابيع عادةً.

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