خوادم 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 وما قبله يتحدثون بنموذج المصافحة. وتسمّي المواصفة هذه المراجعات قديمة، وتسمّي المراجعات التي تستخدم البيانات الوصفية لكل طلب حديثة. يجب على الخادم الذي لا يدعم إلا هذه المراجعة، عند التعامل مع عميل أقدم، أن يجيب بـ405 Method Not Allowed على GET أو DELETE في نقطة نهاية MCP، وأن يتجاهل أي ترويسة Mcp-Session-Id من دون إنشاء واحدة أو إعادة إرسالها، وأن يتجاهل Last-Event-ID لأن التدفقات لا يمكن استئنافها. ويمكن لخادم يدعم العهدين أن يخدم كليهما عبر نقطة نهاية واحدة: يُخدم الطلب الذي يحمل _meta من دون حالة، بينما يحدد طلب initialize دلالات الجلسة الأقدم.

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

FAQ

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

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

هل ما زلت أحتاج إلى الجلسات الثابتة في موازن التحميل؟

ليس للطلبات العادية. في المراجعة 2026-07-28 يحمل كل POST إصدار البروتوكول والقدرات وبيانات الاعتماد الخاصة به، لذلك يمكن لأي نسخة متماثلة الاستجابة لأي طلب، ويكون التوزيع بالتناوب مناسباً. الشيء الوحيد طويل الأمد المتبقي هو دفق استجابة 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 مستقل. وتطبّق الخوادم التي يجب أن تواصل خدمة العملاء الأقدم سلوك المراجعة السابقة إلى جانب هذه المراجعة.

كيف أختبر صحة خادم MCP من دون مصافحة؟

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