---
title: "كيف يختار وكلاء الذكاء الاصطناعي الأدوات: ميكانيكا الاكتشاف الوكيل"
description: "كيف يقرر Claude وChatGPT وCursor أي خادم MCP يستدعي. ما الإشارات التي تهم وكيف تكون الأداة التي يختارها الوكيل."
canonical_url: "https://getminds.ai/blog/ar/how-ai-agents-choose-tools-mcp-discovery-mechanics"
last_updated: "2026-06-22T02:08:42.804Z"
---

# كيف يختار وكلاء الذكاء الاصطناعي الأدوات

عندما يطلب مسوّق من Claude "ابحث عن لوحات عملاء اصطناعية لـ B2B SaaS في ألمانيا"، فإن النموذج لا يفتح محرّك بحث. إنه يقرأ أوصاف كل أداة MCP متصلة حالياً بالجلسة، ويرتّبها، ويختار واحدة. هذا الترتيب هو الصفحة الأمامية الجديدة للإنترنت لاكتشاف الأدوات، ولا يكاد يحسّن أحد من أجله.

هذا المنشور يرفع الغطاء ويشرح كيف يعمل الترتيب فعلياً في 2026، وما الإشارات التي تحرّكه، وما هي الآثار العملية لأي فريق يطلق خادم MCP.

## ماذا يعني "الاكتشاف" في سياق وكيل

هناك طبقتان من الاكتشاف يجب الفصل بينهما.

*الطبقة 1، على مستوى السجل.* المستخدم (أو الوكيل نفسه) يجد خادم MCP في دليل ويربطه بالعميل. هذا اكتشاف على طراز المتصفّح: سجلات صديقة للوكلاء، تدفقات OAuth، أزرار "أضف هذا الموصِل". سجل MCP، ودليل Anthropic، ودليل Apps SDK من OpenAI، و`mcpmarket.com`، جميعها تؤدي هذا الدور. بمجرد أن ينقر المستخدم على Connect، يصبح الخادم في قائمة أدوات الوكيل.

*الطبقة 2، الاكتشاف داخل الجلسة.* في كل مرة يُرسل فيها المستخدم رسالة، يجب على الوكيل أن يقرّر أي أداة، إن وجدت، يستدعيها. هذه هي الطبقة التي تحرّك الاستخدام فعلياً. يمكن أن يكون خادم متصلاً ولا يُستدعى لأشهر لأن الوكيل يختار دائماً شيئاً آخر. هنا يحدث الترتيب الحقيقي، ولا يكاد يتحدّث عنه أحد.

بقية هذا المنشور تتحدث عن الطبقة 2.

## ما يراه الوكيل فعلاً

عندما يتصل خادم MCP، يُرسل مصافحة تصف كل أداة يعرضها. لكل أداة يتلقى الوكيل:

- اسماً (مثل `create_panel`)
- وصفاً قصيراً (1 إلى 3 جمل، يكتبه مؤلف الخادم)
- مخطط JSON لمعلمات الإدخال
- بيانات وصفية اختيارية مهيكلة (تعليقات، أمثلة، نوع الإرجاع)

هذا هو السطح كاملاً. لا يرى الوكيل موقعك ولا تسعيرك ولا توثيقك ولا مدوّنتك. أكثر قطعة كتابة ذات رافعة في منتجك بأكمله هي سلسلة الوصف في تسجيل أداتك.

النتيجة المزعجة: أداة لامعة بوصف غامض تخسر أمام أداة متوسطة بوصف حادّ، في كل مرة.

## عملية الترتيب، خطوة بخطوة

عندما يرسل المستخدم رسالة، يفعل الوكيل ما يلي تقريباً:

