خوادم MCP عديمة الحالة: ما الذي تغيّر فعلياً؟

ما هو خادم MCP عديم الحالة

لا يحتفظ خادم MCP عديم الحالة بأي حالة خاصة بالعميل بين الطلبات. يحمل كل طلب إصدار البروتوكول، وقدرات العميل، وبيانات الاعتماد التي يحتاج إليها الخادم للرد عليه، لذلك يمكن لأي عملية على أي جهاز معالجة أي طلب. جعل MCP (اختصار Model Context Protocol، وهو تنسيق السلك الذي تستخدمه الوكلاء للوصول إلى الأدوات) ذلك قاعدة في المراجعة 2026-07-28، التي أزالت مصافحة initialize وجلسة HTTP التي كانت تعتمد عليها. يتناول هذا المحتوى جانب الخادم من هذا السلك، لذلك إذا كان جانب الوكيل لا يزال جديداً عليك، فإن مساراً تدريجياً لتعلّم وكلاء الذكاء الاصطناعي يشرح الحلقة التي تحدد متى تستدعي الأداة، قبل أن تصبح تفاصيل HTTP هذه مهمة.

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

بروتوكول Model Context Protocol هو بروتوكول عديم الحالة: توجد كل المعلومات اللازمة لمعالجة الطلب داخل الطلب نفسه. يعالج الخادم كل طلب بشكل مستقل؛ ولا ينبغي استنتاج أي حالة من الطلبات السابقة، حتى تلك الموجودة على الاتصال أو الدفق نفسه.

لا يعني انعدام الحالة أن خادمك لا يخزّن شيئاً. تظل قاعدة بياناتك وطابورك وذاكرة التخزين المؤقت موجودة. المقصود هو أن البروتوكول لا يحمل أي حالة على مستوى الاتصال، لذلك يجب ألا يتعامل الخادم مع اتصال أو عملية أو مقبس مفتوح على أنه بديل عن «هذا العميل أثناء محادثة جارية». يتضح هذا الفصل بسهولة في تطبيق يملك بياناته بالفعل: يجيب خادم MCP للقراءة فقط في openGym عن أسئلة تتعلق بسجل التدريب المخزّن في قاعدة بيانات التطبيق نفسه، ولا يعتمد أي شيء في هذا التخزين على الاتصال الذي وصل عبره طلب معيّن.

ما أزالته المراجعة 2026-07-28

تُعد 2026-07-28 المراجعة الحالية للمواصفة حتى أغسطس 2026. وبالمقارنة مع 2025-11-25، فإنها تزيل خمسة عناصر وُجدت لدعم الجلسات.

• طلب initialize وإشعار notifications/initialized. لا توجد أي مصافحة على الإطلاق (SEP-2575).
• ترويسة Mcp-Session-Id، وإنهاء الجلسة باستخدام HTTP DELETE (SEP-2567).
• دفق HTTP GET المستقل الذي كانت الخوادم تدفع الإشعارات عبره. استُبدل بـsubscriptions/listen، وهو POST عادي تكون استجابته دفقاً طويل الأمد.
• إمكانية استئناف دفق SSE (الأحداث المرسلة من الخادم). أزيلت ترويسة Last-Event-ID ومعرّفات الأحداث لكل حدث، لذلك يؤدي انقطاع الدفق إلى فقدان الطلب الجاري، ويجب على العميل إعادة إرساله كطلب جديد مع معرّف طلب جديد.
• ping وlogging/setLevel وnotifications/roots/list_changed. أصبح مستوى السجل حقلاً لكل طلب، وهو io.modelcontextprotocol/logLevel في _meta.

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

لماذا كان من الصعب تشغيل نقل الجلسات في بيئة الإنتاج

في 2025-11-25 والإصدارات الأقدم، كان الخادم يستطيع إنشاء معرّف جلسة أثناء التهيئة وإعادته في الترويسة Mcp-Session-Id ضمن InitializeResult. وكان يجب على العميل إرسال هذه الترويسة مع كل طلب لاحق. وكانت نسخة البروتوكول المتفاوض عليها وقدرات العميل محفوظتين في ذاكرة الخادم، ومربوطتين بذلك المعرّف. وكان لكل خيار من هذه الخيارات تكلفة تشغيلية.

