جودة MCP Server لا تقاس بعدد الأدوات فقط. Tool واحدة بعقد واضح قد تكون أكثر فائدة من عشر أدوات بأسماء غامضة ومدخلات حرة. ال ـAgent يعتمد على الاسم والوصف وال ـJSON Schema ليقرر متى يستدعي الأداة وكيف يمرر البيانات. ثم يحتاج نتيجة منظمة وأخطاء مستقرة ليبني الخطوة التالية. في أدوات المتصفح يجب أن يضاف إلى ذلك Profile isolation والصلاحيات لأن target الخطأ قد يعني حسابًا مختلفًا تمامًا.
اسم الأداة يجب أن يصف فعلًا واحدًا
اختر `profile_open` أو `workflow_run` أو `page_capture` بدل أسماء عامة مثل `browser_action`. الفعل الواحد يجعل الصلاحيات والاختبارات أوضح. إذا كانت Tool تفعل create-or-update-or-delete حسب parameter فهي أصعب في المراجعة وأكثر قابلية لاختيار خاطئ. قسمها عندما تختلف المخاطر أو side effects.
Schema ضيقة تقلل التخمين
استخدم enum بدل string مفتوحة للحالات المعروفة، وحدد formats والحدود والأطوال. إذا كانت Tool تتطلب profileId فلا تسمح بخلط username أو اسم المجموعة في نفس الحقل إلا إذا كان resolver رسميًا. اجعل الحقول الاختيارية اختيارية فعلًا؛ لا تطلب 15 parameter ثم تتجاهل معظمها. وأعد errors قبل تنفيذ أي side effect إذا فشل validation.
خطوات عملية
- حدد minimum input اللازم للفعل.
- استخدم types/enums دقيقة.
- أضف descriptions للأجزاء غير البديهية.
- ارفض unknown أو contradictory fields عند الخطورة.
- اختبر boundary values وال ـmissing required fields.
النتيجة يجب أن تكون قابلة للاستخدام في Tool أخرى
إذا فتحت Profile، أعد profileId و windowId وحالة الفتح و URL الحالية بدل رسالة `Success`. إذا أنشأت Task، أعد taskId و status. IDs المستقرة تسمح لل ـAgent بربط الخطوات دون إعادة البحث بالأسماء. أضف `changed` أو `reused` عند العمليات idempotent حتى يعرف العميل هل وقع أثر جديد.
قائمة مراجعة
- النتيجة JSON منظمة.
- IDs الأساسية موجودة.
- status machine-readable.
- لا تُرجع secret غير مطلوب.
- الأخطاء لها code ثابت و details محدودة.
الصلاحيات جزء من العقد
Tool قد تكون موجودة في catalog لكن تنفيذها يعتمد على Actor و scope. افحص الصلاحية داخل domain action نفسها وليس في واجهة MCP فقط. لو هناك `profile_read` و`profile_delete` فالمخاطر مختلفة. أضف confirmation token أو policy للأفعال غير القابلة للتراجع عندما يكون المنتج يحتاج ذلك. ولا تسمح للعميل بتمرير actorId عشوائيًا لتجاوز الهوية الموثقة.
اختبر العقد كمنتج مستقل
اكتب tests لل ـschema وللأخطاء ولل ـidempotency وللتأثيرات الجانبية. شغل official MCP client أو protocol tests للتأكد أن discovery و call results صحيحة. اختبر أيضًا tool chaining: output من resolver يدخل مباشرة في action. عند تعديل backend، اختبارات العقد تمنع كسر العملاء حتى لو الواجهة البشرية ما زالت تعمل.
قائمة مراجعة
- List tools يرجع schema صالحًا.
- happy path مختبر.
- permission denied مختبر.
- invalid input لا ينفذ أثرًا.
- إعادة نفس الطلب لا تضاعف أثرًا عندما يجب أن يكون idempotent.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…