1. *تصفية إلى أدوات محتملة الصلة.* يقرأ النموذج سياقه الخاص (المحادثة حتى الآن، آخر رسالة من المستخدم) ويحدّد مجموعة مرشحين. مع مجموعة أدوات صغيرة (أقل من 20 أداة)، عادةً يأخذها كلها بعين الاعتبار. مع مجموعة أدوات كبيرة، يصفّي أولاً.
2. *تسجيل النقاط حسب تطابق الوصف.* لكل أداة مرشحة، يقيّم النموذج مدى مطابقة الوصف لنية المستخدم. هذا تطابق ليّن دلالي، وليس تطابق كلمات مفتاحية. المرادفات تعمل. لغة المجال تعمل. الأوصاف الغامضة تفشل.
3. *تكوين استدعاء.* إذا تم اختيار أداة، يملأ النموذج المعلمات من سياق المحادثة. الأدوات التي تتطلب مخططاتها حقولاً غامضة (مثل كائن "options" غير مُعلَّم) تُعاقب لأن النموذج أقل ثقة في قدرته على استدعائها بشكل صحيح.
4. *تسلسل الاستدعاءات اختيارياً.* للمهام متعددة الخطوات، يختار النموذج الأداة الأولى، وينفّذها، ويقرأ النتيجة، ويكرر. الأدوات التي تُرجع مخرجات مهيكلة قابلة للقراءة بواسطة الوكيل تكسب استدعاءات متابعة. الأدوات التي تُرجع مخرجات على شكل جدار من النص تُعطّل السلسلة.

كل هذا يحدث في تمريرة استدلال واحدة. لا يوجد نموذج مرتّب منفصل. لا توجد (بعد) حلقة تغذية راجعة من القياس. القرار يُتخذ على الأوصاف والمخطط، نقطة.

## ما يحرّك الترتيب فعلاً

بالعمل عكسياً من السلوك المُلاحَظ للوكيل، أربعة أشياء تحرّك اختيار الأدوات بشكل مُثبَت:

*خصوصية الوصف.* "Run market research" تخسر أمام "Run a synthetic customer panel against an audience persona and return summarized findings". الوصف الأطول يطابق المزيد من الاستفسارات لأنه يكشف عن المزيد من المقابض ليمسك بها النموذج. هناك ميزانية (تقتطع معظم الوكلاء الأوصاف فوق ~500 حرف) لكن معظم الخوادم بعيدة عنها.

*هيكل فعل-فاعل-مفعول.* يختار الوكلاء أدوات أوصافها تطابق الفعل الذي استخدمه المستخدم. "اسأل عملائي" يطابق `ask_panel` أفضل من `query_panel_responses`. التسمية والوصف يجب أن يقودا بالفعل.

*شكل المخرجات الملموس.* "تُرجع كائن JSON بحقول `panel_id` و`responses` و`summary`" يهزم "تُرجع نتيجة اللوحة". الوكلاء أكثر ميلاً لاستدعاء الأدوات عندما يستطيعون التنبؤ بما يفعلون بالمخرجات.

*قابلية تحليل المخطط.* المخططات بحقول مطلوبة يستطيع النموذج ملؤها من السياق (أوصاف نصية، أعداد رقمية) تُستدعى. المخططات بحقول مطلوبة تحتاج إدخال مستخدم في منتصف الاستدعاء (رموز مصادقة، معرفات داخلية) تُتخطّى لصالح أدوات تستطيع العمل من البداية للنهاية.

## ما لا يحرّك الترتيب (بعد)

قائمة أشياء يُتحدث عنها كأنها مهمة لكنها ليست كذلك في 2026:

- *عدد النجوم في السجل.* قابلية الاكتشاف في الطبقة 1، غير ذي صلة في الطبقة 2.
- *حشو الكلمات المفتاحية بأسلوب SEO.* النموذج يطابق دلالياً؛ لا يطابق بالكلمات المفتاحية. حشر "agentic research AI panels MCP" في الوصف لا يساعد.
- *تمييز العلامة التجارية.* النموذج ليس له تفضيل للعلامات الراسخة على المجهولة في طبقة داخل الجلسة. جودة الوصف تكسب.
- *تأخير تحت 500 مللي ثانية.* النموذج لا يقيس وقت استدعاءات الأدوات عند الترتيب. الأدوات البطيئة لكن المفيدة لا تزال تُستدعى.

سيتغير هذا. درجات Eval، وإشارات الرضا بعد الاستدعاء، وترتيب مكافحة البريد المزعج، كلها على خارطة الطريق للمستضيفين الكبار. اليوم، الوصف هو الرافعة.

## مشكلة مكافحة البريد المزعج

النتيجة الطبيعية لكل هذا هي أن أي شخص يستطيع التلاعب بالترتيب بكتابة وصف طويل جداً وكثيف الكلمات المفتاحية. المستضيفون يعرفون ذلك. بدأ Anthropic وOpenAI ومُشرفو سجل MCP جميعاً في إيقاف حشو الوصف في أواخر 2026.

تظهر آليتان لمكافحة البريد المزعج:

