आपके MCP सर्वर को 40 टूल्स की ज़रूरत नहीं है

MCP डेमो अक्सर सब कुछ एक साथ दिखाते हैं। वे हर एंडपॉइंट और हर डेटाबेस टेबल दिखाते हैं। वे दावा करते हैं कि एजेंट कुछ भी कॉल कर सकता है।

यह दस मिनट के लिए शक्तिशाली महसूस होता है। फिर मॉडल विफल हो जाता है। यह गलत टूल कॉल करता है। यह गलत आकार (shape) में आर्गुमेंट्स पास करता है। यह एक सर्च एंडपॉइंट से चार्ट मांगता है। यह किसी विनाशकारी (destructive) एक्शन को दोबारा दोहराता है।

समस्या MCP नहीं है। समस्या MCP को आपके बैकएंड के लिए एक जादुई एडॉप्टर की तरह मानना है।

एक MCP सर्वर केवल आपका API नहीं है जिसे एजेंटों के लिए सुलभ बनाया गया है। यह एक बहुत ही शाब्दिक (literal) और बहुत जल्दी विचलित होने वाले उपयोगकर्ता के लिए एक प्रोडक्ट सरफेस है। वह उपयोगकर्ता एक लैंग्वेज मॉडल है।

यदि आप किसी मॉडल को 40 समान टूल्स देते हैं, तो आप उसे शक्ति नहीं दे रहे हैं। आप उसे लगभग सही होने के 40 तरीके दे रहे हैं।

अपने API रूट्स को मिरर करना बंद करें। इंसान डॉक्यूमेंटेशन पढ़ सकते हैं और संदर्भ (context) समझ सकते हैं। मॉडल नामों और विवरणों (descriptions) में पैटर्न मैच करते हैं।

अपने MCP लेयर को यूजर इंटेंट (user intent) के इर्द-गिर्द बनाएं।

हर रूट को मिरर करने के बजाय, उन्हें स्पष्ट सीमाओं में समूहित (group) करें:

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

एक API रूट कहता है: यदि आप यह अनुरोध भेजते हैं, तो सर्वर जवाब देगा। एक MCP टूल को कहना चाहिए: इस सटीक काम के लिए, इन सटीक इनपुट्स के साथ मेरा उपयोग करें, और इस विशिष्ट परिणाम की अपेक्षा करें।

अच्छे टूल विवरण रूटिंग लॉजिक होते हैं, मार्केटिंग कॉपी नहीं।

गलत: 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. उबाऊ (boring) नामों का उपयोग करें। डेवलपर्स को fetch या query जैसे संक्षिप्त नाम पसंद होते हैं। मॉडल्स को search_docs या check_deployment_status जैसे विशिष्ट नामों की आवश्यकता होती है। अस्पष्ट नाम महंगे पड़ते हैं।

  2. रिस्पॉन्स के आकार (shape) को नियंत्रित करें। विशाल नेस्टेड ऑब्जेक्ट्स वापस न करें। वह सबसे छोटा आकार लौटाएं जो काम को पूरा करने में सक्षम हो। यदि मॉडल बहुत अधिक डेटा देखता है, तो वह गलत फ़ील्ड का उपयोग करेगा या विवरणों के बारे में मतिभ्रम (hallucinate) करेगा।

  3. विफलता (failure) के लिए डिज़ाइन करें। प्रोडक्शन क्वालिटी इस बात से आती है कि आप त्रुटियों (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