आपके MCP सर्वर में एक छिपी स्कोरिंग समस्या है

आपका MCP सर्वर डेमो में बिल्कुल सही काम करता है। आप जानते हैं कि ऐसा होगा क्योंकि डेमो आपने खुद बनाई है। आपने prompt सोच-समझकर चुना, टूल फायर हुआ, रिजल्ट साफ-सुथरा वापस आया। सबने सिर हिलाया। शिप करो।

फिर प्रोडक्शन आता है।

प्रोडक्शन में, LLM 30% बार गलत टूल चुनता है। यूज़र अजीब नतीजे रिपोर्ट करते हैं। एजेंट fetch की जगह search कॉल करता है। जहां epoch timestamp चाहिए वहां date string पास करता है। आपके सबसे शक्तिशाली टूल को पूरी तरह नज़रअंदाज़ कर देता है क्योंकि उसे समझ नहीं आता कि इसे कब इस्तेमाल करना है।

क्या बदला? कोड में कुछ नहीं। Handler ठीक हैं। लॉजिक ठीक है। समस्या हमेशा से थी — आपने बस कभी ध्यान नहीं दिया क्योंकि डेमो स्क्रिप्टेड होती हैं और प्रोडक्शन नहीं। डेमो में आप इनपुट कंट्रोल करते हैं। प्रोडक्शन में, LLM को आपके पंद्रह टूल्स में से यह समझना होता है कि यूज़र की अस्पष्ट request किससे मैच करती है। और वो इस कदम पर आपकी सोच से कहीं ज़्यादा बार फेल हो रहा है।

यही है वो छिपी स्कोरिंग समस्या। आपके सर्वर में बग नहीं है। इसमें एक क्वालिटी गैप है जो तभी दिखता है जब एक लैंग्वेज मॉडल को आपके टूल्स के बारे में असली फैसले लेने होते हैं।

एक बात जो ज़्यादातर MCP डेवलपर्स अंदर तक नहीं समझते: LLM कभी आपका कोड नहीं पढ़ता। वो कभी आपकी handler लॉजिक, validation rules, या सावधानी से बनाया error handling नहीं देखता। वो सिर्फ एक नाम, एक विवरण, और एक schema देखता है।

बस। आपके टूल और उसे इस्तेमाल करने का फैसला करने वाली बुद्धि के बीच का पूरा इंटरफेस यही है।

अगर दो टूल्स के विवरण मिलते-जुलते हैं, तो LLM अंदाज़ा लगाता है। वो स्पष्टीकरण नहीं मांगता। अस्पष्टता नहीं बताता। एक चुनता है और आगे बढ़ जाता है। अगर आपका विवरण कहता है "दस्तावेज़ खोजें" और दूसरा टूल कहता है "दस्तावेज़ ढूंढें", तो LLM अनिवार्य रूप से सिक्का उछाल रहा है।

अगर विवरण अस्पष्ट है, तो LLM इरादे को हैलुसिनेट करता है। वो मान्यताओं से खाली जगह भरता है। "यूज़र सेटिंग्स मैनेज करें" का मतलब सेटिंग्स पढ़ना, लिखना, हटाना, या एक्सपोर्ट करना हो सकता है। LLM एक मतलब मान लेगा और बिना किसी को बताए उस पर अड़ जाएगा।

टूल चयन एक भाषा की समस्या है, कोड की नहीं। इंजीनियर की सहज प्रवृत्ति handler डीबग करने की होती है। असली सुधार लगभग हमेशा टेक्स्ट में होता है — वो बीस शब्द जो बताते हैं कि आपका टूल क्या करता है और कब इस्तेमाल करना है। ज़्यादातर टीमें कभी वहां नहीं देखतीं क्योंकि वो stack traces पढ़ने में व्यस्त होती हैं।

क्वालिटी स्कोर एक अकेला नंबर नहीं है। अगर होता, तो बेकार होता — जैसे किसी रेस्तरां को खाने, सर्विस और माहौल में फ़र्क किए बिना एक ही रेटिंग देना।

असली क्वालिटी स्कोर छह आयामों का है, हर एक स्वतंत्र रूप से मापने योग्य, हर एक अकेले आपके टूल की विश्वसनीयता बर्बाद करने में सक्षम।

विवरण की स्पष्टता: क्या विवरण बताता है कि टूल क्या करता है, कब इस्तेमाल करना है और कब नहीं? क्या यह रिस्पॉन्स फॉर्मेट बताता है? यहां 40 का स्कोर मतलब "LLM इस टूल का नियमित रूप से गलत इस्तेमाल करेगा।" 90 का मतलब "LLM लगभग हमेशा इस टूल को सही चुनता है।"

Schema पूर्णता: क्या पैरामीटर सटीक रूप से टाइप किए गए हैं? क्या required फील्ड्स वाकई required हैं? क्या constrained values के लिए enum इस्तेमाल किए गए हैं?

नामकरण की एकरूपता: क्या आपके टूल्स एक अनुमानित पैटर्न फॉलो करते हैं? अगर आपके पास create_user और delete_user है लेकिन फिर fetch_all_documents है, तो यह असंगति मॉडल पर संज्ञानात्मक बोझ बनाती है।

