MCP 2026-07-28 دليل الترحيل: الخوادم عديمة الحالة

الخلاصة: يزيل MCP 2026-07-28 الجلسات على مستوى البروتوكول ومصافحة التهيئة الإلزامية. على فرق الإنتاج اكتشاف تبعيات الجلسات المخفية، واعتماد بيانات التعريف الخاصة بالبروتوكول لكل طلب، وتنفيذ طلبات متعددة الجولات (MRTR)، وتحديث سياسات البوابة، وإجراء نشر كناري للبروتوكول الجديد قبل إيقاف السلوك القديم.

يقدّم مواصفات Model Context Protocol الصادرة في 28 يوليو 2026 أكبر تغيير معماري لـ MCP منذ إضافة دعم النقل البعيد.

أصبح البروتوكول الآن يعتمد نواة عديمة الحالة قائمة على طلب-واستجابة. تم إلغاء تبادل initialize وnotifications/initialized الإلزامي، وتمت إزالة Mcp-Session-Id، ويحمِل كل طلب معلومات البروتوكول اللازمة لمعالجته.

تتضمن الإصدارة أيضًا طلبات متعددة الجولات (MRTR)، ورؤوس توجيه HTTP، واستجابات قوائم قابلة للتخزين المؤقت، وسلوك تفويض أكثر صرامة، وإطار امتدادات، ودورة إهمال رسمية. راجع الإعلان الرسمي لإصدار MCP 2026-07-28 وسجل تغييرات المواصفات الكامل للتفاصيل على مستوى البروتوكول.

تجعل هذه التغييرات خوادم MCP البعيدة أسهل في التحجيم خلف بنية HTTP القياسية. لكنها لا تجعل التطبيق القائم عديم الحالة تلقائيًا.

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

للاطلاع على تمهيد عملي أكثر، اقرأ How to Create an MCP Server for Claude Code قبل بدء الترحيل.

من يحتاج إلى الترحيل؟

يعتمد حجم الجهد على كيفية استخدام MCP في نظامك.

قد لا يتطلب الخادم المحلي الذي لا يحتفظ بحالة عبر الطلبات سوى ترقية SDK واختبارات التوافق.

يتطلب النشر البعيد الذي يستخدم الجلسات أو OAuth أو البث أو الطلبات المبادر إليها من الخادم ترحيلًا متدرجًا.

ما الذي تغير في MCP 2026-07-28؟

1. تدقيق التنفيذ القائم

قبل الترقية، ابحث في العميل والخادم والبوابة وتكوين النشر عن افتراضات البروتوكول القديمة.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

ثم أجب عن الأسئلة التالية:

1. هل يرفض الخادم الاستدعاءات حتى تكتمل التهيئة؟
2. هل يحدد معرّف الجلسة مستخدمًا أو بيانات اعتماد أو مساحة عمل أو محادثة؟
3. هل يمكن لمثيل خادم آخر متابعة سير عمل بدأه الأول؟
4. هل يتطلب موازن التحميل تقارب الجلسة (sticky affinity)؟
5. هل تنفذ أداة أثرًا جانبيًا قبل طلب التأكيد؟
6. هل تحلل البوابة الجسم لتحديد الطريقة أو الأداة؟
7. هل تُخزن بيانات اعتماد OAuth دون جهة الإصدار الخاصة بها؟
8. هل يعتمد العميل على إعادة اتصال SSE أو إعادة تسليم الرسائل؟
9. هل تختلف قوائم الأدوات أو الموارد حسب الاتصال؟
10. ما الميزات المهملة التي لا تزال تتلقى حركة إنتاجية؟

لا تقم بإزالة Mcp-Session-Id حتى تفهم ما يخزّنه التطبيق وراءه.

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

2. استبدال حالة الجلسة المخفية

يزيل MCP 2026-07-28 الجلسات على مستوى البروتوكول، وليس حالة التطبيق.

يجب التعامل مع الحالة المطلوبة عبر الاستدعاءات بإحدى ثلاث أنماط.

مقابض صريحة

أعد مقبضًا يصدره الخادم من أداة ما واطلبه في الاستدعاءات اللاحقة.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

يمرر الطلب اللاحق المقبض كوسيط عادي:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

هذا يجعل الاعتمادية مرئية في عقد الأداة ويسمح لأي مثيل خادم متوافق بمعالجة الطلب.

تخزين مشترك

استخدم قاعدة بيانات أو ذاكرة موزعة مؤقتة أو مخزن كائنات أو نظام مهام دائم عندما:

• يحتاج عدة عمال إلى نفس الحالة؛
• يجب أن ينجو سير العمل من إعادة التشغيل؛
• الحالة كبيرة جدًا بالنسبة لمقبض؛
• يدوم سير العمل أكثر من طلب واحد؛
• يلزم سلوك معاملات أو استخدام لمرة واحدة.

requestState محمي

يمكن لـ MRTR إرجاع قيمة requestState غير شفافة يعكسها العميل عند إعادة محاولة الطلب الأصلي.

نظرًا لأن القيمة تمر عبر العميل، احمها باستخدام HMAC أو تشفير موثّق. اربطها بالجهة المصادق عليها، والعملية الأصلية، والمعلمات المهمة، ووقت الانقضاء، ورقم عشوائي عند الحاجة لحماية من الإعادة.

لا تثق بقيمة requestState غير الموقّعة لمجرد أن العميل أعادها دون تغيير.

3. اعتماد طلبات مكتفية ذاتيًا واكتشاف

تتضمن طلبات MCP الحديثة سياق البروتوكول في _meta.

يمكن أن يبدو استدعاء أداة عبر Streamable HTTP هكذا:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

يجب على الخوادم المستهدِفة للبروتوكول الجديد تنفيذ server/discover، الذي يعلن الإصدارات المدعومة والقدرات وهوية الخادم. قد يستدعيه العملاء قبل عملية أخرى أو يستخدمونه لتحديد ما إذا كان يلزم تراجع إلى النسخة الأقدم.

اقرأ توثيق server/discover الرسمي لعقدة الاستجابة.

تفاوض الإصدارات في TypeScript SDK

ترقية TypeScript SDK وحدها لا تنقل العميل تلقائيًا إلى البروتوكول الجديد.

يجب على العميل الذي يستخدم SDK v2 تفعيل ذلك صراحة:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

في الوضع التلقائي، يستكشف SDK باستخدام server/discover ويمكنه التراجع إلى تدفق التهيئة الأقدم عند الوصول إلى خادم قديم.

الفرق التي لا تزال تستخدم @modelcontextprotocol/sdk v1 ينبغي أن تتبع أولًا دليل ترحيل TypeScript SDK من v1 إلى v2. الفرق التي تستخدم v2 بالفعل ينبغي أن تستخدم دليل دعم بروتوكول 2026-07-28 المنفصل.

4. استبدال الطلبات المبادَرة من الخادم بـ MRTR

كانت تطبيقات MCP السابقة قادرة على إرسال طلبات مثل elicitation/create أو sampling/createMessage أو roots/list من الخادم إلى العميل.

يستبدل البروتوكول الجديد هذا النموذج بطلبات متعددة الجولات (MRTR).

التدفق هو:

1. يرسل العميل الطلب الأصلي.
2. يعيد الخادم resultType: "input_required".
3. يجمع العميل المعلومات أو الموافقة المطلوبة.
4. يعيد العميل محاولة العملية الأصلية باستخدام معرّف JSON-RPC جديد.
5. تتضمن إعادة المحاولة inputResponses وrequestState الأصلي.
6. يُكمل الخادم الطلب أو يبدأ جولة أخرى.

مثال استجابة:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

يعيد العميل محاولة العملية الأصلية:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

ينبغي لتنفيذ MRTR الإنتاجي تحديد:

• الحد الأقصى للجولات؛
• انتهاء صلاحية حالة الطلب؛
• سلوك الإلغاء والرفض؛
• التحقق من مخطط الاستجابة؛
• فحوصات التفويض في كل إعادة محاولة؛
• الحماية من الإعادة؛
• الاعتمادية (idempotency) للآثار الجانبية؛
• السلوك عند عدم دعم العميل للقدرة المطلوبة.

تجنّب إتمام عملية شراء أو حذف أو خصم رصيد أو كتابة خارجية قبل إعادة 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 فترة إهمال لا تقل عن اثني عشر شهرًا؛ ولا تعني أن لكل ميزة تاريخ إزالة مؤكدًا واحدًا.

راجع سجل الميزات المهملة الرسمي قبل تحديد موعد الإزالة.

7. تنفيذ الترحيل بأمان

لا تغيّر العملاء والخوادم والبوابات والتخزين المؤقت والتفويض في إصدار غير مراقَب واحد.

ترتيب الترحيل الموصى به

1. جرد إصدارات البروتوكول، وSDKs، والجلسات، وحركة SSE، والعملاء المسجلين عبر DCR، والطرق المهملة.
2. ترقية SDKs غير الإنتاجية.
3. إضافة server/discover وتفاوض الإصدارات.
4. استبدال تبعيات الجلسة المخفية.
5. تنفيذ وتأمين MRTR.
6. إضافة رؤوس توجيه مُتحقَّق منها وتخزينات مؤقتة بنطاقات.
7. اختبار حدود جهة إصدار التفويض.
8. نشر كناري للبروتوكول الحديث إلى جانب المسار القديم.
9. إيقاف السلوك الأقدم فقط بعد مراجعة القياسات.

