في الفصل السابق شغّلنا وكيلاً أدنى يربط الأدوات بالعقل (LLM) ويدير الحلقة بنفسه. بذلك الشعور أدركت — أنّ قدرة الوكيل الفعلية تُحسم تقريباً بـ«أيّ أدوات هو موصول بها». في هذا الفصل نخرج من عناء صناعة تلك الأدوات في كلّ مرّة، ونتعلّم كيف نربط بالأدوات والبيانات الخارجية بطريقة معيارية عبر معيار موحّد اسمه MCP (Model Context Protocol). وُلد MCP في Claude، وصار الآن معياراً للربط ينتشر في الصناعة كلّها.
الهدف هو «أن تربط بأمان عبر معيار موحّد دون صناعة الأدوات بنفسك»
لماذا ربط الأدوات هو جوهر الوكيل
الـLLM بذاته، مهما بلغ ذكاؤه، لا يستطيع إلا «توليد الكلمات». أن يعرف أحدث عدد في المخزون، أو أن يكتب سطراً واحداً في ملف، مستحيلٌ بلا وسيلة تلمس العالم الخارجي. وما يجعل الوكيل يدير حلقة «البحث، والتنفيذ، والتحقّق» ليس إلا امتلاكه أدوات تؤثّر في الخارج.
أي إنّ سقف قدرة الوكيل تحسمه جودة الأدوات الموصولة وعددها. بالـLLM نفسه، يختلف ما يمكن فعله اختلافاً تامّاً بين وكيل لا يملك إلا آلة حاسبة، ووكيل موصول بقاعدة بيانات وبحث وملفات وواجهات API داخلية. وليس نادراً أن يزيد ربطُ أداة جيّدة بدقّة القدرةَ المحسوسة أكثر من استبدال العقل بأرقى منه.
💡 «توفّر الأدوات» أهمّ من «الذكاء». حتى الشخص البارع لا يستطيع شيئاً وصندوق أدواته فارغ. كثيرٌ من وقت تطوير الوكلاء يُنفق في الواقع على تصميم «أيّ أداة نعطي وكيف نعطيها بأمان». هذا الفصل هو صميم ذلك.
حدود تعريف الأدوات الخام
في الفصل السابق عرّفنا الأداة بأيدينا. كتبنا دالّة، ومرّرنا اسمها ووسائطها ووصفها إلى الـLLM، وحين يأتي الاستدعاء ننفّذ ونعيد النتيجة — هذا المسار نفسه صحيح، وما يزال الأساس. المشكلة أن نصنع هذا من جديد في كلّ مرّة، ولكلّ أداة، ولكلّ مشروع.
لنتأمّل مثلاً «أداة تبحث في قاعدة بيانات». تكتب معالجة الاتصال، وتركّب الاستعلام، وتنسّق النتيجة، وتعالج الأخطاء، وتتعامل بأمان مع بيانات الاعتماد… هذه الحزمة نفسها ينفّذها كلّ واحد على حدة في مشروعك، وفي الفريق المجاور، وبلغة أخرى. الأداة نفسها يعيد مطوّرو العالم اختراع عجلتها مراراً — هذا واقع تعريف الأدوات الخام.
الأداة المكتوبة لمشروع بعينه مقيّدة بذلك الإطار وتلك اللغة، فيصعب نقلها إلى غيرها.
لو ربطت M نوعاً من الأدوات بـN منصّة وكلاء، فنظرياً تحتاج N×M من شيفرات الربط.
كلّما تغيّرت مواصفات الجهة الموصولة، لزمك أن تدور تصلح واحدةً واحدة أدواتك المبعثرة هنا وهناك.
هذا يشبه كثيراً زمن كانت كلّ ملحقٍ يحتاج كابلاً خاصّاً. للطابعة منفذها الخاصّ، وللفأرة منفذها الخاصّ — وكلّما زادت الأجهزة انفجرت أنواع طرق الوصل. لو وُجد «منفذ موحّد» لزال هذا العناء دفعةً واحدة. وهنا يظهر MCP.
ما هو MCP ― المعيار الموحّد لربط الأدوات
MCP (Model Context Protocol) هو معيار مفتوح لربط الذكاء الاصطناعي بالأدوات والبيانات الخارجية بطريقة معيارية. أطلقته Anthropic أواخر 2024 لأجل Claude، ثم دعمته أدوات وخدمات ذكاء اصطناعي متنوّعة. وحتى 2026 صار يُتبنّى واسعاً عبر الشركات، وينمو تحت إدارة محايدة ليصير معياراً صناعياً. المهمّ أنه ليس منتج شركة واحدة، بل مواصفة موحّدة يستطيع الجميع تنفيذها.
إن أوجزنا فكرة MCP في كلمة فهي «USB لربط أدوات الذكاء الاصطناعي». كما أنّ ظهور USB جعل ملحقات أيّ مصنّع تعمل بالمنفذ نفسه، فالأداة المتوافقة مع MCP يستطيع استخدامها أيّ وكيل متوافق مع MCP بمنطق «صِلها فتعمل». حين يتّبع صانعُ الأداة ومستخدمُها الاتفاق نفسه، ينطوي جحيم تركيبات N×M إلى «N+M».
هنا يقع الوكيل الذي تصنعه، أو تطبيقات مثل Claude. هو الجهة التي تستفسر الخادم «ما الأدوات الموصولة الآن؟» وتستدعي ما تلزم منها.
الجهة التي تنشر وظائف كمعالجة الملفات وبحث قواعد البيانات وربط SaaS مجمّعةً كـ«أدوات». يستطيع خادم واحد أن يحمل عدّة أدوات.
يتحادث الطرفان بخطوات محدّدة. حين يتّصل العميل، يستقبل أوّلاً من الخادم «قائمة الأدوات المتاحة» و«وصف كلٍّ منها ووسائطها». ينظر الـLLM في القائمة، فيختار الأداة الموافقة للهدف ويستدعيها، فينفّذها الخادم ويعيد النتيجة — وأن يتمّ هذا الذهاب والإياب دون تنفيذ خاصّ لكلّ أداة هو جوهر MCP.
العميل ← الخادم :«أخبرني بالأدوات المتاحة» الخادم ← العميل :«ثلاث: search_docs / read_file / query_db، والوصف كالتالي» يحكم الـLLM :«لأستدعِ query_db بالوسيط {sql:"..."}» العميل ← الخادم :«نفّذ query_db» الخادم ← العميل :«النتيجة هي بيانات هذه الصفوف»
طرق النشر أساساً طريقتان: النمط المحلّي الذي تشغّله عمليةً على جهازك، والنمط البعيد الذي تتّصل به عبر الشبكة. المحلّي مناسب لملفاتك وقاعدة بيانات التطوير، والبعيد لربط خدمات SaaS المشتركة في الفريق. وكلاهما يتّبع الاتفاق نفسه «تستقبل قائمة الأدوات وتستدعي»، ولا تكاد طريقة التعامل من جهة العميل تختلف.
📖 ابدأ من الصورة الكاملة. إن قرأت أوّلاً مقال شرح «ما هو MCP» الذي ينظّم نشأته ومصطلحاته وحالة دعمه ببساطة، دخل حديث هذا الفصل بيسر. وتفاصيل المواصفة ونسخها تتطوّر بسرعة، فتحقّق دائماً من الأحدث في الوثائق الرسمية قبل التنفيذ.
استخدام خوادم MCP وبناؤها
أطيب ما في MCP أنّك تستطيع استخدام خوادم منشورة في العالم كما هي. الأدوات الشائعة، غالباً هيّأها أحدهم كخادم MCP. حين تصلها بوكيلك المصنوع، تزيد قدرته دفعةً واحدة بلا إعادة اختراع للعجلة.
قراءة مجلّد محدّد والكتابة فيه. أساسٌ لإقرائه المستندات أو لإخراجه النتاج.
تنفيذ SQL ومراجعة المخطّط. أمام «اجمع لي» يستطيع الاستعلام من البيانات الحقيقية والإجابة.
بحث الويب أو بحث المعرفة الداخلية. يصير «يد البحث» التي تجلب أحدث المعلومات والأدلّة.
إدارة المهام والدردشة والتخزين. تجعل أدوات عملك القائمة يدَي الوكيل وقدميه.
خطوات الربط ذاتها بسيطة. تُشغّل الخادم الذي تريده (أو تحدّد رابطه)، وتسجّل موضع الخادم وبيانات اعتماده في إعدادات العميل فحسب. بعدها يستقبل الوكيل قائمة الأدوات عند الاتّصال، ويستدعي حسب الحاجة. لست بحاجة إلى كتابة «متن أداة بحث قاعدة البيانات». يصير عملك أن تركّب الأدوات المقدَّمة بما يوافق هدفك.
⚠️ «مفيدة فلنصلها كلّها» ممنوع. كلّما أضفت خادماً، زادت بعدد أدواته الأوصافُ المُمرّرة للـLLM، فيتشتّت حكمه، ويتّسع مجال الخطأ التشغيلي. الأساس أن تختار وتصل الأدوات التي يحتاجها هدف ذلك الوكيل فعلاً فقط. الأدوات الكثيرة جداً تخفض الدقّة بالعكس.
تستطيع بناء خادمك أيضاً
الأدوات التي لا خادم جاهز لها — واجهة API داخلية خاصّة، منطق عمل خاصّ… — ما عليك إلا أن تكتب خادم MCP بنفسك. وهنا حُسن MCP: ما إن تنشره خادماً، حتى تستطيع أيّ وكيل متوافق استخدامه بالطريقة نفسها. فالأداة المصنوعة لمشروع بعينه، يعاد استخدامها بلا إعادة كتابة في المشروع التالي، وفي وكيل آخر للفريق.
متن بناء الخادم هو «أن تعرّف الوظيفة التي تريد تقديمها كأداة، وتصرّح باسمها ووسائطها ووصفها، وحين تُستدعى تنفّذ المعالجة وتعيد النتيجة». الفكرة كتعريف الأداة الخام في الفصل السابق، لكن الفرق الحاسم أنّ وجهة الإخراج ليست «وكيلاً بعينه» بل «منفذ MCP الموحّد». جهد الصنع مرّة واحدة، والاستعمال مراراً بلا حدّ.
🛠 إن أردت الخوض في التنفيذ. للشيفرة الملموسة لتركيب الوكلاء وربط الأدوات في Claude، فإنّ مدخل Claude Agent SDK عمليّ. يمتلك الـSDK آليةً للتعامل مع خوادم MCP، فربط الجاهز منها وبناء الخاصّ كلاهما يمضي وفق خطوات الوثائق الرسمية.
أيّ الأدوات تعطي وكيف
حين تصبح قادراً على «وصل» الأدوات، فالسؤال التالي هو «ماذا تعطي وكيف». هنا مفتاح تصميم يحسم جودة الوكيل وأمانه، وهو أساس الفصول اللاحقة أيضاً. لنمسك بثلاثة مبادئ.
أعطِ الأدوات والنطاق اللازم لتلك المهمّة فقط. «إن كفت القراءة فلا تعطِ إذن الكتابة». في قاعدة البيانات حساب محدود للقراءة، وفي الملفات المجلّد المعنيّ فقط — هذا الأساس.
يحكم الـLLM باستخدام الأداة من عدمه معتمداً على وصفها وحده. اكتب بوضوح «ماذا تفعل الأداة، ومتى تُستخدم، ومعنى الوسائط، وفي أيّ موضع لا يجوز استخدامها». الوصف الغامض يولّد سوء الاستخدام.
العمليات التي لا رجعة فيها كالكتابة والحذف والتحصيل المالي وتنفيذ الأوامر، لا تضعها في صفّ واحد مع أدوات القراءة. أضِف إليها دائماً تأكيداً قبل التنفيذ، وتقييد الهدف، والتسجيل.
و③ مهمّ خاصّة. أدوات «البحث» (البحث والمراجعة والقراءة) لا تُحدث ضرراً كبيراً غالباً حتى لو استُدعيت خطأً. أمّا أدوات «التغيير» (الكتابة والحذف والإرسال والتنفيذ) فخطأ تشغيليّ واحد فيها يولّد نتيجةً لا رجعة فيها. القاعدة الذهبية أن تفصل بوعي بين أدوات القراءة وأدوات الكتابة، وتكدّس الحواجز على الأخيرة.
| النوع | أمثلة | الخطر | دليل الإعطاء |
|---|---|---|---|
| أدوات القراءة | بحث ومراجعة وقراءة ملفات | منخفض (انتبه لتداول المعلومات) | بحرّية نسبية. مع تضييق النطاق |
| أدوات الكتابة | تحديث ملف وكتابة في قاعدة بيانات وإرسال | مرتفع (يصعب التراجع) | اجعل التأكيد والتقييد والتسجيل إلزامياً |
| أدوات التنفيذ | تنفيذ أوامر واستدعاء خارجي وتحصيل مالي | أقصى (مدخل الانفلات وسوء الاستخدام) | حاجز مبدئياً + إدراج موافقة بشرية |
🔒 هذا نتناوله بعمق في الفصل السادس. التحكّم بالأدوات الخطرة، والتصدّي لحقن التعليمات (prompt injection)، وتصميم مسار الموافقة، مواضيع لا مفرّ منها عند طرح الوكيل في الإنتاج. نتناولها مجمّعةً في الفصل السادس «الحواجز الواقية والأمان»، فلا تحمل من هذا الفصل إلا الإحساس بأنّ «للأدوات درجات خطورة متفاوتة». وألّا تصل خادم MCP غير موثوق باستخفاف عادةٌ مهمّة أيضاً.
أدوات متقدّمة كالتحكّم بالمتصفّح
من بين الأدوات، ما ينال اهتماماً خاصّاً في السنوات الأخيرة هو التحكّم بالمتصفّح. أن يرى الشاشة، ويتتبّع الروابط، ويملأ النماذج، ويضغط الأزرار — لو أوكلت للوكيل ما يفعله الإنسان في المتصفّح، تحوّلت خدمات ويب كثيرة لا واجهة API خاصّة لها إلى «يدين وقدمين». وقد ظهرت تنفيذات تقدّم التحكّم بالمتصفّح كخادم MCP، فانخفضت عتبة الربط.
غير أنّ هذه من أقوى الأدوات وأعلاها خطراً. خطورة تلقّي تعليمات الشاشة كما هي (التضليل والمعلومات المزيّفة)، والنقر أو الإرسال غير المقصود، وكشف بيانات الاعتماد — تنطبق عليها تماماً تحذيرات «أدوات التنفيذ» في الفقرة السابقة. الحكمة أن تبدأ من الاستخدامات الأقرب إلى القراءة كالتصفّح واجتلاب المعلومات، وأن تضع حواجز بحذر على العمليات المصحوبة بكتابة.
🌐 إلى أيّ حدّ يمكن أن توكل؟ نتحقّق ملموساً من القدرة الواقعية لوكيل التحكّم بالمتصفّح وحدوده في إلى أيّ حدّ يستطيع الذكاء الاصطناعي أتمتة مهام المتصفّح. إن أمسكت بمسافة «ليس حلّاً لكلّ شيء، لكنّه عمليّ إن ضيّقت الاستخدام»، لم يتذبذب حكمك في اختيار الأدوات.
وليس المتصفّح وحده، فكلّما تقدّمت الأداة تناسب معها «ما يمكن فعله» و«ما قد يقع». كلّما أعطيت أداةً قويّة، فكن أدقّ في مبادئ الأذونات والوصف والحواجز الثلاثة — هذه هي الرسالة التي كرّرناها عبر هذا الفصل.
- قدرة الوكيل تحسمها جودة الأدوات الموصولة وعددها. وكثيراً ما يكون تصميم الأدوات أنجع من العقل.
- صناعة الأدوات الخام يصعب إعادة استخدامها، وتصير جحيم تركيبات N×M. فيصبح المنفذ الموحّد مطلوباً.
- MCP معيار مفتوح يربط الذكاء الاصطناعي بالأدوات الخارجية معيارياً. «USB الذكاء الاصطناعي» حيث يتحادث العميل (المستخدِم) والخادم (المقدِّم) بالاتفاق نفسه.
- خوادم MCP الجاهزة (ملفات/قاعدة بيانات/بحث/SaaS) صِلها فاستخدمها، والأدوات الخاصّة اجعلها خادماً مصنوعاً يُعاد استخدامه.
- مبادئ الإعطاء: ① تقليل الأذونات ② جودة الوصف ③ الأدوات الخطرة على حدة. كلّما قويت الأداة كالتحكّم بالمتصفّح فكن أحذر.
حين تعرف كيف تجهّز الأدوات، فالمرحلة التالية «أن تكثّر الوكلاء». نمضي إلى تصميم يوزّع العمل الذي لا يقوى عليه وكيل واحد وينسّقه بين عدّة وكلاء. في الفصل الرابع «تصميم الوكلاء المتعدّدين» لنتعلّم تقسيم الأدوار وتعاون الوكلاء فيما بينهم (A2A).