• كان إعادة التشغيل يتخلص من جدول الجلسات. وكانت المواصفة تتطلب من الخادم الرد بـ 404 Not Found على أي طلب يحمل معرّف جلسة منتهياً، كما كانت تتطلب من العميل البدء من جديد باستخدام InitializeRequest. وكان كل نشر يؤدي إلى إعادة اتصال لكل عميل متصل.
• لم تكن نسخة ثانية تعرف جلسات النسخة الأولى. وكان التوسع يتطلب توجيهاً ثابتاً في موازن التحميل، أو مخزناً مشتركاً للجلسات تقرأ منه كل نسخة مع كل طلب.
• كان جدول الجلسات يستهلك ذاكرة تزداد مع العملاء الخاملين. وكان DELETE اختيارياً، وكان العملاء الذين يغلقون الاتصال دون إرساله يتركون إدخالاتهم في الجدول.
• كان يمكن أن تختلف نتائج القوائم باختلاف الاتصال، لذلك كان التخزين المؤقت أمام الخادم غير آمن.

إزالة الجلسات تزيل المشكلات الأربع دفعة واحدة. وهذا هو التغيير الذي يستحق الفهم قبل تعديل أي إعداد.

ما تحمله كل مطالبة الآن

كل طلب POST إلى نقطة نهاية MCP مستقل عن غيره. ينتقل إصدار البروتوكول وإمكانات العميل في نص الطلب ضمن _meta، وتُعكس حقول محددة منهما في ترويسات HTTP كي يتمكن وسيط من التوجيه استناداً إليها دون تحليل JSON.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {"location": "Seattle, WA"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

يُشترط وجود io.modelcontextprotocol/protocolVersion وio.modelcontextprotocol/clientCapabilities في كل طلب. أما clientInfo فليس مطلوباً، مع أنه ينبغي للعملاء إرساله. ويُعد الطلب الذي يفتقد حقلاً مطلوباً مشوهاً، لذلك يجب على الخادم رفضه بخطأ JSON-RPC -32602 وHTTP 400 Bad Request.

تُعد ترويسة Mcp-Method مطلوبة في كل طلب. وتُعد Mcp-Name مطلوبة في tools/call وresources/read وprompts/get. يجب أن تتطابق قيمة الترويسة مع النص، وعلى الخادم الذي يعالج النص رفض أي عدم تطابق باستخدام 400 Bad Request ورمز الخطأ -32020 وHeaderMismatch. وُضعت هذه القاعدة لأن موازن تحميل يوجّه استناداً إلى الترويسة وخادماً ينفّذ استناداً إلى النص يمثلان مصدرين مختلفين للحقيقة. إذا استخدمت هذه الترويسات للتوجيه أو تحديد معدل الطلبات، فتحقق من MCP-Protocol-Version أولاً: لم تكن المراجعات السابقة تتحقق من تطابق الترويسة مع النص، ولذلك لا تكون قيمة الترويسة موثوقة في تلك الإصدارات.

أصبح عدم توافق الإصدار الآن خطأً عادياً خاصاً بالطلب، بدلاً من كونه فشلًا في المصافحة. يجيب الخادم الذي لا يطبّق الإصدار المطلوب باستخدام 400 Bad Request مع الخطأ -32022 وUnsupportedProtocolVersion، ويسرد الإصدارات التي يدعمها في data.supported. يختار العميل إصداراً من تلك القائمة ثم يعيد المحاولة.

أين انتقلت الحالة: الرموز المميزة والمؤشرات والاشتراكات

لم تختفِ الحالة، بل انتقلت إلى أماكن يمكنك رؤيتها وتسجيلها.

تنتقل بيانات الاعتماد إلى كل طلب. لا توجد جلسة لإسناد الهوية إليها، لذلك يُرسَل access token مع كل استدعاء HTTP وتُجرى صلاحيته في كل مرة. ترد التفاصيل في قسم المصادقة أدناه.

يجب أن تحمل المؤشرات موضعها بنفسها. يستخدم ترقيم الصفحات في tools/list وresources/list وprompts/list وresources/templates/list سلسلة cursor غير شفافة، ويجب ألا يحللها العملاء أو يعدّلوها. في الخادم ذي العملية الواحدة، كان من الشائع الاحتفاظ بالإزاحة في الذاكرة وربطها بالجلسة. عند عدم وجود جلسة، يجب أن يكون cursor كافياً لكي تستأنف أي replica عرض القائمة، لذلك شفّر الموضع داخل cursor ووقّعه، أو احتفظ به في مخزن تشترك فيه جميع replicas. يجب أن يعيد cursor غير الصالح -32602. وقّعه لأن cursor غير الشفاف يظل إدخالاً يرسله العميل، وتفك شفرة محتواه برمجيتك وتثق به.

ترتبط الاشتراكات بطلب، لا باتصال. يرسل العميل الذي يريد إشعارات التغييرات subscriptions/listen مع filter يحدد الأنواع التي يريدها: toolsListChanged وpromptsListChanged وresourcesListChanged وresourceSubscriptions. يرد الخادم بـnotifications/subscriptions/acknowledged ويُبقي stream الاستجابة مفتوحاً. إذا انقطع stream، لا يحتفظ الخادم بأي شيء، ويعيد العميل إرسال subscriptions/listen لاستعادته.

تصبح حالة التطبيق الممتدة عبر الاستدعاءات handle صريحاً. عندما يحتاج الخادم فعلاً إلى تذكّر شيء بين الاستدعاءات، تكون إجابة المواصفة هي identifier ينشئه الخادم ويرسله العميل مجدداً كوسيط tool عادي. يظهر هذا identifier في مخطط tool، ويمكن تسجيله، ولا يُستنتج أبداً من الاتصال. يستخدم خادم لديه بيانات فعلية لكل مستخدم، مثل خادم MCP للبريد الإلكتروني مستضاف ذاتياً، هذا النمط بدلاً من الجلسة: يكون identifier صندوق البريد أو المسودة وسيطاً في tool، ولذلك يمكن لأي replica متابعة الاستدعاء التالي. ولا تحتاج أدوات كثيرة إلى handle أصلاً: أداة بحث مدعومة بمثيل SearXNG الخاص بك تستقبل query وتعيد النتائج، من دون أي شيء يحتاج الاستدعاء التالي إلى استئنافه، ومن دون سبب للاهتمام بأي replica أجابت.

النشر: Reverse Proxy، والمهلات، وفحوصات الصحة

تُعدّ نقطة نهاية MCP مساراً واحداً يقبل POST. معظم حركة المرور عبارة عن طلب قصير واستجابة JSON، ويمكن لأي Proxy التعامل معها. الاستثناء هو الاستجابة المتدفقة، إذ تعمل الإعدادات الافتراضية للـProxy ضدك. وهذا هو الجزء الذي يتغير عند الانتقال من عرض تجريبي على حاسوب محمول إلى خادم MCP يعمل على VPS.

location /mcp {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 1h;
    proxy_send_timeout 1h;
}

تكتسب proxy_buffering off أهميتها لأن nginx يخزّن الاستجابات الممرّرة مؤقتاً افتراضياً، ما يحجز أحداث SSE إلى أن تمتلئ إحدى الذاكرات المؤقتة أو تنتهي الاستجابة. كما تطلب المواصفة من الخوادم إرسال X-Accel-Buffering: no في استجابات SSE، ويحترم nginx هذا الرأس؛ لذلك يرسل الخادم الصحيح إلى الـProxy الإعداد المناسب تلقائياً. اضبط التوجيه أيضاً، لأن هذا هو الجزء الذي تتحكم فيه.

تكون القيمة الافتراضية لـproxy_read_timeout هي 60 ثانية. إذا ظلّ تدفق subscriptions/listen خاملاً مدة أطول من ذلك، يغلقه nginx، لا خادمك. لذلك تظهر سجلاتك أن العملية سليمة، بينما يرى العميل أن التدفق انقطع. ارفع القيمة في موقع MCP فقط، لا على مستوى الخادم كله. ويُستحسن أيضاً أن ترسل الخوادم سطر تعليق SSE، أي سطراً يبدأ بنقطتين، كإشارة إبقاء حي أثناء فترات الخمول. يمنع ذلك الوسطاء من إنهاء مهلة التدفق.

يحتاج Caddy إلى إعدادات أقل. فهو يخزّن الاستجابة جزئياً افتراضياً لتحسين كفاءة الإرسال، ويفرغها فوراً عندما تحمل الاستجابة Content-Type: text/event-stream. لذلك يعمل البث دون توجيهات إضافية.

mcp.example.com {
	reverse_proxy 127.0.0.1:8080 {
		health_uri /healthz
		health_interval 10s
	}
}

انتبه إلى الهدف الذي يشير إليه فحص الصحة. لا توجّه فحصاً نشطاً إلى نقطة نهاية MCP باستخدام GET، لأن الخادم الذي يطبّق هذه المراجعة فقط يجيب بـ405 Method Not Allowed على GET وDELETE، بينما تكون طريقة فحص الصحة الافتراضية في Caddy هي GET. عندئذ سيضع الـProxy الواجهة الخلفية السليمة تماماً في حالة متوقفة. وفّر مساراً بسيطاً مثل /healthz للـProxy، وافحص البروتوكول بشكل منفصل باستخدام POST.

curl -sS https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

يعني 200 الذي يحمل قائمة supportedVersions أن العملية تعمل وتتحدث البروتوكول. ويعني 404 مع خطأ JSON-RPC هو -32601 أن العملية تعمل، لكنها لا توفّر server/discover، الذي يجب على كل خادم 2026-07-28 تطبيقه. ويعني 400 مع -32022 أن أداة الفحص طلبت إصداراً لا يدعمه هذا البناء، وهذا بالضبط ما تريد اكتشافه بعد ترقية اعتماد. لا يوفّر nginx مفتوح المصدر فحوصات صحة نشطة. لذلك استخدم max_fails وfail_timeout السلبية على upstream، وشغّل فحص البروتوكول من نظام المراقبة لديك بدلاً من ذلك.

بعد ذلك، لا تؤدي إعادة التشغيل التدريجية إلا إلى فقدان الطلبات قيد التنفيذ. نفّذ Drain، وانتظر انتهاء طلبات POST المفتوحة، ثم شغّل العملية الجديدة، وسيعيد العملاء إرسال ما فشل منها. الشيء الوحيد الذي سيُغلق أيضاً هو أي تدفق subscriptions/listen مفتوح، لأن هذا التدفق اتصال حي بعملية محددة. أزالت خاصية انعدام الحالة الحاجة إلى تثبيت الجلسة. لكنها لم تُزل ارتباط الاتصال بالنسبة إلى تدفق مفتوح حالياً، ولا يمكن لأي قاعدة توجيه إصلاح ذلك. يستطيع العميل التمييز بين الحالتين: التدفق الذي ينتهي بنتيجة subscriptions/listen الفارغة أُغلق بسلاسة، أما التدفق الذي ينتهي دونها فقد انقطع، ويمكن للعميل اعتبار ذلك سبباً لإعادة الاتصال.

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

كيف تتغير المصادقة عند عدم وجود جلسة

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

يعمل خادم MCP المحمي كخادم موارد OAuth 2.1. يجب أن يحمل كل طلب HTTP من العميل Authorization: Bearer <access token>، ويتحقق الخادم من الرمز المميز في كل طلب. ويشمل التحقق الجمهور؛ إذ يجب على الخادم تأكيد أن الرمز المميز صدر له تحديداً، وفقاً للمعيار RFC 8707 (Resource Indicators for OAuth 2.0)، وألا يقبل رموزاً مميزة مخصصة لأي جهة أخرى أو يعيد تمريرها. يطلب العملاء الجمهور الصحيح بإرسال المعامل resource مع URI الأساسي للخادم.

يبدأ الاكتشاف من خلال تحدٍّ. عندما يصل طلب من دون رمز مميز صالح للاستخدام، يجيب الخادم بـ 401 Unauthorized.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

يقرأ العميل resource_metadata، ثم يجلب ذلك المستند (RFC 9728، OAuth 2.0 Protected Resource Metadata، الذي يجب على خوادم MCP تنفيذه)، ويحدد خادم التفويض، ثم ينفذ التدفق. إذا كان الرمز المميز صالحاً لكنه لا يتضمن أذونات كافية، فستكون الاستجابة 403 Forbidden مع error="insufficient_scope" والنطاقات المطلوبة لتنفيذ العملية.

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

ما هو صحيح بخصوص هذه المراجعة، وما هو ليس كذلك

يصف كل ما سبق المراجعة 2026-07-28. هذا الوصف لا يغطي MCP إلى الأبد، ولا يصف الخادم الذي قمت بنشره في العام الماضي.

لا تزال العملاء والخوادم التي تعمل بالإصدار 2025-11-25 أو ما قبله تستخدم نموذج المصافحة (handshake). تُسمي المواصفات تلك المراجعات بـ "القديمة" (legacy)، وتُسمي المراجعات التي تعتمد على البيانات الوصفية لكل طلب بـ "الحديثة" (modern). يُنصح الخادم الذي يدعم هذه المراجعة فقط، عند التعامل مع عميل أقدم، بأن يجيب بـ 405 Method Not Allowed على طلبات GET أو DELETE في نقطة نهاية MCP، وأن يتجاهل أي ترويسة Mcp-Session-Id دون إنشائها أو إعادة إرسالها، وأن يتجاهل Last-Event-ID لأن التدفقات (streams) غير قابلة للاستئناف. يمكن للخادم ثنائي الحقبة خدمة كلا النوعين على نقطة نهاية واحدة: الطلب الذي يحمل _meta حديثة يُخدم بدون حالة (stateless)، بينما يختار طلب initialize دلالات الجلسة القديمة.

لذا، تحقق من سلسلة المراجعة قبل الوثوق بأي مما سبق. إذا كانت مجموعة تطوير البرمجيات (SDK) الخاصة بك لا تزال ترسل initialize، فستظل الجلسات حقيقية في بيئة النشر الخاصة بك، وستظل المشكلات المتعلقة بالجلسات المذكورة أعلاه من مسؤوليتك. ينطبق الأمر نفسه على جانب العميل: عملية الوكيل على جهازك الخاص، مثل الإعداد الموضح في تشغيل وكيل برمجي على خادم VPS، تكون عديمة الحالة بهذا المعنى فقط إذا كانت المكتبة التي تستخدمها تتحدث بمراجعة حديثة. اقرأ الإصدار الذي يتفاوض عليه وقت التشغيل (runtime)، ثم اقرأ المراجعة المطابقة في المواصفات، وتعامل مع هذه الصفحة على أنها تصف مراجعة واحدة مسماة بدلاً من البروتوكول بشكل عام.

FAQ

هل يعني خادم MCP عديم الحالة (stateless) أنني لا أستطيع تخزين أي شيء؟

لا. مصطلح "عديم الحالة" يصف البروتوكول، وليس تطبيقك. قواعد البيانات، وقوائم الانتظار، وذاكرات التخزين المؤقت تعمل جميعها تماماً كما كانت من قبل. ما يتغير هو أن الحالة التي تمتد عبر عدة استدعاءات يجب أن يُشار إليها بمعرف صريح يمرره العميل في كل طلب، مثل مقبض (handle) ينشئه الخادم في وسيط أداة. ما لا يمكنك فعله هو استنتاج السياق من الاتصال: تنص المواصفات على أنه لا يجب على الخادم الاعتماد على طلبات سابقة عبر نفس الاتصال لتحديد القدرات، أو إصدار البروتوكول، أو هوية العميل، لأن كل طلب يوفر هذه المعلومات في _meta.

هل لا أزال بحاجة إلى جلسات لاصقة (sticky sessions) على موازن التحميل الخاص بي؟

ليس للطلبات العادية. بموجب المراجعة 2026-07-28، يحمل كل طلب POST إصدار البروتوكول الخاص به، وقدراته، وبيانات اعتماده، لذا يمكن لأي نسخة متماثلة (replica) الإجابة على أي طلب، ويعمل التوزيع الدوري (round-robin) بشكل جيد. الشيء الوحيد طويل الأمد المتبقي هو تدفق استجابة subscriptions/listen، وهو اتصال مفتوح واحد بعملية واحدة. ينتهي هذا الاتصال عند انتهاء تلك العملية، ويقوم العميل بإعادة إرسال subscriptions/listen لإعادة إنشائه. هذا يتعلق بعمر الاتصال وليس بارتباط الجلسة، ولا توجد قاعدة توجيه تمنع ذلك.

ماذا حدث لـ Mcp-Session-Id وتدفق HTTP GET؟

تمت إزالة كلاهما في المراجعة 2026-07-28، بموجب SEP-2567 و SEP-2575. يُنصح الخادم الذي يطبق هذه المراجعة فقط بأن يجيب بـ 405 Method Not Allowed على GET و DELETE في نقطة نهاية MCP، وأن يتجاهل ترويسة Mcp-Session-Id بدلاً من إعادة إرسالها. تنتقل إشعارات التغيير التي يبدأها الخادم الآن عبر تدفق استجابة طلب subscriptions/listen بدلاً من تدفق GET مستقل. الخوادم التي يجب أن تستمر في خدمة عملاء أقدم تطبق سلوك المراجعة السابقة جنباً إلى جنب مع هذه المراجعة.

كيف أقوم بفحص سلامة (health check) خادم MCP بدون مصافحة؟

استخدم مستويين. وجّه الفحص النشط للمخزن المؤقت (proxy) إلى مسار HTTP عادي يخدمه تطبيقك، لأن طلب GET إلى نقطة نهاية MCP سيعيد بشكل صحيح 405 وقد يؤدي إلى وضع علامة "معطل" على خادم خلفي سليم. بعد ذلك، افحص البروتوكول نفسه عن طريق إرسال طلب POST لـ server/discover، وهو ما يجب على كل خادم 2026-07-28 تنفيذه، وتأكد من أن الرد هو HTTP 200 ويسرد إصدار بروتوكول يستخدمه عملاؤك. طلب 404 مع خطأ JSON-RPC -32601 يعني أن العملية قيد التشغيل ولكنها لا تخدم تلك الطريقة، وطلب 400 مع -32022 يعني أن الإصدار الذي طلبته غير مدعوم من قبل ذلك البناء (build).