𝗬𝗼𝘂𝗿 𝗠𝗖𝗣 𝗦𝗲𝗿𝘃𝗲𝗿 𝗗𝗼𝗲𝘀𝗻'𝘁 𝗡𝗲𝗲𝗱 𝟰𝟬 𝗧𝗼𝗼𝗹𝘀

MCP کے ڈیموز اکثر سب کچھ ایک ساتھ دکھاتے ہیں۔ وہ ہر اینڈ پوائنٹ (endpoint) اور ڈیٹا بیس کا ہر ٹیبل دکھاتے ہیں۔ وہ دعویٰ کرتے ہیں کہ ایجنٹ کچھ بھی کال کر سکتا ہے۔

یہ دس منٹ کے لیے تو طاقتور محسوس ہوتا ہے۔ پھر ماڈل ناکام ہو جاتا ہے۔ وہ غلط ٹول کال کرتا ہے۔ وہ غلط فارمیٹ میں آرگومنٹ (arguments) پاس کرتا ہے۔ وہ سرچ اینڈ پوائنٹ سے چارٹ مانگتا ہے۔ وہ کسی تباہ کن عمل (destructive action) کو دوبارہ کرنے کی کوشش کرتا ہے۔

مسئلہ MCP نہیں ہے۔ مسئلہ MCP کو اپنے بیک اینڈ (backend) کے لیے ایک جادوئی اڈاپٹر کے طور پر سمجھنا ہے۔

ایک MCP سرور صرف آپ کی API نہیں ہے جسے ایجنٹس کے لیے قابل رسائی بنایا گیا ہو۔ یہ ایک بہت ہی لفظی اور بہت جلد توجہ بھٹک جانے والے صارف کے لیے پروڈکٹ کی سطح (product surface) ہے۔ وہ صارف ایک لینگویج ماڈل ہے۔

اگر آپ ایک ماڈل کو 40 ملتے جلتے ٹولز دیتے ہیں، تو آپ اسے طاقت نہیں دے رہے ہوتے۔ بلکہ آپ اسے تقریباً صحیح ہونے کے 40 طریقے دے رہے ہوتے ہیں۔

اپنی API روٹس (routes) کی نقل کرنا بند کریں۔ انسان دستاویزات پڑھ سکتے ہیں اور سیاق و سباق (context) سمجھ سکتے ہیں۔ ماڈلز ناموں اور تفصیلات میں پیٹرن میچ (pattern-match) کرتے ہیں۔

اپنی MCP لیئر کو صارف کے ارادے (user intent) کے گرد بنائیں۔

ہر روٹ کی نقل کرنے کے بجائے، انہیں واضح حدود میں تقسیم کریں:

  • مارکیٹ کے خلاصوں کے لیے ایک ٹول
  • ریلیز کیلنڈرز کے لیے ایک ٹول
  • مخصوص ڈیٹا اسنیپ شاٹس کے لیے ایک ٹول
  • تاریخی اشاریوں (historical indicators) کے لیے ایک ٹول

ایک API روٹ کہتا ہے: اگر آپ یہ درخواست بھیجیں گے، تو سرور جواب دے گا۔ ایک MCP ٹول کو کہنا چاہیے: مجھے اس بالکل اسی کام کے لیے، ان بالکل اسی ان پٹس کے ساتھ استعمال کریں، اور اس مخصوص نتیجے کی توقع رکھیں۔

اچھے ٹول کی تفصیلات روٹنگ لاجک (routing logic) ہوتی ہیں، مارکیٹنگ کاپی نہیں۔

برا: name: get_data description: Gets data from the API.

بہتر: name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.

بہتر ایجنٹس کے لیے ان اصولوں پر عمل کریں:

  1. سادہ نام استعمال کریں۔ ڈویلپرز fetch یا query جیسے مختصر نام پسند کرتے ہیں۔ ماڈلز کو search_docs یا check_deployment_status جیسے مخصوص ناموں کی ضرورت ہوتی ہے۔ مبہم نام مہنگے پڑتے ہیں۔

  2. رسپانس کی شکل (response shape) کو کنٹرول کریں۔ بڑے اور پیچیدہ (nested) آبجیکٹس واپس نہ کریں۔ وہ سب سے چھوٹی شکل واپس کریں جو کام کے لیے ضروری ہو۔ اگر ماڈل بہت زیادہ ڈیٹا دیکھتا ہے، تو وہ غلط فیلڈ استعمال کرے گا یا تفصیلات کے بارے میں غلط معلومات (hallucinate) دے گا۔

  3. ناکامی کے لیے ڈیزائن کریں۔ پروڈکشن کوالٹی اس بات سے آتی ہے کہ آپ غلطیوں (errors) کو کیسے سنبھالتے ہیں۔ صرف 500 ایرر یا خالی ایرے (empty array) واپس نہ کریں۔ ماڈل کو بتائیں کہ وہ کیوں ناکام ہوا۔ اگر کوئی ریکارڈ میچ نہ ہو، تو ماڈل کو بتائیں کہ وہ صارف کو تاریخ کی ایک وسیع تر حد تجویز کرے۔

بہترین ایجنٹ ٹول وہ نہیں ہے جو سب سے زیادہ طاقتور ہو، بلکہ وہ ہے جسے ماڈل غلط نہ سمجھ سکے۔

ماخذ: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi