REST API से MCP सर्वर तक, सिर्फ 10 मिनट में
जो आपके पास पहले से है
अगर आपके पास REST API है, तो MCP सर्वर का 90% आपके पास पहले से है। यह वो बात है जो कोई नहीं बताता।
आपके एंडपॉइंट्स आपके टूल्स हैं। आपके रिक्वेस्ट स्कीमा आपके इनपुट स्कीमा हैं। आपके रिस्पॉन्स फॉर्मेट आपके आउटपुट टाइप्स हैं। मैपिंग इतनी सीधी है कि शर्म आ जाए।
POST /users/create? वो एक create_user टूल है। GET /orders/:id? वो get_order है। पैरामीटर टाइप्स, वैलिडेशन रूल्स, एरर फॉर्मेट्स — सब कुछ आप पहले से लिख चुके हैं। शायद दो बार, अगर OpenAPI स्पेक को गिनें तो।
बस एक चीज़ की कमी है — ट्रांसलेशन लेयर। और — यही वो हिस्सा है जो आपको अटकाएगा — अच्छी डिस्क्रिप्शन। "description: यूज़र बनाता है" नहीं। ऐसी डिस्क्रिप्शन जिन पर LLM असल में रीज़निंग कर सके। यह फ़र्क आप सोचते हैं उससे ज़्यादा मायने रखता है।
ट्रांसलेशन लेयर
MCP टूल्स REST एंडपॉइंट्स से लगभग 1:1 मैप होते हैं। यह इत्तेफ़ाक नहीं है। दोनों बुनियादी तौर पर एक ही सवाल का जवाब दे रहे हैं: यह सर्विस क्या कर सकती है, और मैं इससे कैसे करवाऊँ?
स्कीमा ट्रांसलेशन मैकेनिकल हैं। JSON Schema अंदर आता है, JSON Schema बाहर निकलता है। ज़रूरी फ़ील्ड्स ज़रूरी रहती हैं। Enums enums रहते हैं। नेस्टेड ऑब्जेक्ट्स नेस्टेड रहते हैं। आँखें सिकोड़कर देखें तो MCP टूल डेफ़िनिशन बेहतर एर्गोनॉमिक्स वाला OpenAPI ऑपरेशन लगता है।
आप कन्वर्ज़न को ऑटोमेट कर सकते हैं। हमने ऑटोमेट किया। स्ट्रक्चरल मैपिंग एक सॉल्व्ड प्रॉब्लम है। इसके बारे में सोचने की ज़रूरत नहीं।
जिसके बारे में सोचना ज़रूरी है वो है वो सब कुछ जो स्ट्रक्चर कैप्चर नहीं करता। इम्प्लिसिट कॉन्ट्रैक्ट्स। ऑर्डर डिपेंडेंसीज़। वो "इस एंडपॉइंट को उस एंडपॉइंट से पहले मत कॉल करो" वाला नॉलेज जो आपकी टीम के दिमाग़ में है और कहीं और नहीं। यही असली ट्रांसलेशन का काम है।
डिस्क्रिप्शन एंडपॉइंट्स से ज़्यादा क्यों मायने रखती हैं
यहाँ ज़्यादातर माइग्रेशन फ़ेल होते हैं। और वजह वो नहीं है जो आप सोचते हैं।
आप एंडपॉइंट नाम कॉपी करते हैं, OpenAPI स्पेक से स्कीमा जेनरेट करते हैं, और डिप्लॉय कर देते हैं। सब कुछ शानदार दिखता है। टूल डेफ़िनिशन साफ़ हैं। टाइप्स सही हैं। प्रोडक्टिव फ़ील करते हैं।
फिर LLM update_user की जगह create_user कॉल कर देता है। क्यों? क्योंकि दोनों की डिस्क्रिप्शन में लिखा है "यूज़र डेटा मैनेज करता है।" आपने ये एक ऐसे डेवलपर के लिए लिखी थीं जो URL पाथ पढ़कर फ़र्क समझ लेता। LLM URL पाथ नहीं पढ़ता। वो डिस्क्रिप्शन पढ़ता है।
आपकी डिस्क्रिप्शन स्पष्ट, विशिष्ट और ऐसे पाठक के लिए लिखी होनी चाहिए जिसने कभी आपका सिस्टम नहीं देखा और कभी देखेगा भी नहीं। "दिए गए ईमेल और पासवर्ड से नया यूज़र अकाउंट बनाता है। जेनरेट किए गए ID के साथ बनाया गया यूज़र ऑब्जेक्ट लौटाता है। अगर ईमेल पहले से रजिस्टर्ड है तो फ़ेल होता है।" यह ऐसी डिस्क्रिप्शन है जिसके साथ LLM काम कर सकता है।
यह माइग्रेशन का असली मुश्किल काम है। प्लंबिंग नहीं — नामकरण।
10 मिनट का रास्ता
तो ये रहा शॉर्टकट। SmeltSec को अपनी OpenAPI स्पेक या GitHub रेपो की तरफ़ पॉइंट करो। बस। यही शुरुआत है।
यह आपके एंडपॉइंट्स पढ़ता है, रूट स्ट्रक्चर और मौजूदा डॉक्यूमेंटेशन से इंटेंट समझता है, सही स्कीमा के साथ MCP टूल्स जेनरेट करता है, और ऐसी डिस्क्रिप्शन लिखता है जो LLMs असल में पार्स कर सकें। फिर टूल पॉइज़निंग वेक्टर्स और बहुत ज़्यादा परमिसिव इनपुट स्कीमा पकड़ने के लिए सिक्योरिटी स्कैनिंग चलाता है।
टाइटल में 10 मिनट बहुत है। ज़्यादातर रेपो 60 सेकंड से कम में हो जाते हैं। बॉटलनेक जेनरेशन नहीं है — आप हैं, जो आउटपुट रिव्यू कर रहे हैं और तय कर रहे हैं कि डिस्क्रिप्शन हर टूल के काम को सही से कैप्चर करती हैं या नहीं।
यह सब हाथ से भी कर सकते हैं। पूरा वीकेंड लग जाएगा। स्कीमा सही बनाएँगे और डिस्क्रिप्शन गलत, क्योंकि अच्छी डिस्क्रिप्शन लिखना एक ऐसा स्किल है जो ज़्यादातर बैकएंड इंजीनियरों को कभी डेवलप करने की ज़रूरत नहीं पड़ी। यह उस तरह का बोरिंग लेकिन ज़रूरी काम है जो टूल्स को हैंडल करना चाहिए।
लॉन्च के बाद क्या बदलता है
MCP में कन्वर्ट करने में सबसे हैरानी की बात कन्वर्ज़न नहीं है। उसके बाद जो होता है वो है।
आपकी API के अचानक ऐसे नए कंज़्यूमर आ जाते हैं जिनकी आपने उम्मीद नहीं की थी। AI एजेंट्स आपके टूल्स को ऐसे तरीकों से कॉल करने लगते हैं जो आपने कभी टेस्ट नहीं किए। वो आपके टूल्स को पूरी तरह अलग सर्विसेज़ के टूल्स के साथ कंपोज़ करते हैं — एक कैलेंडर टूल आपके पेमेंट टूल को कॉल करता है जो नोटिफ़िकेशन टूल को कॉल करता है, सब कुछ एक LLM ऑर्केस्ट्रेट कर रहा है जिसने वर्कफ़्लो खुद ही समझ लिया।
अब आप API नहीं बना रहे। एक इकोसिस्टम में योगदान दे रहे हैं। आपके टूल्स ऐसे सिस्टम्स में बिल्डिंग ब्लॉक्स बन जाते हैं जो आपने डिज़ाइन नहीं किए और जिनकी भविष्यवाणी नहीं कर सकते।
यह असहज है अगर आप पूरी इंटीग्रेशन सरफ़ेस को कंट्रोल करने के आदी हैं। लेकिन रोमांचक है अगर आप समझें कि इसका मतलब क्या है: आपकी सर्विस अभी ऐसे तरीकों से उपयोगी हो गई है जो आप कल्पना नहीं कर सकते थे, ऐसे यूज़र्स के लिए जिनसे आप कभी नहीं मिलेंगे, ऐसी समस्याएँ हल करते हुए जिनके बारे में आप जानते भी नहीं थे।
यही स्विच करने की असली वजह है। इसलिए नहीं कि MCP नया या ट्रेंडी है। इसलिए कि यह आपके काम को एक बहुत बड़ी दुनिया में मायने देता है।
संबंधित पोस्ट
SmeltSec आज़माने के लिए तैयार हैं?
60 सेकंड में सुरक्षित MCP सर्वर जेनरेट करें। मुफ्त में शुरू करें।