MCP يوصل الوكيل إلى API، لكنه لا يقرر بنفسه الوصول على مستوى الحقول
باستخدام MCP، أصبح ربط وكيل AI بواجهة API داخلية أمرًا سهلًا. السؤال الصعب هو أي الحقول يمكن للوكيل قراءتها وأي الإجراءات يمكنه تنفيذها، وهذا لا يقرره MCP بنفسه.
في 29 سبتمبر 2026، نُشر على The New Stack مقال لمؤسس Apollo GraphQL، مات ديبرغاليس: الوصول إلى نظام عبر MCP سهل اليوم، لكن ما يمكن للوكيل رؤيته بعد الاتصال لا يقرره MCP بنفسه.
الوصول اليوم سهل، أما الرؤية فلا
يستخدم المقال مثال فريق العمليات: يطلب موظف من المساعد تحديد أي طلب لن يلحق بموعد الشحن، والتحقق من المخزون في مستودعات أخرى، وإنشاء طلبات نقل حيث يغطي ذلك النقص. تحتاج العملية إلى الطلبات الحالية والمخزون المتاح والكتابة الراجعة.
يمكن جعل API الداخلي متاحًا للوكيل عبر بناء خادم MCP، لكن السؤال الصعب هو ما يحق له رؤيته بعد الاتصال.
لماذا لا تحل الحلول الواضحة المشكلة
قد يعيد API إدارة الطلبات أكثر بكثير من حالة الطلب: بيانات شخصية، وتفاصيل مالية وتفاصيل احتيال، ومعلومات تشغيلية لا ينبغي أن تخرج خارج الشبكة الموثوقة. في تطبيق عادي يقرر الخادم ذلك: يتحقق من الصلاحيات ويعيد العرض المناسب فقط.
الوكيل يكسر هذا المخطط: الأداة التي تمرر كل شيء من النظام الأعلى تشكل خطرًا أمنيًا. أما تصفية الاستجابة فتخلق مشكلة ثانية: قسم المالية يحتاج عرضًا مختلفًا للطلبات، والدعم يحتاج جزءًا من الملاحظات الداخلية، وفريق آخر يربط نظام المخزون، فتتراكم عشرات الأدوات المتداخلة.
عقد على مستوى الحقول
الحل، بحسب الكاتب، هو عقد على مستوى الحقول يحدد بدقة ما يمكن لكل وكيل رؤيته وما يمكنه فعله. يحدد MCP اكتشاف الأدوات واستدعاءها، ويحدد العقد حدود الوصول؛ وكلتا الطبقتين ضروريتان.
كطريق عملي يقترح الكاتب GraphQL: يتضمن الطلب الحقول المطلوبة فقط، مثل status وshipBy، ولا تعود في الاستجابة إلا هي. إذا طلب الوكيل حقلًا حساسًا مثل internalFraudScore أو customerSSN، يمكن للخادم رفض الطلب أو جعل هذه الحقول غير متاحة. القاعدة تخص الحقل نفسه.
تعمل الكتابة بالطريقة نفسها: إذن القراءة فقط لن يسمح بإنجاز العمل، والوصول غير المحدود سيتيح للوكيل تغيير المخزون أو إلغاء طلب أو إرجاع مبلغ. تظهر عملية تجارية منفصلة، مثل requestInventoryTransfer، كعملية منفصلة: يُتحقق من الإذن وقت التشغيل، بينما يتحقق الخدمة الأساسية من توافر المخزون والموافقات المطلوبة. لا حاجة لتغيير APIs التجارية: تقف الطبقة فوق خدمات REST أو gRPC أو SOAP موجودة.
ماذا يعني ذلك عمليًا
التوصية ليست محايدة: الكاتب يدير شركة تنتج GraphQL. لكن الحجة نفسها تعمل بمعزل عن أداة محددة: يحتاج وصول الوكيل إلى حد منفصل ومحدد بوضوح بين API والأداة، على مستوى كل حقل وكل إجراء. وبحسب الكاتب، يعمل عقد كهذا منذ أكثر من عشر سنوات في أنظمة حقيقية ويخدم مليارات المعاملات في شركات مثل Shopify وNetflix وAirbnb وExpedia Group وWalmart.
SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي
نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.