إعداد MCP: افهم البنية والاتصال والصلاحيات
تنظيم إعداد MCP في ثلاث خطوات يسهّل التشخيص: راجع بنية الملف، ثم اختبر الاتصال، ثم قيّم الخادم والصلاحيات المطلوبة. فحص البنية يغطي الخطوة الأولى؛ أما الاتصال والثقة فيحتاجان تحققًا منفصلًا.
ثلاثة أسئلة مختلفة
الأول: هل يستطيع البرنامج قراءة الإعداد؟ الثاني: هل يعمل الاتصال والخادم؟ الثالث: هل المصدر والصلاحيات مناسبان لبياناتك؟ إجابة نعم عن السؤال الأول لا تجيب عن البقية.
MCP يربط العميل بخادم يقدّم إمكانات. قد يكون برنامجًا محليًا عبر stdio أو خدمة عبر HTTP؛ اختلاف وسيلة الاتصال يغيّر ما تحتاج إلى مراجعته في الإعداد والتشغيل.
المراجع: Model Context Protocol — Clients, servers and transports
تحقق من الصيغة التي يدعمها عميلك
يفحص ToolRoof مجموعة JSON محددة تحت mcpServers: إما command مع args وenv الاختياريين، أو url مع headers الاختيارية. وجود command وurl معًا خطأ هنا؛ أما الحقول غير المعروفة فتظهر تحذيرًا.
هذه ليست صيغة كل تطبيقات MCP. قد تكون للعميل حقول أو طريقة إعداد أخرى؛ راجع وثيقته بدل حذف إعداد صحيح لمجرد أنه خارج نطاق الفاحص. الأداة لا تشغّل الأمر ولا تزور العنوان ولا تختبر المصادقة.
التحذير ليس اكتشافًا شاملًا للأسرار
المعاملات ومتغيرات البيئة والرؤوس قد تحمل بيانات حساسة. الفاحص ينبه إلى أماكن تحتاج مراجعة دون أن يثبت أن كل قيمة فيها سر أو أن الملف خالٍ من الأسرار عند غياب التحذير.
لا تشارك ملف إعداد حقيقيًا في بلاغ عام. استخدم مثالًا منقحًا، وراجع منشأ الخادم والصلاحيات عند توصيله في عميلك. وجود HTTPS أو JSON صحيح لا يمنح الخادم الثقة تلقائيًا.
مثال: نتيجة صحيحة ذات نطاق ضيق
الإعداد {"mcpServers":{"notes":{"url":"https://example.com/mcp","type":"http"}}} يصف خادمًا واحدًا وفق المجموعة المدعومة. اجتيازه يعني أن الشكل مقبول فقط؛ example.com هنا عنوان توضيحي، وليس خادم MCP جرى اختباره.
إضافة command إلى الخادم نفسه تجعل وسيلة الاتصال ملتبسة وتفشل الفحص. أما إضافة headers بالقيمة {"X-Mode":"demo"} فتنتج تحذير مراجعة بيانات مع بقاء البنية مقبولة؛ لا يعني التحذير أن كلمة demo اعتماد سري.