منذ بداية يوليو، خادم MCP Trigger الخاص بي يعيد “No bridge acquired” على كل استدعاء أداة. نقطة نهاية SSE نشطة، mcp-remote متصل، لكن الجسر لم يتم تهيئته أبداً. كان يعمل بشكل جيد في أواخر يونيو. مثيل سحابي، سير عمل يستخدم Execute Workflow sub-workflows كأدوات MCP. هل وجد أحد حلاً؟
مرحباً @Munish_Gupta، بينما تنتظر الرد، إليك بعض الأشياء التي قد تساعدك:
الموارد المقترحة
تم المطابقة تلقائياً مع سؤالك.
المستندات:
المنتدى:
@Gonzalo_Romero_Herna، @Inshal_Amir، @Patrik_Breitenmoser - لقد ساعدتم مع مشاكل مشابهة من قبل، هل يمكنكم إلقاء نظرة؟
مقترح تلقائياً من قبل بوت مجتمع n8n. إنه نسخة تجريبية - يرجى مشاركة ملاحظاتك هنا.
أهلاً @Munish_Gupta مرحباً بك!
تأتي هذه السلسلة من محيِّم التعابير الخاص بـ n8n وتُطلق فقط عندما تكون محرك الـ vm التجريبي نشطاً. يحل مشغّل MCP Server Trigger معاملات الأداة خارج نافذة isolate التي يحتاجها هذا المحرك، لذا ينجح الاتصال والقائمة الأدوات بشكل صحيح بينما كل استدعاء يفشل عند النقل دون توليد تنفيذ فرعي. N8N_EXPRESSION_ENGINE متغير ذاتي الاستضافة بدون معادل سحابي، لذا يجب على help@n8n.io التحقق مما إذا كان vm مفعّلاً على نسختك وإعادته إلى الإصدار القديم. أرسل لهم معرّف سير العمل والسلسلة الخطأ الدقيقة والتفاصيل بأن الاستدعاء يفشل في ميلي ثانية دون توليد تنفيذ فرعي.
حتى يتم تبديله، اكشف سير العمل الفرعية من خلال MCP على مستوى النسخة بدلاً من عقدة المشغّل. انتقل إلى Settings > Instance-level MCP، فعّل الوصول، شغّل “Available in MCP” على كل سير عمل فرعي، ثم وجّه عميلك إلى:
https://<your-n8n-domain>/mcp-server/http
يشغّل العميل سير العمل باستخدام execute_workflow ويمرر الوسائط مباشرة، لذا لا توجد تعابير $fromAI() في عقدة الأداة تحتاج إلى الحل. تشغّل هذه الأداة النسخة المنشورة من سير العمل.
مرحباً @Munish_Gupta، كلمة “bridge” في هذا الخطأ مضللة — فليس لها علاقة بجسر نقل MCP. إنها جسر V8 isolate الخاص بـ n8n داخل محيط تقييم التعابير، وهذا هو السبب في أن كل عرض على مستوى النقل يبدو صحياً: نقطة نهاية SSE مباشرة، mcp-remote متصلة، قائمة الأدوات صحيحة. طبقة النقل بخير. الفشل يحدث لاحقاً، عند حل معاملات الأداة.تحديداً: عندما تكون محرك التعابير التجريبي vm نشطاً، يحل مشغل MCP Server Trigger معاملات الأداة خارج نافذة isolate التي يتطلبها هذا المحرك، لذلك تنجح المصافحة وtools/list بينما كل tools/call تفشل قبل أن تبدأ سير العمل الفرعي الخاص بك.أكد هذا في حوالي خمس دقائق:1. اعمل نسخة من أحد أدواتك.2. في النسخة، استبدل كل مدخل $fromAI() برمز حرفي.3. استدعِ كليهما من عميلك.- يعمل الرمز الحرفي، $fromAI() يفشل → تم التأكيد. إنها حل المعاملات، وليس أسالب العمل الفرعية الخاصة بك.- كلاهما يفشل → يحدث شيء آخر؛ أرسل التنفيذ.افتح أيضاً تنفيذاً فاشلاً وابحث عن بصمة هذه: مدة قصيرة جداً (عشرات الميلي ثانية)، مخرجات فارغة، وعدم ظهور تنفيذ فرعي. إذا لم يظهر تنفيذ سير العمل الفرعي في قائمة الإجراءات، فقد توقف عند النقل قبل تشغيل سير العمل الخاص بك كلياً.تخطَّ هذه — تبدو ذات صلة لكنها ليست السبب: إعادة تسجيل الموصل، التبديل من SSE → Streamable HTTP، إعادة تثبيت أو إعادة تثبيت mcp-remote.نظراً لأنك على Cloud، N8N_EXPRESSION_ENGINE هو متغير بيئة ذاتي الاستضافة بدون معادل Cloud وبدون مبدل واجهة المستخدم، لذا لا يمكنك عكسه بنفسك. أرسل بريداً إلى help@n8n.io يتضمن:- معرّف سير العمل الخاص بك والإصدار Cloud الدقيق- سلسلة الخطأ الدقيقة- أن قائمة الأدوات صحيحة لكن كل استدعاء يفشل- أن الاستدعاءات تفشل في ميلي ثانية بدون تنفيذ فرعي يُرسل- نتيجة الرمز الحرفي مقابل $fromAI() الخاصة بك واسأل مباشرة: “هل تم تعيين N8N_EXPRESSION_ENGINE إلى vm على المثيل الخاص بي؟ يرجى عكسه إلى legacy.” كونك محدداً بهذه الطريقة هو ما يمنعه من التوجيه إلى استكشاف أخطاء MCP العام.حل مؤقت أثناء انتظارك: تجاوز مشغل MCP Server Trigger بالكامل وعرّض أسالب العمل الفرعية من خلال MCP على مستوى المثيل. الإعدادات → MCP على مستوى المثيل → تفعيل الوصول، ثم شغّل “متاح في MCP” لكل سير عمل فرعي، وأشر عميلك إلى:https://<your-n8n-domain>/mcp-server/httpالعميل يستدعيها عبر execute_workflow ويمرر الحجج مباشرة، لذا لا يضطر تعبير $fromAI() إلى الحل في عقدة أداة. تحذيرات اثنان: يشغّل النسخة المنشورة من كل سير عمل، لذا احفظ وانشر أولاً؛ وأسماء الأدوات والأوصاف تأتي من اسم/وصف سير العمل بدلاً من إعداد عقدة الأداة الخاصة بك، لذا ستبدو قائمة أدوات العميل مختلفة عما لديك الآن.شيء واحد قد يساعد في تضييق النطاق — ما إصدار Cloud الدقيق الذي أنت عليه؟ “في وقت جيد من أواخر يونيو، مكسور في أوائل يوليو” ربما يحدّ الإصدار الذي فعّل هذا على المثيل الخاص بك.
لقد فحصنا هذا ويبدو أنه قد تم إصلاحه في إصدار حديث. يرجى التحديث والتحقق مما إذا كنت لا تزال تواجه نفس المشكلة.
شكراً لكم. تم حل المشكلة عند تحديث إصدار n89.