[ مقال تقني ]•أنظمة الوكلاء الذكية•

٢٨ أغسطس ٢٠٢٦

•٧ دقائق قراءة

بروتوكول MCP يتخلى عن الجلسات: ماذا يعني إصدار 2026-07-28 لخوادمك؟

معظم تحديثات البروتوكولات تضيف مزايا جديدة. أما إصدار 2026-07-28 من بروتوكول Model Context Protocol فقد فعل العكس: حذف ميزة — وهي تحديدًا الميزة التي بُنيت حولها كل خوادم MCP القائمة.

اختفت مصافحة initialize/initialized، واختفت معها ترويسة Mcp-Session-Id. صار قلب البروتوكول عديم الحالة (Stateless): كل طلب مكتفٍ بذاته، يحمل إصدار البروتوكول وهوية العميل وقدراته. وفي 22 أغسطس 2026، نشر المشرفان الرئيسيان David Soria Parra وDen Delimarsky خارطة طريق تحدد ما سيأتي لاحقًا.

إن كنت تُشغّل خادم MCP، فهذه ترحيلة (Migration) لا يمكن تجاهلها. وإليك ما تغيّر فعليًا، وما ثمنه عليك.

ما الذي حدث؟

كان نموذج النقل الأصلي في MCP قائمًا على الحالة. يفتح العميل جلسة عبر initialize، فيصدر الخادم معرّف جلسة Mcp-Session-Id، ثم يعيد العميل إرساله مع كل طلب لاحق. نموذج سهل الفهم، ومُرهق التشغيل.

فمعرّف الجلسة هذا كان يفرض التوجيه اللاصق (Sticky Routing): يجب أن يصل الطلب إلى النسخة ذاتها التي تحتفظ بالجلسة. وهذا يعني إما مخزن جلسات مشترك، أو بوابة تُجري فحصًا عميقًا للحزم (Deep Packet Inspection) لتعرف إلى أين ترسل جسم JSON-RPC. باختصار: كان التوسّع الأفقي يصارع البروتوكول في كل خطوة.

إصدار 2026-07-28 ألغى الافتراض من أساسه. فبحسب المواصفة الرسمية، صار البروتوكول الأساسي يُعرَّف بأنه طلبات عديمة الحالة ومكتفية بذاتها مع تفاوض على القدرات لكل طلب على حدة.

صار الطلب يبدو هكذا:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

كل ما يحتاجه الخادم موجود داخل هذا الطلب الواحد، ويمكن لأي نسخة خلف موزّع أحمال دوري (Round-Robin) أن تخدمه.

لماذا يهم هذا؟

ثلاث خصائص تشغيلية تنبثق مباشرة من هذا التغيير.

التوسّع الأفقي صار أمرًا عاديًا. لا مخزن جلسات مشترك، ولا جلسات لاصقة، ولا قواعد ارتباط. صارت خوادم MCP تتوسّع كأي خدمة HTTP عديمة الحالة.

البوابات توقفت عن تحليل الأجسام. ترويستا Mcp-Method وMcp-Name الجديدتان تتيحان للبوابات وجدران الحماية (WAF) ومحددات المعدل أن توجّه وتقيس اعتمادًا على الترويسات بدل تفتيش حمولة JSON. أي أن تحديد معدل الاستدعاء لكل أداة صار سطر إعداد في موزّع الأحمال، لا مسؤولية تطبيقية.

البدء البارد (Cold Start) لم يعد قاتلًا. لم تعد عمليات النشر بلا خادم (Serverless) أو ذاتية التوسّع مضطرة لإعادة بناء حالة جلسة تملكها نسخة أخرى.

لكن المقايضة حقيقية: إن كان خادمك يخزّن حالة تطبيقية خلف معرّف الجلسة، فلم يعد لتلك الحالة مكان تتعلق به. وتوجيه المواصفة هنا واضح: أصدر مِقبضًا صريحًا (Handle) من إحدى الأدوات، ودع النموذج يعيده إليك كوسيط. أي أن الحالة تنتقل إلى نموذج مجالك (Domain Model) بدل أن تكون أثرًا جانبيًا لطبقة النقل — أوضح من ناحية التصميم، وأكثر عملًا إن كنت تعتمد على الجلسات.

