تتيح مواصفة Model Context Protocol بتاريخ 28 يوليو 2026 تنظيم اتصال تطبيقات الذكاء الاصطناعي بالموارد والأدوات. وفي بيئة مؤسسية، يهمني ما يحدث بعد نجاح الاتصال: أي معلومات يمكن قراءتها، وأي فعل يمكن تنفيذه، وكيف نعرف المستخدم الذي سمح به؟ البروتوكول جزء من الحل، بينما تحتاج قواعد العمل إلى تصميم صريح.
أداة ضيقة الغرض أسهل للفهم
في تصور لنظام معاملات، أفضّل فصل البحث عن طلب عن تعديل حالته. الأولى تعيد معلومات مسموحًا بها، والثانية تتطلب تحققًا إضافيًا من الدور الوظيفي والمرحلة الحالية. كما ينبغي تحديد الحقول المقبولة بوضوح، بدل إتاحة أمر عام يستطيع تغيير أي جزء من السجل.
وتصبح تسمية الأداة ووصفها مفيدين عندما يعكسان أثرها الحقيقي. أداة إعداد مسودة لا ينبغي أن ترسلها تلقائيًا. وأداة القراءة لا ينبغي أن تحدث السجل ضمنيًا. هذا الفصل يسهل المراجعة الفنية، ويساعد المستخدم على فهم ما سيحدث عند اعتماد العملية.
التفويض لا ينتقل بلا تحقق
تؤكد اعتبارات الأمن في المواصفة التحقق من أن رمز الوصول موجّه إلى الخادم المقصود، وتحظر تمريره كما هو إلى خدمات أخرى. والمعنى العملي أن اتصال المساعد بخدمة لا يمنحه تلقائيًا تفويضًا مفتوحًا لبقية الأنظمة المرتبطة بها.
أقترح توثيق هوية المستخدم والغرض ونطاق الوصول لكل تكامل. وإذا احتاجت العملية إلى خدمة خارجية، تُراجع علاقتها بالتفويض الأصلي وطريقة حماية بياناتها. كما ينبغي التعامل مع أوصاف الأدوات والمحتوى الخارجي على أنها مدخلات تحتاج إلى تقييم، وليست تعليمات أعلى صلاحية من سياسة التطبيق.
أربع حالات قبل الإطلاق
- مستخدم يحاول الوصول إلى طلب خارج نطاقه الوظيفي.
- إعادة إرسال عملية سبق تنفيذها بعد انقطاع الاتصال.
- تغير حالة المعاملة بين عرض المسودة واعتمادها.
- تعطل الخدمة المرتبطة وبقاء العملية دون نتيجة مؤكدة.
تساعد هذه الحالات المقترحة على اختبار ما لا يظهر في العرض التجريبي الناجح. ومن المفيد أن يسجل النظام النتيجة النهائية لكل محاولة، وأن يفرق بين رفض العملية وفشل الاتصال وعدم التأكد من التنفيذ.
أرى أن أفضل بداية لتكامل من هذا النوع هي أداة قراءة محدودة ومهمة واضحة. وبعد التحقق من الصلاحيات وجودة السجل، يمكن دراسة إضافة إجراءات أخرى.