التوافق أثناء النشر الكناري

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 والمنصات المستضافة بسرعات مختلفة.

القياسات المطلوب تسجيلها

لا تكفي طلبات tools/call أحادية التنفيذ الناجحة لقياس الترحيل. يظل سير العمل الذي ينتهي مهلة مرارًا أو يطلب مدخلات غير ضرورية أو يكرر كتابة خارجية فشلًا إنتاجيًا.

كيف يتناسب CometAPI مع بنية MCP

لا يستبدل MCP واجهة برمجة نماذج. الطبقتان تحلان مشكلات تكامل مختلفة.

تبدو بنية إنتاجية نموذجية على النحو التالي:

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 المستخدم في مكان آخر في التطبيق:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

يبقى خادم MCP مسؤولًا عن عقد الأداة والتفويض والحالة والتعامل مع النتائج. تتولى بوابة النماذج اختيار النموذج والوصول إلى المزود واستجابات الاستدلال.

يوفر الحفاظ على هاتين الطبقتين منفصلتين فائدتين عمليتين:

1. يمكن لعملاء وخوادم MCP الترحيل إلى البروتوكول الجديد دون تغيير طبقة تكامل النماذج.
2. يمكن تغيير مزودي النماذج دون إعادة تصميم أدوات MCP أو سلوك النقل.

لمزيد من تفاصيل التنفيذ، راجع البدء السريع لـ CometAPI، وتوثيق API، ودليل تطبيقات الذكاء المتعدد النماذج.

قائمة تحقق لترحيل MCP 2026-07-28

العميل

• ترقية إلى SDK متوافق.
• تفعيل تفاوض الإصدارات الحديثة.
• دعم server/discover.
• تضمين بيانات تعريف البروتوكول في كل طلب.
• التعامل مع resultType.
• دعم MRTR أو رفضه صراحة.
• استخدام معرّف JSON-RPC جديد لإعادات المحاولة.
• حفظ وإرجاع requestState.
• التحقق من جهات إصدار OAuth.
• تخزين بيانات الاعتماد حسب جهة الإصدار.
• احترام تلميحات التخزين المؤقت.
• دعم subscriptions/listen عند الحاجة.

الخادم

• إزالة بوابات التهيئة لطلبات العصر الحديث.
• إزالة الاعتمادية على Mcp-Session-Id.
• تنفيذ server/discover.
• استبدال الحالة المخفية بمقابض أو تخزين مشترك.
• إرجاع resultType.
• استبدال الطلبات المبادَرة من الخادم بـ MRTR.
• حماية requestState.
• التحقق من جميع inputResponses.
• إضافة اعتمادية للآثار الجانبية.
• إرجاع قوائم حتمية.
• نشر تلميحات تخزين مؤقت محافظة.
• ترحيل العمل طويل الأمد إلى امتداد Tasks.

البوابة والبنية التحتية

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

الأسئلة الشائعة

ما هو MCP 2026-07-28؟

هو مواصفة 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 تلقائيًا؟

لا. يتطلب SDK v2 إعداد تفاوض إصدارات صريحًا لاستخدام البروتوكول الحديث.

استخدم التفاوض التلقائي عندما يجب أن يعمل العميل مع خوادم حديثة وقديمة معًا.

التوصيات النهائية

يجعل MCP 2026-07-28 بنية MCP البعيدة أسهل في التحجيم والتوجيه والتخزين المؤقت والرصد. الخطر الرئيسي في الترحيل ليس مجرد إزالة رأس أو مصافحة، بل الحالة المخفية للتطبيق ومنطق التفاعل الذي قد لا يزال يعتمد عليهما.

قبل نشر البروتوكول الجديد:

اعثر على كل اعتماد على التهيئة وMcp-Session-Id.

1. انقل الحالة المطلوبة إلى مقابض صريحة أو تخزين مشترك.
2. نفّذ MRTR مع انتهاء صلاحية وحماية من الإعادة واعتمادية.
3. تحقّق من رؤوس MCP مقابل جسم JSON-RPC.
4. قسّم التخزينات المؤقتة حسب المستأجر ونطاق التفويض.
5. حصّن التحقق من جهة إصدار OAuth.
6. قِس حركة الطرق المهملة ونقل HTTP القديم.
7. نفّذ نشرًا كناريًا لمسارات البروتوكول الحديث والقديم قبل الإزالة.

عامل الترحيل كتغيير بنية تحتية لا كترقية SDK روتينية.

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