ما الذي تغيّر بالتحديد؟

الطلبات متعددة الجولات (MRTR)

إلغاء التدفقات المفتوحة يكسر الطلبات التي يبدأها الخادم. فآليات elicitation/create وsampling/createMessage وroots/list كانت جميعها تعتمد على مناداة الخادم للعميل أثناء التنفيذ.

جاءت الطلبات متعددة الجولات (Multi Round-Trip Requests) لتعكس النمط بدل إلغائه. فبدل أن يدفع الخادم طلبًا عبر تدفق مفتوح، يُرجع نتيجة تقول إنه يحتاج مزيدًا:

يستجيب الخادم بـ resultType: "input_required" واصفًا ما يحتاجه.
يعيد العميل الاستدعاء الأصلي، مرفقًا الإجابات في inputResponses.

تأكيدات المستخدم والوسائط الناقصة ما زالت تعمل، لكنها تكلّف جولة إضافية بدل اتصال دائم.

نتائج القوائم القابلة للتخزين المؤقت

صارت tools/list وprompts/list وresources/list وresources/read تحمل بيانات وصفية ttlMs وcacheScope، ما يتيح للعميل تحديد مدة الاحتفاظ بالنتيجة بدل إعادة الجلب مع كل إعادة اتصال. ومع الترتيب الحتمي (Deterministic Ordering)، يستقر أيضًا التخزين المؤقت للموجّهات (Prompt Cache) في الأعلى — وهو توفير مباشر في تكلفة الكلمات الرمزية للعملاء كثيري إعادة الاتصال.

تشديد التفويض

تغييرات التفويض هي الأجدر بالقراءة المتأنية إن كنت تُشغّل MCP في بيئة مؤسسية:

التحقق من المُصدِر وفق RFC 9207: على خوادم التفويض إرجاع الوسيط iss، وعلى العملاء التحقق منه قبل استبدال رمز التفويض. وهذا يغلق ثغرة الخلط بين خوادم التفويض (Mix-Up).
ربط بيانات اعتماد العميل بمُصدِرها: لم تعد قابلة لإعادة الاستخدام عبر مُصدِر آخر.
إضافة application_type عند التسجيل، وهو ما يعالج مشكلة رفض إعادة التوجيه إلى localhost في تطبيقات سطح المكتب وسطر الأوامر.
إهمال التسجيل الديناميكي للعملاء (DCR) رسميًا لصالح مستندات بيانات معرّف العميل (CIMD). لا يزال DCR يعمل، لكن الأعمال الجديدة يجب أن تستهدف CIMD.

إطار رسمي للامتدادات

صارت الوظائف الاختيارية تعيش داخل امتدادات مُسمّاة، اختيارية بالكامل، وتتطلب دعمًا صريحًا من الطرفين. فانتقل امتداد Tasks (io.modelcontextprotocol/tasks) من النواة التجريبية إلى امتداد رسمي، واكتسب tasks/get القائم على الاستطلاع، وطريقة tasks/update الجديدة، وإشعارات التغيير عبر تدفق اختياري subscriptions/listen. أما MCP Apps فيغطي واجهات المستخدم التفاعلية المضمّنة، وEnterprise Managed Authorization يغطي السياسات على مستوى المؤسسة.

نافذة إهمال حقيقية

تلتزم المواصفة بنافذة إهمال لا تقل عن اثني عشر شهرًا. فـ Roots وSampling وLogging مُهملة لكنها تعمل، ولطبقة النقل القديمة HTTP+SSE مهلة خروج مدتها عام كامل. الوقت متاح — لكن العدّاد بدأ في 28 يوليو.

ماذا ينبغي أن يفعل المطورون؟