*التحقق من المخطط.* الأدوات التي لا يطابق مخططها المُعلن شكل الاستجابة الفعلي تُخفّض في الترتيب أو تُزال.

*تسجيل Eval عبر المستضيفين.* يقود سجل MCP مجموعة eval عامة تُشغّل promptات مقابل الخوادم المسجّلة وتُبلّغ عن درجات الصحة. الخوادم التي تفشل في الـ eval تتلقى تحذيرات، ثم إزالة.

لا يوجد منهما حياً بالكامل في منتصف 2026، لكن كليهما قادمان. الموقف الذي يجب اتخاذه: اكتب الوصف الذي سيكسب في عالم مُسجَّل بالجودة، وليس فقط في عالم مُطابَق بالكلمات المفتاحية.

## توصيات عملية لمؤلفي الخوادم

إذا كنت تطلق خادم MCP، التغييرات التالية ستحسّن قابلية الاختيار داخل الجلسة بشكل قابل للقياس:

1. *أعد كتابة كل وصف أداة ليقود بالفعل الذي قد يستخدمه المستخدم.* ليس "Panel runner" بل "Run a customer research panel against a target audience and return summarized responses".
2. *حدّد شكل المخرجات في الوصف.* "تُرجع كائن JSON بمصفوفة `responses`، حقل `themes`، وحقل `summary`." هذا يجعل الوكيل واثقاً بما يكفي لتسلسل استدعاءات المتابعة.
3. *اجعل الحقول المطلوبة قابلة للملء من السياق.* إذا احتاج حقل معرفاً داخلياً، اقبل اسماً وحلّه على جانب الخادم. الوكلاء يتخطّون الأدوات التي لا يستطيعون التنبؤ بحقولها المطلوبة.
4. *استخدم 200 إلى 400 حرف لكل وصف أداة.* تحت 100 رفيع جداً. فوق 500 يُقتطع من قبل معظم العملاء.
5. *دقّق عدد أدواتك.* الخوادم بأكثر من 30 أداة تُصفّى قبل أن يرتّبها الوكيل. ادمج الأدوات المرتبطة حيثما أمكن. رأينا خوادم بـ 60 أداة تحصل على اختيار أسوأ من الـ 12 لأن النموذج لا يرى الذيل الطويل أبداً.

الفرق التي تتعامل مع هذه الأوصاف كأهم نسخها يتم استدعاؤها. الفرق التي تتعامل معها كسباكة سجل، لا.

## إلى أين يتجه هذا

ستتصلّب الميكانيكا في الـ 12 شهراً المقبلة. توقع ثلاثة تغييرات:

*الترتيب القائم على Eval يصبح حياً.* درجات الجودة من eval المؤتمتة ستبدأ بالظهور في قوائم السجل وستؤثر على الاختيار داخل الجلسة في مستضيف رئيسي واحد على الأقل.

*حلقات تغذية راجعة من قياس الوكيل.* أول مستضيف رئيسي يطلق "الأدوات التي أنتجت نتائج مُرضية في الجلسات السابقة تُرتّب أعلى" سيتفوّق على الآخرين. هذا هو المعادل الوكيلي لـ click-through-rate، ويغيّر هدف التحسين.

*أنظمة بيئية وكيلة عمودية.* وكلاء التسويق، ووكلاء المبيعات، ووكلاء البحث، سيطوّر كل منهم أكوام أدواته المعيارية. أن تكون الافتراضي في عمودك سيكون أهم من أن تكون في كل دليل.

الأدوات التي تكسب في هذا الانتقال هي تلك التي تتعامل مع أوصاف MCP الخاصة بها كصفحة أمامية لمنتجها. الأدوات التي لا تفعل، لن تُستدعى، بغض النظر عن مدى جودة الخدمة الكامنة.

---

للصورة الأشمل عن سبب كون الوكلاء هم المشترون الجدد، راجع [وكلاء الذكاء الاصطناعي هم المشترون الجدد للتسويق](/blog/ai-agents-new-marketing-buyer-agentic-discovery). للإعداد العملي، راجع [كيف تشغّل لجان عملاء من Claude أو ChatGPT أو Cursor](/blog/run-customer-panels-from-claude-chatgpt-cursor-mcp-guide). لرؤية كيف يبدو خادم MCP موصوف جيداً في الإنتاج، راجع [Minds MCP](/mcp/overview).