تغييرات مواصفات Model Context Protocol: الجديد وما الذي سيتعطل

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

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

💡 الخلاصة المختصرة: انتهت الجلسات، وصارت الطلبات التي يبدؤها الخادم تستخدم نمط إعادة المحاولة، ونتائج القوائم قابلة للتخزين المؤقت، وأصبح التفويض أكثر صرامة، وأصبحت المهام ضمن إضافة. تبقى Roots وSampling وLogging تعمل، لكن لمدة اثني عشر شهرًا على الأقل.

لماذا تختلف هذه المراجعة

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

خمس مراجعات، اتجاه واحد

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

يدعم الإصدار نفسه بالفعل حيث يهم ذلك. تتوافق جميع حزم SDK من فئة Tier 1 الأربع (TypeScript وPython وGo وC#) مع الإصدار 2026-07-28، وتدعمه حزمة Rust SDK في نسختها التجريبية. يعترف القائمون على المشروع بوجود "بعض تكلفة الترحيل، خاصة للمطورين الذين اعتمدوا فعلًا على معرّفات الجلسات"، ثم يضيفون أن ملاحظات الاختبار المبكر جعلت العملية أسهل.

النواة عديمة الحالة

يُحدث اقتراحان معظم الضرر: يُزيل SEP-2567 الجلسات، ويُزيل SEP-2575 المصافحة ويعيد تشكيل طريقة تدفق الإشعارات.

لا مصافحة ولا معرّف جلسة

طلب initialize وnotifications/initialized لم يعودا موجودين، وكذلك Mcp-Session-Id. لم تعد نقاط نهاية القوائم (tools/list وresources/list وprompts/list) قادرة على التغيّر لكل اتصال، لأنه لم تعد هناك هوية اتصال تتغيّر بحسبها. عندما تحتاج أداة إلى حالة عبر الاستدعاءات، يُنشئ الخادم مقبضًا صريحًا، مثل معرّف سلة تسوق أو معرّف مساحة عمل، ويعيد النموذج تمريره كوسيط عادي للأداة.

بدلًا من المصافحة، يحمل كل طلب سياقه الخاص في _meta. يوضح هذا المثال الشكل فقط، وليس نسخة من المواصفات:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "stateless transport" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

نسخ الأمر النصي

يعيد عدم تطابق الإصدار UnsupportedProtocolVersionError، ويعرّف الخوادم بنفسها في كل نتيجة عبر io.modelcontextprotocol/serverInfo.

⚠️ الحالة المخفية هي الخطر الحقيقي. الخرائط في الذاكرة المفهرسة بمعرّف الجلسة، ومستويات السجل لكل اتصال، وقوائم الاشتراك لكل اتصال، كلها ستتوقف عن العمل. ومن السهل إغفالها في البحث داخل الشيفرة لأنها نادرًا ما تحتوي على كلمة "session".

الإعلان عن الإصدارات والقدرات. يجب أن تنفّذ الخوادم الآن RPC جديدًا في نطاق server/ يُبلغ عن إصدارات البروتوكول المدعومة والقدرات والهوية. يمكن للعملاء استدعاؤه قبل أي شيء آخر لاختيار الإصدار مسبقًا، وعلى STDIO يعمل كفحص للتوافق مع الإصدارات السابقة. يدرج سجل التغييرات هذا الأمر مباشرة تحت إزالة المصافحة، لذا راجع صفحة المخطط لمعرفة اسم الطريقة الدقيق وشكل الاستجابة قبل ربطه.

ما الذي يحل محل تدفق GET

نقطة نهاية GET عبر HTTP، resources/subscribe، وresources/unsubscribe استُبدلت باستدعاء واحد: subscriptions/listen. يفتح هذا الاستدعاء تدفق استجابة POST واحدًا طويل الأمد، ويختار العملاء أنواع التغييرات التي يهتمون بها:

• toolsListChanged
• promptsListChanged
• resourcesListChanged
• resourceSubscriptions

يقرّ الخادم بكل إشعار ويضع عليه الوسم io.modelcontextprotocol/subscriptionId. وتبقى الرسائل المرتبطة بالطلب، مثل notifications/progress وnotifications/message، على تدفق استجابة الطلب الذي تنتمي إليه.

تُزال ثلاثة أشياء إضافية أيضًا: ping وlogging/setLevel وnotifications/roots/list_changed. يُضبط مستوى السجل الآن لكل طلب عبر io.modelcontextprotocol/logLevel، ويجب على الخادم ألا يُصدر notifications/message لطلب لا يتضمنه.

استئناف SSE أيضًا لم يعد موجودًا. لا توجد ترويسة Last-Event-ID ولا معرّفات أحداث، لذلك إذا انقطع تدفق الاستجابة يفقد الطلب الجاري، ويجب على العميل إعادة إرساله بمعرّف طلب جديد. استدعاء أداة يستغرق تسعين ثانية عبر اتصال غير مستقر يحتاج الآن إلى إضافة المهام، لا إلى الحظ.

شرح طلبات الرحلة المتعددة الجولات

لماذا كان لا بدّ من إزالة طلبات الخادم

قبل هذه المراجعة، كان بإمكان الخادم أن يرسل elicitation/create أو sampling/createMessage أو roots/list في منتصف استدعاء عبر تدفق مفتوح. كان ذلك يربط العميل بنسخة واحدة من الخادم، ويستلزم موازنة حمل لاصقة أو تخزينًا مشتركًا.

تحل طلبات الرحلة المتعددة الجولات (SEP-2322) محل ذلك التصميم. تقول المواصفات ذلك بوضوح: يجب على الخوادم إرسال هذه الطلبات عبر نمط MRTR، ولم يعد النمط القديم مدعومًا، وهذا تغيير كاسر. كما أن كل نتيجة تحمل الآن حقلًا إلزاميًا هو resultType. إحدى قيمه هي input_required، والأخرى تدل على نتيجة نهائية عادية، ويعامل العملاء الحقل المفقود من خادم أقدم على أنه من النوع العادي.

كيف تعمل حلقة إعادة المحاولة

يتألف التدفق من أربع خطوات:

1. يرسل العميل طلبًا عاديًا، مثل tools/call.
2. لا يستطيع الخادم إكمال الطلب، فيعيد InputRequiredResult يسرد ما يحتاجه.
3. يجمع العميل الإجابات من المستخدم أو من مصدر آخر.
4. يعيد العميل محاولة الطلب الأصلي مع inputResponses مرفقًا، باستخدام معرّف JSON-RPC جديد.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "github_login": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Please provide your GitHub username",
          "requestedSchema": {
            "type": "object",
            "properties": { "name": { "type": "string" } },
            "required": ["name"]
          }
        }
      }
    },
    "requestState": "AEAD-protected blob"
  }
}