ओवरलैप का पता लगाना: कितने टूल्स एक ही यूज़र request से मैच कर सकते हैं? ज़्यादा ओवरलैप गलत टूल चयन का सबसे बड़ा भविष्यवक्ता है।

एरर डॉक्यूमेंटेशन: क्या टूल बताता है कि गलत होने पर क्या होता है?

उदाहरण कवरेज: क्या विवरण में उपयोग के उदाहरण हैं? उदाहरण स्पष्टीकरण के पैराग्राफ से ज़्यादा मूल्यवान हैं क्योंकि वे LLM की समझ को ठोस पैटर्न में एंकर करते हैं।

चलिए इसे ठोस बनाते हैं। हर आयाम में 40 और 90 का स्कोर कैसा दिखता है।

विवरण स्पष्टता 40 पर: "डेटाबेस में खोजता है।" 90 पर: "सभी इंडेक्स किए गए दस्तावेज़ों में फुल-टेक्स्ट सर्च। प्रासंगिकता के अनुसार शीर्ष 10 परिणाम लौटाता है। जब यूज़र सामग्री से दस्तावेज़ खोजना चाहता है तब इस्तेमाल करें। सटीक ID से खोज के लिए इस्तेमाल न करें — इसके बजाय get_document इस्तेमाल करें।"

Schema पूर्णता 40 पर: एक अकेला पैरामीटर "query" string टाइप, कोई constraint नहीं। 90 पर: "query" नॉन-एम्प्टी string अधिकतम लंबाई 500, plus ऑप्शनल "limit" integer न्यूनतम 1 अधिकतम 100 डिफ़ॉल्ट 10, plus ऑप्शनल "date_range" ISO 8601 तारीखों के साथ।

नामकरण 40 पर: search, getDoc, user_remove, ListAllItems। 90 पर: search_documents, get_document, remove_user, list_items। पैटर्न verb_noun है, लगातार।

ओवरलैप 40 पर: search_documents, find_documents, और query_documents सब मौजूद हैं और थोड़ा अलग-अलग काम करते हैं। 90 पर: हर टूल का एक स्पष्ट, गैर-अतिव्यापी उद्देश्य है।

फ़र्क हमेशा विशिष्टता में है। अस्पष्ट टूल्स फेल होते हैं। सटीक टूल्स काम करते हैं। और 40 से 90 के बीच का अंतर आमतौर पर दोबारा लिखना नहीं है — एक दोपहर की सावधान एडिटिंग है।

ज़्यादातर टीमें गलत लेयर डीबग करती हैं। वो टूल चयन की विफलताएं देखती हैं और सीधे कोड पर पहुंच जाती हैं। Handler को ज़्यादा सहिष्णु बनाने के लिए दोबारा लिखती हैं। Retry लॉजिक जोड़ती हैं। महंगे मॉडल पर स्विच करती हैं। MCP के ऊपर जटिल routing लेयर बनाती हैं ताकि नीचे की अस्पष्टता की भरपाई हो सके।

यह सब महंगा, धीमा है, और कारण की बजाय लक्षण का इलाज करता है।

असली सुधार आमतौर पर टूल विवरण में 20 शब्दों का बदलाव होता है। "दस्तावेज़ प्रबंधित करता है" को बदलकर "दिए गए शीर्षक और बॉडी से नया दस्तावेज़ बनाता है। दस्तावेज़ ID लौटाता है। केवल नए दस्तावेज़ बनाने के लिए इस्तेमाल करें — मौजूदा दस्तावेज़ अपडेट करने के लिए update_document इस्तेमाल करें।"

इस बदलाव में तीस सेकंड लगे। यह टूल चयन त्रुटियों की पूरी एक श्रेणी को खत्म कर देता है। कोई कोड नहीं बदला। कोई मॉडल अपग्रेड ज़रूरी नहीं।

क्वालिटी स्कोरिंग आपको बिल्कुल बताती है कि कौन से 20 शब्द बदलने हैं। यह उस विशिष्ट आयाम की ओर इशारा करती है जो फेल हो रहा है, उस विशिष्ट टूल पर जो समस्या पैदा कर रहा है, इसकी जगह क्या लिखना है इसके ठोस सुझाव के साथ। यह अस्पष्ट "AI बार-बार कन्फ्यूज़ हो रहा है" को सटीक "आपके search_documents के विवरण में रिस्पॉन्स फॉर्मेट का ज़िक्र नहीं है, और 34% विफलताएं LLM द्वारा परिणामों की गलत व्याख्या से जुड़ी हैं" में बदल देती है।

इसीलिए मापना ज़रूरी है। इसलिए नहीं कि स्कोर अपने आप में कीमती है, बल्कि इसलिए कि यह एक अदृश्य समस्या को दृश्य और ठीक करने योग्य बनाता है। जो टीमें यह समझ जाती हैं वो handler दोबारा लिखना बंद करती हैं और विवरण दोबारा लिखना शुरू करती हैं। दिनों की जगह मिनटों में सुधार भेजती हैं। और उनके टूल्स बस काम करते हैं — इसलिए नहीं कि कोड बेहतर है, बल्कि इसलिए कि भाषा बेहतर है।