हम MCP सर्वर गलत तरीके से बना रहे हैं
REST का हैंगओवर
जब अधिकांश डेवलपर अपना पहला MCP सर्वर बनाते हैं, तो वे कुछ अनुमानित करते हैं: अपनी REST API लेते हैं और प्रत्येक एंडपॉइंट को MCP टूल के रूप में रैप करते हैं। GET /users get_users टूल बन जाता है। मैपिंग 1:1 है, यांत्रिक है, और गलत है।
यह गलत है क्योंकि REST API उन डेवलपर्स के लिए डिज़ाइन किए गए हैं जो डॉक्यूमेंटेशन पढ़ते हैं और कई कॉल्स को दिमाग में चेन कर सकते हैं। LLM ऐसे काम नहीं करते। वे टूल विवरणों के साथ काम करते हैं, डॉक्स के साथ नहीं।
जब आप REST को अंधा होकर MCP में मैप करते हैं, तो आप LLM को वो मानसिक मॉडल पुनर्निर्मित करने के लिए मजबूर करते हैं जो आपके API डॉक्स ने एक मानव डेवलपर को दिया होता।
एंडपॉइंट्स में नहीं, कार्यों में सोचें
मौलिक बदलाव यह है: REST एंडपॉइंट्स संसाधनों को मॉडल करते हैं। MCP टूल्स को कार्यों को मॉडल करना चाहिए।
एक REST API में GET /users/{id}, GET /users/{id}/orders, GET /orders/{id}/items है। तीन एंडपॉइंट्स, तीन कॉल्स, तीन रिस्पॉन्स।
एक MCP सर्वर में get_user_order_summary टूल होना चाहिए जो एक कॉल में सब कुछ लौटाए। LLM ने पूछा "इस यूज़र ने क्या ऑर्डर किया?" — जवाब दो, तीन पहेली के टुकड़े नहीं।
API शुद्धतावादियों को यह गलत लगता है। लेकिन उपभोक्ता डेवलपर नहीं है — यह LLM है जो कम, अधिक पूर्ण टूल कॉल्स के साथ बेहतर प्रदर्शन करता है।
विवरण ही आपका डॉक्यूमेंटेशन है
REST API में, एंडपॉइंट पथ और HTTP मेथड सिमेंटिक जानकारी रखते हैं। GET /users स्पष्ट है।
LLM URL पैटर्न पार्स नहीं करते। वे टूल विवरण पढ़ते हैं। आपका टूल विवरण एकमात्र डॉक्यूमेंटेशन है जो मायने रखता है।
विवरण ऐसे लिखें जैसे आप टूल को एक बहुत शाब्दिक सहकर्मी को समझा रहे हों जिसके पास आपके सिस्टम के बारे में कोई संदर्भ नहीं है। बिल्कुल बताएं कि क्या करता है, क्या लौटाता है, कब उपयोग करें और कब नहीं।
अधिकांश MCP सर्वर के विवरण तकनीकी लेखन कक्षा में D ग्रेड पाएंगे।
ओवरलैप समस्या
मैं लगातार यह पैटर्न देखता हूं: search_documents, find_documents, और query_documents वाला MCP सर्वर। तीन टूल जो लगभग एक ही काम करते हैं।
मानव डेवलपर के लिए, अंतर स्पष्ट हैं। LLM के लिए, ये तीन समान विवरण वाले टूल हैं। लगभग 40% बार गलत अनुमान लगाता है।
टूल ओवरलैप MCP विश्वसनीयता समस्याओं का नंबर एक स्रोत है। समाधान निर्दयी डिडुप्लिकेशन है। अगर दो टूल मर्ज हो सकते हैं, तो मर्ज करें। टूल जोड़ने के बजाय पैरामीटर जोड़ें।
कम लेकिन अधिक सक्षम टूल हमेशा कई विशेष टूल्स को हराते हैं।
LLM के लिए डिज़ाइन करें, डेवलपर के लिए नहीं
मेटा-सबक सरल है: MCP टूल्स का उपभोक्ता REST API से अलग है।
असली LLM के साथ अपने टूल्स का परीक्षण करें। सिर्फ "क्या टूल सही निष्पादित होता है?" नहीं — बल्कि "क्या LLM सही टूल चुनता है और सही पैरामीटर पास करता है?"
प्रोडक्शन में LLM वास्तव में आपके टूल्स कैसे उपयोग करते हैं इसकी निगरानी करें। आपको आश्चर्यजनक पैटर्न मिलेंगे।
सबसे अच्छे MCP सर्वर वे नहीं हैं जिनमें सबसे ज़्यादा टूल हैं। वे हैं जहां LLM हर बार पहली कोशिश में सही जवाब पाता है। यही एकमात्र मीट्रिक है जो मायने रखती है।
संबंधित पोस्ट
SmeltSec आज़माने के लिए तैयार हैं?
60 सेकंड में सुरक्षित MCP सर्वर जेनरेट करें। मुफ्त में शुरू करें।