نسخ الأمر النصي

لا يجوز إلا لثلاثة طلبات من العميل أن تتلقى هذه النتيجة: prompts/get وresources/read وtools/call. كل InputRequiredResult يحتاج إلى واحد على الأقل من inputRequests أو requestState، ولا يجوز للخادم أن يطلب قدرة لم يصرّح بها العميل. ولأن إعادة المحاولة تخبر العميل بكيفية انتهاء الأمور، أُزيل إشعار إكمال الاستيضاح وحقل elicitationId الذي أُضيف في 2025-11-25.

تعامل مع requestState كما تتعامل مع مدخلات المستخدم

سلسلة requestState تمر عبر العميل، لذلك تنص المواصفات على معاملتها كأنها خاضعة لسيطرة المهاجم. إذا أثّرت في التفويض أو الوصول إلى الموارد أو منطق العمل، فاحمِ سلامتها باستخدام HMAC أو AEAD، وارفض أي شيء يفشل في التحقق.

للحماية من إعادة التشغيل، ضع ثلاثة أشياء داخل الحمولة المحمية، وتحقق من كل منها عند الاستلام:

• الهوية الموثّقة للمستخدم
• صلاحية قصيرة المدى
• معرّف للطلب الأصلي، مثل اسم الطريقة وملخص تجزئة لمعاملاتها الرئيسية

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

الترويسات والتخزين المؤقت ورموز الأخطاء

ترويسات التوجيه للبوابات

