तुमच्या MCP सर्व्हरला ४० टूल्सची गरज नाही

MCP डेमोमध्ये अनेकदा सर्व काही एकाच वेळी दाखवले जाते. ते प्रत्येक एंडपॉइंट (endpoint) आणि प्रत्येक डेटाबेस टेबल दाखवतात. एजंट काहीही कॉल करू शकतो असा दावा ते करतात.

हे दहा मिनिटांसाठी शक्तिशाली वाटते. पण त्यानंतर मॉडेल अपयशी ठरते. ते चुकीचे टूल कॉल करते. ते चुकीच्या स्वरूपात (shape) आर्ग्युमेंट्स पास करते. ते सर्च एंडपॉइंटकडून चार्टची मागणी करते. ते एखादी विनाशकारी (destructive) कृती पुन्हा करण्याचा प्रयत्न करते.

समस्या MCP मध्ये नाहीये. समस्या अशी आहे की तुम्ही MCP ला तुमच्या बॅकएंडसाठी एक 'मॅजिक अडॅप्टर' म्हणून वागवत आहात.

MCP सर्व्हर म्हणजे केवळ एजंट्ससाठी उपलब्ध करून दिलेली तुमची API नाही. ते एका अत्यंत शब्दशः (literal) आणि अत्यंत विचलित होणाऱ्या युजरसाठीचे प्रॉडक्ट सरफेस आहे. तो युजर म्हणजे एक लँग्वेज मॉडेल आहे.

जर तुम्ही मॉडेलला ४० सारखीच टूल्स दिली, तर तुम्ही त्याला शक्ती देत नाही आहात. तुम्ही त्याला 'जवळपास बरोबर' असण्याचे ४० मार्ग देत आहात.

तुमच्या API रूट्सची (routes) हुबेहूब नक्कल करणे थांबवा. माणसे डॉक्युमेंटेशन वाचू शकतात आणि संदर्भ (context) समजू शकतात. मॉडेल्स नावांमध्ये आणि वर्णनांमध्ये पॅटर्न मॅच करतात.

तुमचे MCP लेअर युजरच्या हेतूभोवती (user intent) तयार करा.

प्रत्येक रूटची नक्कल करण्याऐवजी, त्यांना स्पष्ट सीमांमध्ये (boundaries) गटबद्ध करा:

  • मार्केट सारांशासाठी एक टूल
  • रिलीज कॅलेंडरसाठी एक टूल
  • विशिष्ट डेटा स्नॅपशॉट्ससाठी एक टूल
  • ऐतिहासिक निर्देशकांसाठी (historical indicators) एक टूल

एक API रूट म्हणते: जर तुम्ही ही विनंती (request) पाठवली, तर सर्व्हर प्रतिसाद देईल. एक MCP टूल म्हणायला हवे: या नेमक्या कामासाठी, या नेमक्या इनपुट्ससह माझा वापर करा आणि या विशिष्ट निकालाची अपेक्षा करा.

चांगले टूल वर्णन हे राउटिंग लॉजिक असते, मार्केटिंग कॉपी नाही.

वाईट: name: get_data description: API मधून डेटा मिळवते.

उत्तम: name: lookup_release_calendar description: एका विशिष्ट चलनासाठी (currency) आणि दिनांक मर्यादेसाठी (date range) नियोजित आर्थिक घटना परत करा. आगामी मॅक्रो इव्हेंट्सबद्दलच्या प्रश्नांची उत्तरे देण्यापूर्वी याचा वापर करा.

चांगल्या एजंट्ससाठी या नियमांचे पालन करा:

१. साधी/साधारण नावे वापरा. डेव्हलपर्सना fetch किंवा query सारखी संक्षिप्त नावे आवडतात. मॉडेल्सना search_docs किंवा check_deployment_status सारखी विशिष्ट नावे लागतात. संदिग्ध (ambiguous) नावे महाग पडतात.

२. प्रतिसादाचे स्वरूप (response shape) नियंत्रित करा. प्रचंड मोठी नेस्टेड ऑब्जेक्ट्स (nested objects) परत करू नका. कामासाठी आवश्यक असलेले सर्वात लहान स्वरूप परत करा. जर मॉडेलला खूप जास्त डेटा दिसला, तर ते चुकीचे फील्ड वापरते किंवा तपशीलांची चुकीची माहिती (hallucinate) देते.

३. अपयशासाठी डिझाइन करा. प्रॉडक्शनची गुणवत्ता तुम्ही त्रुटी (errors) कशा हाताळता यावर अवलंबून असते. फक्त 500 एरर किंवा रिकामी ॲरे (empty array) परत करू नका. ते का अपयशी ठरले ते मॉडेलला सांगा. जर कोणताही रेकॉर्ड मॅच झाला नाही, तर मॉडेलला युजरला अधिक व्यापक दिनांक मर्यादा (wider date range) सुचवायला सांगा.

सर्वोत्तम एजंट टूल ते नाही जे सर्वात शक्तिशाली आहे. ते आहे ज्याचा मॉडेल चुकीचा अर्थ लावू शकत नाही.

Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Optional learning community: https://t.me/GyaanSetuAi