MCP सर्वर चुपचाप फेल होते हैं। आपका डैशबोर्ड नहीं बताएगा।
मूक विफलता की समस्या
आपका MCP सर्वर हर अनुरोध पर 200 OK लौटाता है। आपका डैशबोर्ड हरा है। आपके उपयोगकर्ता निराश हैं।
HTTP स्टेटस कोड यहाँ जो मायने रखता है उसे नहीं मापते। टूल ने डेटा लौटाया। क्या यह सही टूल था? क्या जवाब उपयोगी था? क्या मॉडल ने वाकई इसे इस्तेमाल किया?
एजेंट टूल उपयोग पर Anthropic के एक सार्वजनिक मूल्यांकन (MCP Bench, 2025 के अंत में) ने छह से अधिक टूल वाले लोकप्रिय MCP सर्वरों पर टूल चयन त्रुटि दर 28% से 46% के बीच मापी। यही पैटर्न प्रोडक्शन में भी दिखता है: परफेक्ट अपटाइम, 200ms से कम लेटेंसी, शून्य 5xx एरर वाले सर्वर — जबकि मॉडल लगभग आधे समय गलत टूल बुला रहा होता है।
सर्वर को नहीं पता। टीम को नहीं पता। उपयोगकर्ता बस कहते हैं कि AI खराब है।
यही मूक विफलता है। एक MCP सर्वर हर पारंपरिक हेल्थ चेक पास कर सकता है और फिर भी हर कॉल पर गलत सवाल का जवाब दे सकता है।
काम करने का असली मतलब क्या है
REST API के लिए, काम करने का मतलब है वैध अनुरोध स्वीकार करना और सही जवाब लौटाना। इसे सत्यापित करने के लिए दशकों के टूल मौजूद हैं।
MCP सर्वर के लिए, काम करना चार चरणों की एक श्रृंखला है। मॉडल सही टूल चुनता है। सही पैरामीटर भेजता है। उपयोगी जवाब पाता है। जवाब को अपने उत्तर में शामिल करता है। हर चरण स्वतंत्र रूप से विफल होता है। इनमें से कोई भी पारंपरिक मॉनिटरिंग में नहीं दिखता।
गलत टूल? 200. स्कीमा वैलिडेशन पास करने वाले लेकिन उपयोगकर्ता के इरादे से चूकने वाले पैरामीटर? 200. जवाब अनदेखा? 200.
आपके डैशबोर्ड पर 100% सफलता दर और प्रोडक्शन में 40% सफलता दर हो सकती है। उसी खाई में उपयोगकर्ता कहते हैं "AI काम नहीं करता" — और वे सही हैं, भले ही हर SRE मेट्रिक कुछ और कहे।
वे मेट्रिक्स जो मायने रखती हैं
जब आप मान लें कि पारंपरिक मेट्रिक्स अपर्याप्त हैं, सवाल बनता है कि इसके बजाय क्या मापें। पाँच चीज़ें।
**टूल चयन सटीकता।** अगर आपके पास `search_invoices` और `list_documents` है, और उपयोगकर्ता "पिछले महीने के इनवॉइस" माँगता है, तो कौन सा कॉल होता है? इच्छित और वास्तविक चयन के बीच का अंतर ट्रैक करें। MCP ऑब्ज़र्वेबिलिटी में यह सबसे खुलासा करने वाली मेट्रिक है।
**पैरामीटर वैधता।** यह नहीं कि पैरामीटर स्कीमा वैलिडेशन पास कर गए — वह बुनियादी है। क्या तारीख सीमा उपयोगकर्ता की माँग से मेल खाई? क्या खोज क्वेरी ने उनके इरादे को पकड़ा?
**रिस्पॉन्स उपयोग।** क्या मॉडल ने वाकई जवाब का इस्तेमाल किया? अगर आप 50 पंक्तियाँ लौटाते हैं और मॉडल अपने उत्तर में किसी को संदर्भित नहीं करता, तो या तो टूल विवरण गलत है, या फॉर्मेट गलत है, या डेटा अप्रासंगिक है।
**एरर रिकवरी दर।** जब कोई कॉल विफल होती है, तो क्या मॉडल सुधारे हुए पैरामीटर से पुनः प्रयास करता है, टूल बदलता है, या हार मान लेता है? रिकवरी पैटर्न बताता है कि आपके एरर मैसेज उपयोगी हैं या नहीं।
**प्रति सफल इनवोकेशन लागत।** प्रति कॉल लागत नहीं। प्रति उस कॉल की लागत जिसने उपयोगी उत्तर दिया। बर्बाद हुए रिट्राई और गलत-टूल कॉल अक्सर असली लागत को API के कच्चे खर्च के 3-5 गुना तक ले जाते हैं।
ये पाँच MCP सर्वर की सेहत के बारे में सभी पारंपरिक मेट्रिक्स से ज़्यादा बताती हैं।
पारंपरिक APM क्यों चूक जाता है
Datadog, New Relic, और Grafana अपने काम में उत्कृष्ट हैं। वे लेटेंसी वितरण, एरर दर, थ्रूपुट और रिसोर्स उपयोग ट्रैक करते हैं। यह उस API के लिए सही रूप है जिसका कॉलर एक ब्राउज़र या मोबाइल ऐप है जो नियतात्मक अनुरोध भेजता है।
MCP सर्वर का कॉलर नियतात्मक नहीं है। यह एक मॉडल है जो इनफरेंस समय पर निर्णय ले रहा है। विफलता मोड "अनुरोध टाइमआउट" नहीं है। यह है "मॉडल ने तय किया कि यह सही टूल है, और नहीं था।" यह निर्णय-गुणवत्ता की समस्या है, और पारंपरिक APM इसे मापने के लिए नहीं बना है।
ठोस रूप से: अगर आपके एजेंट के पास `get_customer` और `search_customers` दोनों हैं और मॉडल हर बार अनुमानित ID के साथ `get_customer` चुनता है, तो आपका p99 समतल रहता है, आपकी एरर दर समतल रहती है, और हर एक उपयोगकर्ता इंटरैक्शन विफलता में समाप्त होता है। मौजूदा टूलिंग के पास भेजने के लिए कोई सिग्नल नहीं।
आपको मॉडल और टूल्स के बीच एक ऑब्ज़र्वेबिलिटी परत चाहिए — एक जो उपयोगकर्ता इरादे, टूल चयन, पैरामीटर और रिस्पॉन्स उपयोग को सहसंबंधित कर सके। पारंपरिक APM फर्श है। MCP सर्वरों के लिए, यह पूरी तस्वीर का आधा भी नहीं है।
AI टूल्स के लिए ऑब्ज़र्वेबिलिटी स्टैक बनाना
शुरू करने के लिए तीन ठोस चीज़ें। सब कुछ एक बार में सुलझाने की ज़रूरत नहीं।
**1. हर इनवोकेशन को पूरे प्रॉम्प्ट संदर्भ के साथ लॉग करें।** सिर्फ टूल का नाम और पैरामीटर नहीं। वह बातचीत जो कॉल तक ले गई, सिस्टम प्रॉम्प्ट, उपयोगकर्ता का आखिरी संदेश। संदर्भ के बिना, आप मूल्यांकन नहीं कर सकते कि चयन सही था।
**2. इच्छित टूल बनाम चयनित टूल ट्रैक करें।** आपको ग्राउंड ट्रुथ चाहिए — सैंपल पर मैनुअल लेबल, उपयोगकर्ता के अंगूठे ऊपर/नीचे सिग्नल, या ह्यूरिस्टिक नियम (एक उपयोगकर्ता प्रश्न जो "इनवॉइस|बिलिंग|भुगतान" से मेल खाता है और `list_contacts` कॉल में समाप्त हुआ, यह एक दोष है)। मोटे ह्यूरिस्टिक्स भी कुछ न होने से बेहतर हैं।
**3. रिस्पॉन्स उपयोग मापें।** जो टूल ने लौटाया उसकी तुलना मॉडल के अंतिम उत्तर में जो दिखा उससे करें। बड़ा अंतर मतलब खराब रिस्पॉन्स फॉर्मेट, अप्रासंगिक डेटा, या ऐसा टूल विवरण जो मॉडल को परिणाम इस्तेमाल करने में मदद नहीं करता।
ये तीन सिग्नल — इनवोकेशन संदर्भ, चयन सटीकता, रिस्पॉन्स उपयोग — बताते हैं कि आपका MCP सर्वर वाकई उपयोगकर्ताओं की मदद कर रहा है या नहीं। फाइव-नाइन अपटाइम डैशबोर्ड बताते हैं कि प्रक्रिया ज़िंदा है या नहीं। ये अलग सवाल हैं।
संबंधित पोस्ट
SmeltSec आज़माने के लिए तैयार हैं?
60 सेकंड में सुरक्षित MCP सर्वर जेनरेट करें। मुफ्त में शुरू करें।