ابدأ بتدقيق افتراضات الجلسة. المشكلة هنا لا تظهر كخطأ في الترجمة البرمجية، بل كخادم يعمل بنجاح في الاختبار المحلي أحادي النسخة ثم ينهار خلف موزّع أحمال.

# ثلاثة أشياء ستوقعك في المشاكل
grep -rn "Mcp-Session-Id\|sessionId" ./src
grep -rn "initialize\b\|initialized\b" ./src
grep -rn "elicitation/create\|sampling/createMessage\|roots/list" ./src

ثم بالترتيب:

انقل حالة الجلسة إلى مقابض صريحة. الأداة تُرجع مقبضًا، والنموذج يعيده. وإن تعذّر تمثيل الحالة بهذا الشكل، فمكانها على الأرجح مخزن بياناتك الخاص مُفهرسًا بهوية موثّقة، لا بجلسة نقل.
حوّل استدعاءات الخادم إلى نمط MRTR. أي مسار يقاطع النموذج طلبًا لمدخل يحتاج بنية input_required / inputResponses.
اضبط ttlMs وcacheScope على نقاط نهاية القوائم. إضافة رخيصة وفائدتها فورية للعملاء.
عالج التفويض قبل طبقة النقل. أضف التحقق من iss، وخطط للانتقال إلى CIMD الآن بدل الانتظار حتى نهاية عمر DCR.
حدّث حزمة التطوير (SDK). حزم TypeScript وPython وGo وC# في المستوى الأول، وRust في مرحلة بيتا. الترحيل يتضمن تغييرات كاسرة، خصوصًا في أي موضع لمست فيه معرّفات الجلسات.

إلى أين يتجه البروتوكول؟

تحدد خارطة الطريق المنشورة في 22 أغسطس خمسة محاور ذات أولوية:

المحور	ما يشمله
بدائيات المراسلة الوكيلية	إنضاج Tasks (SEP-2663)، الأحداث التي يبدأها الخادم عبر Webhooks والقنوات، الاشتراكات، إشعارات التقدم
توحيد النقل عبر HTTP	توسيع Streamable HTTP ليعمل فوق stdio للخوادم المحلية
هوية الوكيل وأمن المؤسسات	آلية DPoP (إثبات الحيازة)، واتحاد هوية أحمال العمل
تحسين البدائيات	توحيد التعامل مع نتائج الأدوات، والاكتشاف التدريجي لكتالوجات الأدوات الكبيرة
تجربة مطوري SDK	سهولة الاستخدام والتوافق مع المواصفة

محوران يستحقان الانتباه. الاكتشاف التدريجي يعالج مشكلة تواجهها الفرق اليوم فعلًا: كتالوجات أدوات أكبر من أن تُحشر في نافذة السياق. وDPoP مع اتحاد هوية أحمال العمل يشير إلى أن هوية الوكيل صارت تُعامَل كبنية تحتية لا كشأن تطبيقي — وهو تحوّل مهم في ضوء إخفاقات تفويض الوكلاء التي كُشفت هذا الشهر.

ولاحظ الاتجاه العام: الأحداث التي يبدأها الخادم تعود عبر Webhooks والقنوات، لا عبر إحياء الجلسات. أي دلالات دفع (Push) دون حالة في طبقة النقل.

القيود والأسئلة المفتوحة

لا تحدد خارطة الطريق موعدًا لإصدار المواصفة القادم، وعدد من البنود المذكورة — Webhooks والقنوات وDPoP — لا يزال قيد العمل أو مجرد مقترح. تعامل معها بوصفها اتجاهًا لا جدولًا زمنيًا.

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

وللفرق التي تبني على منصة Anthropic، يغطي مقال التوفر العام لـ computer use وSkills API وFiles API الطبقة التي تقع فوق عمل البروتوكول هذا.

الخلاصة

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

ابدأ بتدقيق الجلسات، وكل ما بعده سيتحدد بناءً على ما ستجده.