يفرض SEP-2243 وجود Mcp-Method وMcp-Name في كل طلب POST من نوع Streamable HTTP. الغاية تشغيلية: يمكن للبوابات وجدران حماية تطبيقات الويب (WAF) الآن توجيه حركة MCP وقياسها وتحديد معدلها دون تحليل جسم JSON. ويمكن أيضًا اشتقاق ترويسات مخصصة من معاملات الأداة عبر x-mcp-header، ويظهر عدم التطابق بين الترويسة والجسم كخطأ HeaderMismatch، وهو موجود الآن في المخطط.

💡 إذا كنت تشغّل بوابة API أمام خادم MCP، فهذا التغيير هو الذي يعود عليك بالنفع أولًا. اكتب قواعد على الترويستين بدلًا من التعابير النمطية على أجسام الطلبات.

تلميحات التخزين المؤقت ورموز الأخطاء

يضيف SEP-2549 واجهة CacheableResult. يجب أن تتضمن نتائج tools/list وprompts/list وresources/list وresources/read وresources/templates/list الآتي:

• ttlMs: تلميح بمدة صلاحية الذاكرة المؤقتة بالمللي ثانية، حتى يتمكن العملاء من التخزين المؤقت بدلًا من الاستطلاع المتكرر
• cacheScope: "public" أو "private"، ويوضح للوسطاء المشتركين ما إذا كان يجوز لهم تخزين الاستجابة

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

تغيّرت رموز الأخطاء أيضًا، وفق سياسة تخصيص جديدة: نطاق -32000 إلى -32019 يبقى معرّفًا من قِبل التنفيذ، ونطاق -32020 إلى -32099 محجوز للمواصفات.

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

التفويض أصبح أكثر صرامة

فحوص الجهة المصدرة والبيانات المرتبطة

ثلاثة تغييرات تُشدّد تدفق OAuth:

• SEP-2468: ينبغي لخوادم التفويض تضمين معامل iss من RFC 9207، ويجب على العملاء التحقق من iss إذا كان موجودًا مقابل الجهة المصدرة المسجّلة، قبل استرداد رمز التفويض.
• SEP-2352: ترتبط بيانات اعتماد العميل بخادم التفويض الذي أصدرها. احفظها حسب معرّف الجهة المصدرة، ولا تُعِد استخدامها مع خادم مختلف، وسجّل من جديد عندما يتغيّر الخادم.
• SEP-837: يجب على العملاء إرسال application_type مناسب أثناء التسجيل الديناميكي للعميل، وهذا يمنع تعارضات عناوين إعادة التوجيه في OpenID Connect على localhost.

التسجيل الديناميكي في طريقه إلى الخروج

بروتوكول التسجيل الديناميكي للعميل في OAuth 2.0 (RFC 7591) أصبح مهملًا لصالح وثائق بيانات تعريف هوية العميل. ما زال يعمل مع خوادم التفويض التي لا تملك الخيار الأحدث، لكن الإعلان يقول إنه سيُزال في إصدار لاحق من المواصفات. خطّط للتحول الآن بدلًا من أن تفعل ذلك أثناء حادثة.

المهام والمخططات والإضافات

المهام تنتقل إلى إضافة

خرجت المهام التجريبية من البروتوكول الأساسي وصارت إضافة io.modelcontextprotocol/tasks الرسمية (SEP-2663). يستبدل التصميم الجديد طريقة tasks/result الحاجزة بالاستطلاع عبر tasks/get، ويضيف tasks/update حتى يتمكن العميل من إرسال مدخلات إلى مهمة قيد التشغيل، ويُزيل tasks/list. ويمكن للخوادم الآن إعادة مقبض المهمة دون أن يطلبه العميل.

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

مخططات أقل صرامة وفتحات إضافات جديدة

إضافات أصغر تستحق سطرًا لكل منها:

• inputSchema وoutputSchema يمكن أن يستخدما أي بنية من JSON Schema 2020-12، ويمكن أن يكون structuredContent أي قيمة JSON (SEP-2106)، مع قواعد جديدة لحل $ref وحدود للموارد على بُنى التركيب.
• ClientCapabilities وServerCapabilities يكتسبان حقل extensions للميزات الاختيارية التي تتجاوز الأساس.
• يُنقل سياق تتبع OpenTelemetry عبر _meta من خلال traceparent وtracestate وbaggage (SEP-414).

