टूल सूची को एजेंट के लिए पठनीय क्या बनाता है
हमने हज़ारों MCP टूल सतहों को इस आधार पर अंक दिए कि कोई LLM कितनी आसानी से सही टूल चुन पाता है। वही चार गलतियाँ बार-बार लौटती हैं।
एजेंट आपका दस्तावेज़ कभी नहीं देखता। वह देखता है टूल नामों की सूची, एक पंक्ति के विवरण, और पैरामीटरों का JSON स्कीमा। पूरी ब्रीफिंग बस यही है। यदि सही टूल इससे स्पष्ट नहीं होता, तो एजेंट गलत चुन लेता है — या उपयोगकर्ता से ऐसा प्रश्न पूछता है जो पूछने की ज़रूरत ही नहीं थी।
हम कैटलॉग की हर पठनीय टूल सतह का मूल्यांकन कर उसे अंक देते हैं। हज़ारों पढ़ने के बाद विफलताएँ समूह बनाने लगती हैं।
1. आपस में उलझे टूल
दो टूल जो एक ही अनुरोध का उत्तर दे सकते हों, सबसे महँगी गलती हैं, क्योंकि एजेंट के पास कोई निर्णायक आधार नहीं होता। यदि आपके पास search_docs और find_document दोनों हैं, तो किसी एक को स्पष्ट कहना होगा कि वह क्या करता है जो दूसरा नहीं करता।
2. अर्थहीन पैरामीटर
query नाम का, string प्रकार का पैरामीटर एजेंट को कुछ नहीं बताता। इसमें क्या जाएगा — कीवर्ड, प्रश्न, या कोई आईडी? क्या यह केस-संवेदी है? खाली छोड़ने पर क्या होगा? इसकी जगह स्कीमा है, README नहीं।
3. अस्पष्ट टूलों पर उदाहरण न होना
अधिकांश टूलों को उदाहरण की ज़रूरत नहीं। पर जो मुक्त-रूप वस्तु, फ़िल्टर अभिव्यक्ति या क्षेत्र-विशेष पहचानकर्ता लेता है, उसे निश्चित रूप से चाहिए। हमारे मूल्यांकनों में "उपयोग उदाहरण नहीं है" सबसे बार-बार दिखने वाली कमज़ोरियों में है — और लगभग हमेशा किसी एक टूल के बारे में, पूरे सर्वर के बारे में नहीं।
4. चुप सीमाएँ
दर सीमाएँ, अधिकतम परिणाम संख्या, निष्पादन टाइमआउट, और क्या कॉल पर पैसा लगता है। जो एजेंट सीमा नहीं जानता, वह उससे टकराएगा। सबसे ऊँचे अंक उन्हीं सर्वरों को मिलते हैं जो ये बातें विवरण में साफ़ लिख देते हैं।
छोटा रूप
- अलग नाम जो अलग काम का संकेत दें।
- हर पैरामीटर इस आधार पर वर्णित हो कि उसमें क्या डालना है।
- जिन टूलों के बारे में इंसान पूछेगा, उन पर उदाहरण हों।
- सीमाएँ वहाँ लिखी हों जहाँ एजेंट वास्तव में पढ़ेगा।
इनमें से किसी के लिए और टूल नहीं चाहिए। अधिकांश के लिए कम टूल चाहिए, बेहतर वर्णन के साथ।
देखें कि कोई सर्वर कितने अंक पाता है