الانتقال إلى المحتوى الرئيسي
“سحب البساط” هو خادم MCP يغيّر تعريفات أدواته بعد أن وافقت عليه — معيداً تعريف أداة موثوقة لتفعل شيئاً جديداً، أو مضيفاً واحدة بهدوء. يمسك OrcaRouter بهذا عند طبقة المخطط: يأخذ مجموعة أدوات كل خادم المُعلَنة كخط أساس ويعيد فحصها عند كل تحميل، فـالانحراف يفشل مغلقاً بدلاً من تقديم الأدوات المتغيّرة بصمت. هذه الصفحة هي مرجع حالة مخطط الخادم لكل خادم وما تعنيه كل حالة للحركة.

​
1. بصمة خط الأساس

عند أول اتصال تحسب البوابة تجزئة قانونية لمجموعة أدوات الخادم المُعلَنة وتخزّنها كخط الأساس المعتمَد:
  • تغطي التجزئة اسم كل أداة، ووصفها، ومخطط إدخالها JSON — بالضبط السطح الذي سيغيّره سحب البساط (أداة تكتسب وسيط تسريب، أو وصف مُسلَّح لحقن المطالبة يقلب التجزئة).
  • إنها مستقلة عن الترتيب: خادم يعيد ترتيب قائمة أدواته، أو يعيد ترتيب مفاتيح داخل مخطط، لا يبدو كتغيير. فقط تغيير تعريف حقيقي يحرّك التجزئة.
عند كل فحص لاحق تعيد البوابة تجزئة الأدوات الحية وتقارنها بخط الأساس المخزّن. هذا فحص لكل خادم — لا يعتمد على أي قاعدة تؤلّفها.

​
2. دورة حياة حالة المخطط

كل خادم مسجّل يحمل schema_status. الحالات وكيف تؤثر على ما إذا كانت أدوات الخادم تُقدَّم:
الحالةالمعنىالأدوات تُقدَّم؟
(بلا خط أساس)أول استخدام — لم يُسجَّل خط أساس بعد.وضعية الاكتشاف: نعم (ثقة عند أول استخدام — يُلتقَط المخطط الحالي كخط الأساس). وضعية صارمة: لا — انظر pending أدناه.
verifiedالمخطط الحي يطابق خط الأساس المعتمَد.نعم
changedكُشِف انحراف — المخطط الحي يختلف عن خط الأساس.لا — يفشل مغلقاً
pendingخادم بلا خط أساس تحت وضعية صارمة (بلا ثقة عند أول استخدام) — بانتظار الموافقة.لا — يفشل مغلقاً
quarantinedاحتجز مسؤول الخادم.لا — يفشل مغلقاً
الحالات المغلقة الثلاث — changed، وpending، وquarantined — كلها توقف أدوات الخادم عن التقديم عبر البوابة. verified يقدّم دائماً؛ والخادم بلا خط أساس يقدّم فقط تحت وضعية الاكتشاف (ثقة عند أول استخدام) ويُحتجَز كـpending تحت الوضعية الصارمة. الانحراف لا يمرّ أبداً بصمت.

​
3. ماذا يحدث عند الانحراف

عندما تجد إعادة فحص أن المخطط الحي لم يعد يطابق خط الأساس:
1

الحالة تنقلب إلى changed

schema_status للخادم يصير changed ويُسجَّل طابع انحراف زمني.
2

الأدوات تتوقف عن التقديم

تفشل البوابة مغلقة: تُحجَب أدوات ذلك الخادم عن سطح MCP الموحَّد، فلا يستطيع وكيل استدعاء التعريفات المتغيّرة.
3

وحدة التحكم تُظهِره

يظهر الانحراف للمراجعة بحيث يستطيع مسؤول مقارنة مجموعة الأدوات الجديدة بالمعتمَدة.
4

أعِد أخذ خط الأساس أو احجر

يوافق مسؤول على المخطط الجديد (يعيد أخذ خط الأساس — تصير مجموعة الأدوات الحالية خط الأساس verified الجديد) أو يحجر الخادم. حتى يحدث أحدهما، يبقى الخادم مغلقاً.

​
4. إعادة الموافقة على خادم منحرف

إعادة أخذ خط الأساس استدعاء واحد (أو إجراء وحدة التحكم): 
POST /api/workspace/firewall/mcp_servers/:id/approve_schema
يتطلب دور Developer. يسجّل مجموعة الأدوات الحية كخط الأساس المعتمَد الجديد ويعيد الخادم إلى verified. (حجر خادم إجراء منفصل، لحين تقرر أن التغيير عدائي — approve_schema يعيد أخذ خط الأساس إلى verified فقط.) يُكتَب الإجراء إلى مسار التدقيق.
أعِد الموافقة فقط بعد أن تكون قد راجعت الفرق. الموافقة على مخطط منحرف دون فحصه تهزم الضابط — تخبر OrcaRouter أن تعريفات الأداة الجديدة (ربما الخبيثة) موثوقة.

​
5. أين يلائم هذا

كشف انحراف المخطط هو نصف طبقة المخطط من الدفاع ضد سحب البساط؛ والنصف الآخر هو التقييم لكل استدعاء على سطح mcp (كل tools/call يُفحَص مقابل سياستك عند الإرسال). معاً يغطيان “تغيّرت التعريفات” و”هذا الاستدعاء المحدد خطير”.

الدفاع ضد سحب البساط

صورة سحب البساط الكاملة — خط أساس المخطط إضافة إلى التقييم لكل استدعاء.

نظرة عامة على أمان MCP

بوابة MCP، والمهارات، والاعتمادات.

تسميم أدوات MCP

التهديد الذي تدافع عنه آلة الحالات هذه.

أحداث تدقيق MCP

مراقبة تغييرات المخطط وقرارات البوابة.