تذكر مدونة Cloudflare حول الإصدار أن نقطة نهاية /mcp تقبل الطلبات عديمة الحالة الجديدة وعملاء من حقبة 2025، وهذا نمط معقول لأي شخص يشغّل خادمًا عامًا.

ما الذي يتعطل وكيف تصلحه

الميزات المُزالة

ستفشل هذه الأشياء فشلًا كاملًا أمام نظير بإصدار 2026-07-28:

الميزات المُهملة

المُهمَل ليس مُزالًا. ما زالت هذه الميزات تعمل لمدة اثني عشر شهرًا على الأقل بموجب سياسة دورة حياة الميزات الجديدة (SEP-2596)، التي تحدد حالات Active وDeprecated وRemoved وسجلًا عامًا:

تضع بعض المقالات Roots وSampling وLogging مع الميزات المُزالة. لكن نص المواصفات يقول مُهمَلة، لذا تعامل معها كبند في التقويم، لا كانقطاع. ولم يُزَل فعليًا إلا ping وlogging/setLevel.

ترتيب ترحيل يعمل

1. حدّث SDK أولًا. انتقل إلى إصدار من فئة Tier 1 يدعم 2026-07-28، واقرأ ملاحظات الترحيل الخاصة به قبل أن تلمس شيفرتك.
2. ابحث عن حالة الجلسة. ابحث عن Mcp-Session-Id وعن أي خريطة مفهرسة حسب الاتصال. استبدل كلًّا منها بمقبض صريح يُمرَّر كوسيط للأداة.
3. اقبل الجيلين معًا. قدّم العملاء القدامى والجدد من نقطة النهاية نفسها خلال الانتقال، كما تفعل Cloudflare.
4. أعد كتابة الاستدعاءات التي يبدؤها الخادم. حوّل كل استدعاء للاستيضاح وSampling وRoots إلى InputRequiredResult مع requestState موقّع.
5. أضف حقول التخزين المؤقت. أعد ttlMs وcacheScope في نتائج القوائم والقراءة، ورتّب قوائم الأدوات بشكل حتمي.
6. حدّث قواعد البوابة. وجّه الطلبات حسب Mcp-Method وMcp-Name، ثم تخلّص من قواعد تحليل الأجسام.
7. أصلح التفويض. تحقق من iss، واحفظ بيانات الاعتماد لكل جهة مصدرة، وخطّط للانتقال إلى وثائق بيانات تعريف هوية العميل.

ثم اختبر الحالات الصعبة: أوقف تدفق استجابة في منتصف طلب، وأعد تشغيل requestState قديم، وشغّل نسختين من الخادم دون توجيه لاصق. إذا تصرفت الثلاث بشكل سليم، فالترحيل صالح.

💡 نصيحة سريعة: الصق شيفرة إدارة الجلسات في خادمك ومقطع سجل التغييرات أعلاه في Claude Sonnet 5 على Picasso IA، واطلب قائمة بكل موضع تتسرّب فيه الحالة بين الطلبات. راجع المخرجات بنفسك، فقد يُغفل النموذج خريطة مخفية داخل دالة مساعدة.

أنشئ مرئياتك الخاصة

تعتمد المقالات التقنية مثل هذا المقال على مخططاتها وصور ترويستها، ولا تحتاج إلى فريق تصميم لإنتاجها. تجمع Picasso IA عشرات نماذج الصور في مكان واحد، لتتمكن من اختبار الأمر النصي نفسه على عدة نماذج والاحتفاظ بأفضل نتيجة.

جرّب Seedream 5 Pro للمشاهد الواقعية كالصور الفوتوغرافية، أو GPT Image 2 لاتباع الأوامر النصية بدقة، أو Ideogram v4 Quality عندما تحتاج صورتك إلى نص مقروء. صِف المشهد، واختر نسبة عرض إلى ارتفاع 16:9، وولّد بعض النسخ قبل أن تحسم اختيارك.

افتح Picasso IA، واختر نموذجًا، وأنشئ أول صورة لمقال MCP القادم اليوم.