شرحت AWS كيف تغيّر أحدث مواصفة لبروتوكول سياق النموذج (MCP) طريقة نشر خوادم MCP البعيدة، بعد إزالة «الجلسات» على مستوى البروتوكول، بحسب InfoQ. البروتوكول الذي تتّصل عبره الوكلاء بالأدوات والبيانات صار «عديم الحالة» (Stateless).
ما الذي تغيّر؟
- أُزيلت المصافحة الابتدائية
initializeوinitialized، وأُزيل رأسMcp-Session-Id. - يمكن الآن توجيه كل طلب بشكل مستقل إلى أي نسخة من الخادم خلف موزّع أحمال (Load Balancer) عادي، دون «جلسات لاصقة» أو مخزن جلسات مشترك.
- عملية اختيارية جديدة
server/discoverللعملاء الذين يحتاجون قدرات الخادم قبل استدعاء الأدوات. - آلية MRTR تستبدل الطلبات التي كان يبدؤها الخادم وتتطلّب إبقاء الاتّصال مفتوحًا، بردود
input_requiredوطلبات لاحقة. - رؤوس جديدة
Mcp-MethodوMcp-Nameللتوجيه والتقييد في البوّابات، ودعم W3C Trace Context للتتبّع الموزّع، وضوابط للتخزين المؤقت.
ماذا يعني ذلك على AWS؟
يقول كتّاب مدوّنة AWS للبنية إن الشركات تستطيع الاستغناء عن التوجيه المرتبط بالجلسة وعن مخازن الجلسات المستخدمة فقط لحالة البروتوكول، وإن AWS Lambda صار خيارًا مناسبًا للنشر لأن البروتوكول لم يعد يحتاج اتّصالات دائمة. وقد لخّص أحد المعلّقين التغيير بعبارة: «البروتوكول عديم الحالة. تطبيقك لا يجب أن يكون كذلك».
ما الثمن؟
أُزيلت قابلية استئناف التدفّق، فقد يحتاج العملاء إلى إعادة محاولة العمليات المقطوعة، ما يزيد أهمية «تساوي القوى» (Idempotency) في استدعاءات الأدوات ذات الأثر، أي أن تكرار الطلب لا يكرّر الأثر. وتوصي AWS بتتبّع إصدارات البروتوكول عند البوّابة والإبقاء على بنية الجلسات حتى يختفي الاتّصال القديم. ويطبّق مشروع Apify دعم النسخة الجديدة إلى جانب الخادم القديم.
ليه ده مهم؟
MCP صار الطريقة الشائعة لربط الوكلاء بالأدوات والمهارات. جعله عديم الحالة يسهّل توسيع الخوادم كأي خدمة ويب عادية، لكنه ينقل المسؤولية إلى المطوّرين: إذا كانت أداتك تنشئ طلبًا أو ترسل رسالة، فعليها أن تتعامل بأمان مع استقبال الطلب نفسه مرّتين.
المصادر: InfoQ — 2026-09-25
