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

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

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

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

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

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

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

تُعد 2026-07-28 المراجعة الحالية للمواصفة اعتباراً من August 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 ويبقي تدفق الاستجابة مفتوحاً. إذا انقطع التدفق، لا يحتفظ الخادم بأي شيء، ويعيد العميل إرسال subscriptions/listen لاستعادته.

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

النشر: Reverse Proxy، وtimeouts، وhealth checks

تُعد نقطة نهاية 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، أي سطر يبدأ بنقطتين، باعتباره keep-alive أثناء فترات الخمول. وهذا يمنع الوسطاء من إنهاء مهلة الدفق أصلاً.

يحتاج 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 السلبيين على الخادم الأعلى، وشغّل فحص البروتوكول من نظام المراقبة لديك.

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

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

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

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

يعمل خادم MCP المحمي كخادم موارد OAuth 2.1. يجب أن يحمل كل طلب HTTP من العميل Authorization: Bearer <access token>، ويتحقق الخادم من الرمز المميز في كل طلب. ويشمل التحقق الجمهور: يجب أن يؤكد الخادم أن الرمز المميز صدر له تحديداً، وفقاً للمعيار RFC 8707 (مؤشرات الموارد لـ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، والتي يجب أن تطبقها خوادم MCP)، ويحدّد خادم التفويض، ثم ينفّذ التدفق. يحصل الرمز المميز الصالح ذي الصلاحيات غير الكافية على 403 Forbidden مع error="insufficient_scope" والنطاقات المطلوبة لتنفيذ تلك العملية.

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

ما الذي ينطبق على هذه المراجعة، وما الذي لا ينطبق

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

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

لذلك تحقّق من سلسلة المراجعة قبل أن تثق بأي من ذلك. إذا كان SDK لديك لا يزال يرسل initialize، فالجلسات لا تزال فعلية في عملية النشر لديك، ولا تزال المشكلات المرتبطة بالجلسات المذكورة أعلاه من مسؤوليتك. وينطبق الأمر نفسه على جانب العميل: لا تكون عملية وكيل تعمل على جهازك، مثل الإعداد الموضح في تشغيل وكيل برمجي على 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، وقد يجعل ذلك واجهة خلفية سليمة تبدو متوقفة. ثم افحص البروتوكول نفسه بإرسال server/discover عبر POST، إذ يجب على كل خادم 2026-07-28 تطبيقه، وتحقق من أن الرد هو HTTP 200 وأنه يسرد إصدار بروتوكول تستخدمه عملاؤك. تعني استجابة 404 مع خطأ JSON-RPC -32601 أن العملية تعمل، لكنها لا تخدم تلك الطريقة. وتعني استجابة 400 مع -32022 أن الإصدار الذي طلبته غير مدعوم في ذلك البناء.