الخلاصة: يزيل MCP 2026-07-28 الجلسات على مستوى البروتوكول ومصافحة التهيئة الإلزامية. على فرق الإنتاج اكتشاف تبعيات الجلسات المخفية، واعتماد بيانات التعريف الخاصة بالبروتوكول لكل طلب، وتنفيذ طلبات متعددة الجولات (MRTR)، وتحديث سياسات البوابة، وإجراء نشر كناري للبروتوكول الجديد قبل إيقاف السلوك القديم.
يقدّم مواصفات Model Context Protocol الصادرة في 28 يوليو 2026 أكبر تغيير معماري لـ MCP منذ إضافة دعم النقل البعيد.
أصبح البروتوكول الآن يعتمد نواة عديمة الحالة قائمة على طلب-واستجابة. تم إلغاء تبادل initialize وnotifications/initialized الإلزامي، وتمت إزالة Mcp-Session-Id، ويحمِل كل طلب معلومات البروتوكول اللازمة لمعالجته.
تتضمن الإصدارة أيضًا طلبات متعددة الجولات (MRTR)، ورؤوس توجيه HTTP، واستجابات قوائم قابلة للتخزين المؤقت، وسلوك تفويض أكثر صرامة، وإطار امتدادات، ودورة إهمال رسمية. راجع و للتفاصيل على مستوى البروتوكول.
تجعل هذه التغييرات خوادم MCP البعيدة أسهل في التحجيم خلف بنية HTTP القياسية. لكنها لا تجعل التطبيق القائم عديم الحالة تلقائيًا.
قد يعتمد خادم إنتاجي على مساحات عمل ضمن الذاكرة، أو توجيه لاصق، أو بيانات اعتماد مرتبطة بالجلسة، أو تدفقات طويلة الأمد، أو تفاعلات مبادَرة من الخادم. يركّز هذا الدليل على تحديد تلك التبعيات واستبدالها.
هذا يجعل الاعتمادية مرئية في عقد الأداة ويسمح لأي مثيل خادم متوافق بمعالجة الطلب.
تخزين مشترك
استخدم قاعدة بيانات أو ذاكرة موزعة مؤقتة أو مخزن كائنات أو نظام مهام دائم عندما:
يحتاج عدة عمال إلى نفس الحالة؛
يجب أن ينجو سير العمل من إعادة التشغيل؛
الحالة كبيرة جدًا بالنسبة لمقبض؛
يدوم سير العمل أكثر من طلب واحد؛
يلزم سلوك معاملات أو استخدام لمرة واحدة.
requestState محمي
يمكن لـ MRTR إرجاع قيمة requestState غير شفافة يعكسها العميل عند إعادة محاولة الطلب الأصلي.
نظرًا لأن القيمة تمر عبر العميل، احمها باستخدام HMAC أو تشفير موثّق. اربطها بالجهة المصادق عليها، والعملية الأصلية، والمعلمات المهمة، ووقت الانقضاء، ورقم عشوائي عند الحاجة لحماية من الإعادة.
لا تثق بقيمة requestState غير الموقّعة لمجرد أن العميل أعادها دون تغيير.
3. اعتماد طلبات مكتفية ذاتيًا واكتشاف
تتضمن طلبات MCP الحديثة سياق البروتوكول في _meta.
يمكن أن يبدو استدعاء أداة عبر Streamable HTTP هكذا:
يجب على الخوادم المستهدِفة للبروتوكول الجديد تنفيذ server/discover، الذي يعلن الإصدارات المدعومة والقدرات وهوية الخادم. قد يستدعيه العملاء قبل عملية أخرى أو يستخدمونه لتحديد ما إذا كان يلزم تراجع إلى النسخة الأقدم.
اقرأ توثيق server/discover الرسمي لعقدة الاستجابة.
تفاوض الإصدارات في TypeScript SDK
ترقية TypeScript SDK وحدها لا تنقل العميل تلقائيًا إلى البروتوكول الجديد.
يجب على العميل الذي يستخدم SDK v2 تفعيل ذلك صراحة:
تجنّب إتمام عملية شراء أو حذف أو خصم رصيد أو كتابة خارجية قبل إعادة input_required.
استخدم عملية متدرجة أو مفتاح اعتمادية بحيث لا يمكن أن تكرر عمليات إعادة المحاولة الإجراء. راجع مواصفات MRTR الرسمية لنموذج التفاعل بالكامل.
5. تحديث البوابات والتخزين المؤقت والتفويض
ترتبط تغييرات البنية التحتية بشكل وثيق ويجب اختبارها معًا.
التحقق من رؤوس توجيه MCP
تتضمن طلبات POST عبر Streamable HTTP الآن:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
تسمح هذه الرؤوس للبوابات بتوجيه الحركة وقياسها وتفويضها وتحديد معدلاتها دون تحليل كل جسم JSON.
يمكنها دعم ضوابط مثل:
حدود معدل خاصة بالأدوات؛
سياسات منفصلة لأساليب القوائم والتنفيذ؛
تجمعات عمال مخصصة للأدوات المكلفة؛
وصول مقيد للعمليات عالية المخاطر؛
مقاييس كمون وأخطاء حسب الأداة؛
عزو تكاليف البنية التحتية.
لا تزال القيم تُقدَّم من العميل. قارِنها بجسم JSON-RPC قبل تطبيق السياسة.
لا يجب أن يتمكن طلب من الادعاء بأداة منخفضة المخاطر في Mcp-Name بينما يستدعي أداة مختلفة في الجسم. يجب رفض عدم التطابق بين الرأس والجسم وتسجيله.
استخدام مفاتيح تخزين مؤقت واعية بالتفويض
يضيف البروتوكول الجديد ttlMs وcacheScope إلى النتائج القابلة للتخزين المؤقت بما في ذلك:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
عادةً ما ينبغي أن يتضمن مفتاح التخزين المؤقت:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
لا تعِد استخدام بند خاص في ذاكرة التخزين المؤقت عبر المستخدمين أو المستأجرين لمجرد أن مدة بقائه لم تنتهِ.
يهمّ الترتيب الحتمي للأدوات أيضًا. إن فهرسًا ثابتًا يتجنب فقدان التخزين المؤقت غير الضروري وقد يحسن استخدام ذاكرة التخزين المؤقت للنموذج عندما تُدرج تعريفات الأدوات في المطالبات.
تقوية التعامل مع جهة إصدار OAuth
أثناء ترحيل التفويض:
تحقّق من قيمة iss المرتجعة مقابل جهة الإصدار المسجلة للتدفق؛
اربط تخزين بيانات اعتماد العميل بجهة الإصدار؛
لا تعِد استخدام بيانات الاعتماد مع خادم تفويض آخر؛
اضبط application_type المناسب أثناء DCR؛
جهّز تكاملات جديدة لـ Client ID Metadata Documents.
يبقى Dynamic Client Registration متاحًا للتوافق مع الإصدارات السابقة، لكنه مُهمَل بوصفه نهج التسجيل المفضل.
6. ترحيل الإشعارات والمهام والميزات المهملة
تم استبدال مسار إشعارات HTTP GET وتدفق resources/subscribe أو resources/unsubscribe بـ subscriptions/listen.
يفتح العملاء تدفق استجابة POST طويل الأمد ويختارون فئات الإشعارات التي يحتاجونها. تبقى إشعارات التقدم والسجل الخاصة بالطلب مرفقة بتدفق الاستجابة للطلب الذي تصفه.
لعمليات النشر متعددة المثيلات، استخدم حافلة أحداث مشتركة حين يلزم أن تصل الإشعارات المولدة على مثيل خادم إلى اشتراك متصل بمثيل آخر.
امتداد Tasks
نُقلت الأعمال طويلة الأمد من نواة البروتوكول التجريبية إلى:
io.modelcontextprotocol/tasks
يستخدم الامتداد:
tasks/get للاستطلاع؛
tasks/update لتحديثات من العميل إلى الخادم؛
مقابض مهام دائمة؛
subscriptions/listen لتحديثات بالاشتراك.
لا ينبغي حمل الأنماط القديمة tasks/result وtasks/list إلى تطبيق جديد.
ميزات مهملة
الميزات التالية مُهمَلة:
الميزة
التوجّه الموصى به
MCP 2026-07-28
إجراء الترحيل
Roots
تمرير الأدلة عبر وسائط الأدوات أو URI للموارد أو الإعدادات
لا مصافحة مطلوبة
إزالة بوابات التهيئة لطلبات العصر الحديث
Sampling
التكامل مباشرة مع واجهات مزوّدي النماذج
لا جلسة على مستوى البروتوكول
جعل الحالة المطلوبة صريحة
Logging
استخدام stderr لـ stdio أو OpenTelemetry في الإنتاج
استدعاء server/discover اختياري
تنفيذ الاكتشاف وتفاوض الإصدارات
Dynamic Client Registration
الانتقال نحو Client ID Metadata Documents
مضمن في _meta داخل الطلب
إرسال بيانات تعريف البروتوكول لكل طلب
HTTP+SSE القديم
الترحيل إلى Streamable HTTP
رؤوس Mcp-Method وMcp-Name
تحديث التوجيه والسياسة والقابلية للرصد
deprecated includeContext values
حذف الحقل أو استخدام "none"
طلبات متعددة الجولات
التعامل مع input_required والإعادات
تخزين القوائم مؤقتًا
جلب الفهارس مرارًا
ttlMs وcacheScope وترتيب حتمي
إضافة تخزين مؤقت واعٍ بالتفويض
الإشعارات
GET stream واشتراكات الموارد
subscriptions/listen
نقل إشعارات التغيير إلى التدفق الجديد
التفويض
تسجيل عميل ديناميكي متمركز على DCR
قواعد جهة إصدار أقوى واتجاه CIMD
تبقى الوظائف المهملة متاحة خلال نافذة الإهمال، لكن لا ينبغي أن تعتمدها تطبيقات جديدة. توفر سياسة دورة الحياة الخاصة بـ MCP فترة إهمال لا تقل عن اثني عشر شهرًا؛ ولا تعني أن لكل ميزة تاريخ إزالة مؤكدًا واحدًا.
إضافة رؤوس توجيه مُتحقَّق منها وتخزينات مؤقتة بنطاقات.
اختبار حدود جهة إصدار التفويض.
نشر كناري للبروتوكول الحديث إلى جانب المسار القديم.
إيقاف السلوك الأقدم فقط بعد مراجعة القياسات.
التوافق أثناء النشر الكناري
Modern client + modern server
→ Use MCP 2026-07-28
Modern client + legacy server
→ Probe and fall back when supported
Legacy client + dual-version server
→ Continue on the legacy path
Unsupported combination
→ Return a clear protocol-version error
إن إصدار مواصفة MCP جديدة ليس مفتاحًا يشغّل النظام البيئي كله. ستترحّل العملاء والخوادم وSDKs والمنصات المستضافة بسرعات مختلفة.
القياسات المطلوب تسجيلها
الإشارة
ما تكشفه
إصدار البروتوكول لكل طلب
التبنّي والتركيبات غير المتوافقة
نجاح الاكتشاف ومعدل التراجع
سلوك تفاوض الإصدارات
رؤوس MCP المفقودة أو غير الصالحة
عملاء قدامى أو أخطاء في البوابة
عدم تطابق الرأس/الجسم
أخطاء العملاء أو محاولات تجاوز السياسة
MRTR المطلوب والمكتمل
موثوقية سير العمل التفاعلي
MRTR المرفوض أو المنتهي مهلة
مسارات فشل المستخدم والعميل
إخفاقات التحقق من حالة الطلب
عبث أو إعادة أو انتهاء صلاحية
منع العمليات المكررة
فعالية ضوابط الاعتمادية
معدل نجاح التخزين المؤقت حسب النطاق
خفض آمن للحركة
إخفاقات التحقق من جهة الإصدار
مشاكل تهيئة OAuth
حركة HTTP+SSE
العمل المتبقي لترحيل النقل
حركة الطرق المهملة
أدلة لتخطيط الإزالة
كمون الأدوات ومعدل المهام المقبولة
موثوقية مرئية للمستخدم
لا تكفي طلبات tools/call أحادية التنفيذ الناجحة لقياس الترحيل. يظل سير العمل الذي ينتهي مهلة مرارًا أو يطلب مدخلات غير ضرورية أو يكرر كتابة خارجية فشلًا إنتاجيًا.
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
يوحد MCP كيفية تفاعل الوكلاء مع الأدوات والسياق. لا يقيّس تسعير النماذج أو بيانات اعتماد مقدمي الخدمة أو نقاط نهاية الاستدلال أو التحويل بين المزودين.
تصبح هذه الفصلية مفيدة خاصةً عند الترحيل بعيدًا عن قدرة Sampling المهملة. إذا كان خادم MCP أو الوكيل الذي يستهلكه لا يزال يحتاج إلى استدلال نموذج، فيمكن للتطبيق استدعاء واجهة نموذج مباشرة بدلًا من الاعتماد على تدفق Sampling القديم في MCP.
متى يفيد بوابة نماذج موحدة
يمكن لبوابة نماذج موحدة تقليل العمل التشغيلي عندما:
تحتاج عدة خوادم MCP إلى الوصول إلى مزودي نماذج مختلفين؛
تتطلب أدوات مختلفة نماذج مختلفة؛
تريد الفرق تبديل النماذج دون إعادة كتابة تكاملات خاصة بالمزود؛
يجب إدارة بيانات الاعتماد والاستخدام والفوترة مركزيًا؛
يجب أن يبقى الوصول إلى النماذج مستقلًا عن تغييرات نقل MCP.
يوفر CometAPI نقطة نهاية متوافقة مع OpenAI يمكن استخدامها كطبقة الوصول إلى النماذج خلف تطبيقات MCP. يحافظ هذا على منطق مزود النماذج منفصلًا عن أدوات MCP ومواردها وتنسيق المهام.
على سبيل المثال، يمكن لأداة MCP استدعاء نموذج عبر نفس عميل OpenAI-compatible المستخدم في مكان آخر في التطبيق:
هو مواصفة Model Context Protocol الصادرة في 28 يوليو 2026. تقدم نواة بروتوكول عديمة الحالة، وطلبات متعددة الجولات، ورؤوس توجيه HTTP، ونتائج قابلة للتخزين المؤقت، وتغييرات في التفويض، وامتدادات، ودورة إهمال رسمية.
هل تمت إزالة Mcp-Session-Id؟
نعم. لم يعد البروتوكول الجديد Streamable HTTP يستخدم Mcp-Session-Id.
لا تزال التطبيقات قادرة على الحفاظ على الحالة عبر مقابض صريحة، أو تخزين مشترك، أو مهام دائمة، أو قيم request-state محمية.
هل تمت إزالة مصافحة تهيئة MCP؟
نعم. لا تتطلب الطلبات الحديثة تبادل initialize وnotifications/initialized.
يجب على الخوادم تنفيذ server/discover، رغم أن العملاء لا يحتاجون لاستدعائه قبل كل عملية.
هل يعني MCP عديم الحالة أن الأدوات لا يمكنها الحفاظ على الحالة؟
لا. العديمية للحالة تشير إلى طبقة البروتوكول.
لا يزال بإمكان الأداة تخزين حالة، لكن لا ينبغي أن يعتمد تنفيذ الطلب على تقارب نقل مخفي أو عملية خادم محددة.
ما هي MRTR؟
طلبات متعددة الجولات تسمح للخادم بطلب مدخلات إضافية من العميل أو المستخدم دون إرسال طلب مبادر من الخادم عبر اتصال ثنائي الاتجاه مفتوح باستمرار.
يعيد الخادم input_required ويعيد العميل محاولة العملية الأصلية بالاستجابات المطلوبة.
هل تمت إزالة HTTP+SSE فورًا؟
لا. إنها مُهمَلة وليست مُزالة فورًا.
ينبغي أن تستخدم الخوادم الجديدة Streamable HTTP، بينما تقيس الأنظمة القائمة وتُرحّل حركة HTTP+SSE المتبقية.
هل يستخدم عملاء TypeScript SDK v2 بروتوكول MCP 2026-07-28 تلقائيًا؟
استخدم التفاوض التلقائي عندما يجب أن يعمل العميل مع خوادم حديثة وقديمة معًا.
التوصيات النهائية
يجعل MCP 2026-07-28 بنية MCP البعيدة أسهل في التحجيم والتوجيه والتخزين المؤقت والرصد. الخطر الرئيسي في الترحيل ليس مجرد إزالة رأس أو مصافحة، بل الحالة المخفية للتطبيق ومنطق التفاعل الذي قد لا يزال يعتمد عليهما.
قبل نشر البروتوكول الجديد:
اعثر على كل اعتماد على التهيئة وMcp-Session-Id.
انقل الحالة المطلوبة إلى مقابض صريحة أو تخزين مشترك.
نفّذ MRTR مع انتهاء صلاحية وحماية من الإعادة واعتمادية.
تحقّق من رؤوس MCP مقابل جسم JSON-RPC.
قسّم التخزينات المؤقتة حسب المستأجر ونطاق التفويض.
حصّن التحقق من جهة إصدار OAuth.
قِس حركة الطرق المهملة ونقل HTTP القديم.
نفّذ نشرًا كناريًا لمسارات البروتوكول الحديث والقديم قبل الإزالة.
عامل الترحيل كتغيير بنية تحتية لا كترقية SDK روتينية.
وبعد أن تصبح طبقة MCP عديمة الحالة وقابلة للرصد، حافظ على الوصول إلى النماذج خلف واجهة منفصلة. يتيح ذلك تطوّر بروتوكول الأدوات وطبقة مزود النماذج بشكل مستقل.
