MCP सर्वर vs Function Calling: अपना हथियार चुनो

लालच है। सच में है।

अब हर LLM प्रोवाइडर के पास function calling है। OpenAI के पास है। Anthropic के पास है। Google के पास है। अपना पसंदीदा चुनो, बीस मिनट डॉक्स पढ़ो, JSON schema में फंक्शन्स डिफाइन करो और शिप कर दो। चलता है। डेमो अच्छा दिखता है। इन्वेस्टर्स इम्प्रेस हैं।

समस्या यह है कि "चलता है" और "मल्टीपल वेंडर्स पर स्केल पर चलता है" दो बिल्कुल अलग बातें हैं। पहली मंगलवार की दोपहर है। दूसरी फुल-टाइम जॉब है।

जब आप function calling को सीधे एक प्रोवाइडर से जोड़ते हैं, तो सिर्फ वेंडर नहीं चुन रहे। उनका schema फॉर्मेट, पैरामीटर कन्वेंशन्स, एरर हैंडलिंग सीमेंटिक्स और रिलीज़ शेड्यूल सब चुन रहे हैं। आप ऐसा ग्लू कोड लिख रहे हैं जो परिभाषा के अनुसार पोर्टेबल नहीं है। और यह उस लेयर पर कर रहे हैं जहां पोर्टेबिलिटी सबसे ज़्यादा मायने रखती है — आपकी एप्लिकेशन और उस इंटेलिजेंस की सीमा पर जिस पर वो निर्भर है।

ज़्यादातर लोगों को तब पता चलता है जब दूसरे LLM को सपोर्ट करना पड़ता है। तब तक ग्लू कोड मेटास्टेसाइज़ हो चुका होता है।

एक एक्सरसाइज़ करो। अपने कोडबेस में जाओ और गिनो कि कितनी लाइन्स सिर्फ इसलिए हैं कि आपकी इंटरनल टूल डेफिनिशन्स को किसी स्पेसिफिक LLM प्रोवाइडर के function calling फॉर्मेट में ट्रांसलेट करें।

एक इंटीग्रेशन? शायद सौ लाइन्स। संभालने योग्य। दो इंटीग्रेशन? आपको दिखने लगता है कि OpenAI और Anthropic की ऑप्शनल पैरामीटर्स को एक्सप्रेस करने पर सूक्ष्म रूप से अलग राय है। तीन? कम्पैटिबिलिटी मैट्रिक्स मेंटेन कर रहे हो। पांच? गलती से एक फ्रेमवर्क बना दिया।

और फ्रेमवर्क बढ़ना कभी बंद नहीं करते। हर वेंडर हर तिमाही अपनी API बदलता है। कभी फीचर्स जोड़ते हैं। कभी चीज़ें deprecate करते हैं। कभी schema फॉर्मेट को ऐसे "सुधारते" हैं जो शनिवार रात 2 बजे प्रोडक्शन में आपकी मौजूदा डेफिनिशन्स तोड़ देता है।

मल्टी-वेंडर function calling पर मेंटेनेंस टैक्स लीनियर नहीं है। कॉम्बिनेटोरियल है। हर नया वेंडर सरफेस एरिया को मल्टीप्लाई करता है। हर API चेंज हर इंटीग्रेशन में कैस्केड होता है। आपकी "सिंपल" function calling लेयर स्टैक का सबसे नाज़ुक हिस्सा बन जाती है — वो एक फाइल जिसे छूने से सब डरते हैं।

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

MCP कोई प्रोडक्ट नहीं है। किसी स्टार्टअप की API नहीं है। यह एक प्रोटोकॉल है। यह भेद लोगों की सोच से ज़्यादा मायने रखता है।

जब आप MCP सर्वर लिखते हैं, तो अपने टूल्स एक बार डिस्क्राइब करते हैं। एक schema। एक सेट डिस्क्रिप्शन्स। एक एरर फॉर्मेट। बस। हर LLM जो MCP बोलता है, बिना एक लाइन वेंडर-स्पेसिफिक कोड लिखे आपके टूल्स खोज और इस्तेमाल कर सकता है।

कोई एडेप्टर नहीं। कोई वर्ज़न मैट्रिक्स नहीं। कोई "if openai then फॉर्मेट A, elif anthropic then फॉर्मेट B" ब्रांचिंग नहीं। प्रोटोकॉल ही कॉन्ट्रैक्ट है, और प्रोटोकॉल इम्प्लीमेंट करने वाला हर क्लाइंट आपके टूल्स मुफ्त में पाता है।

यह वही पैटर्न है जिसने HTTP को सफल बनाया। कोई Chrome, Firefox और Safari के लिए अलग API नहीं लिखता। प्रोटोकॉल इम्प्लीमेंट करो और हर कन्फॉर्मिंग क्लाइंट काम करता है। MCP ने AI टूल इंटीग्रेशन के लिए वही किया जो HTTP ने वेब कंटेंट डिलीवरी के लिए किया — ट्रांसपोर्ट लेयर को बोरिंग बना दिया ताकि आप एप्लिकेशन लेयर पर फोकस कर सकें।

प्रैक्टिकल रिज़ल्ट यह है कि आपकी टूल डेफिनिशन्स लायबिलिटी के बजाय एसेट बन जाती हैं। एक बार लिखो, एक बार टेस्ट करो, एक बार डॉक्यूमेंट करो। नया LLM प्रोवाइडर आए तो कुछ रीराइट नहीं। बस अपने MCP सर्वर की तरफ पॉइंट करो और काम हो गया।

अगर मैं यह न मानूं तो बेईमानी होगी: कभी-कभी function calling सही चुनाव है।

अगर ऐसी एप्लिकेशन बना रहे हो जो हमेशा सिर्फ एक LLM इस्तेमाल करेगी, और पता है कौन सा, और इस बारे में खुद को धोखा नहीं दे रहे — तो डायरेक्ट function calling सिंपल है। कम एब्स्ट्रैक्शन। कम मूविंग पार्ट्स। पोर्टेबिलिटी के बदले डायरेक्टनेस लेते हो, और कभी-कभी यह ट्रेड सही होता है।

अगर वेंडर-स्पेसिफिक फीचर्स चाहिए जिनका MCP में अभी कोई विकल्प नहीं — स्ट्रक्चर्ड आउटपुट मोड्स, कंप्यूटर यूज़ APIs, या प्रोवाइडर-स्पेसिफिक स्ट्रीमिंग बिहेवियर — तो डायरेक्ट इंटीग्रेशन समझदारी है। जो प्रोटोकॉल एक्सपोज़ नहीं करता उसे एक्सेस नहीं कर सकते।

और अगर प्रोटोटाइप बना रहे हो, "बस चला दो" वाले फेज़ में हो, तो function calling तेज़ पहुंचाता है। MCP का सेटअप ओवरहेड है। वीकेंड हैकाथॉन के लिए, यह ओवरहेड असली है।

लेकिन एक सवाल का ईमानदारी से जवाब देना होगा: क्या "एक वेंडर हमेशा के लिए" सच में तुम्हारे भविष्य का वर्णन करता है? क्योंकि मेरे अनुभव में, जो कंपनियां कहती हैं "हम सिर्फ OpenAI इस्तेमाल करेंगे" वही छह महीने बाद जब यूज़र्स मांगने लगते हैं तो बेचैनी से Claude सपोर्ट जोड़ रही होती हैं। जो कहती हैं "बस प्रोटोटाइप कर रहे हैं" वही दो साल बाद भी वो प्रोटोटाइप प्रोडक्शन में चला रही होती हैं।

Function calling से MCP पर स्विच करने की कीमत हर दिन बढ़ती है। MCP से शुरू करने की कीमत लगभग स्थिर रहती है।

मुझे लगता है ज़्यादातर लोग यह नहीं देखते: MCP और function calling दुश्मन नहीं हैं। ये एक ही स्टैक में अलग-अलग लेयर्स हैं।

MCP टूल्स को किसी भी LLM के लिए फंक्शन्स के रूप में एक्सपोज़ किया जा सकता है जो function calling सपोर्ट करता है। प्रोटोकॉल ट्रूथ का सोर्स है — आपके टूल्स क्या करते हैं, क्या स्वीकार करते हैं और क्या लौटाते हैं इसका कैनोनिकल डिस्क्रिप्शन। Function calling एडेप्टर्स जेनरेट होते हैं, हाथ से नहीं लिखे जाते। आपका MCP सर्वर सिंगल सोर्स है; वेंडर-स्पेसिफिक फॉर्मेट्स प्रोजेक्शन्स हैं।

इसका मतलब चुनना नहीं पड़ता। MCP को टूल डेफिनिशन लेयर रख सकते हो और हर LLM को डिलीवर करने के लिए function calling इस्तेमाल कर सकते हो। फर्क यह है कि MCP के साथ, वो फंक्शन डेफिनिशन्स एक सिंगल सोर्स से डिराइव होती हैं बजाय प्रति वेंडर अलग से मेंटेन होने के।

इंडस्ट्री इसी दिशा में जा रही है, चाहे उसे पता हो या न हो। "एक कैनोनिकल डिस्क्रिप्शन, कई डिराइव्ड फॉर्मेट्स" का पैटर्न हर दूसरे डोमेन में जीता है — डेटाबेस schemas, API स्पेक्स, टाइप सिस्टम्स। AI टूल इंटीग्रेशन भी इसी पैटर्न पर कन्वर्ज होगा क्योंकि विकल्प एक ऐसा मेंटेनेंस बोझ है जो किसी की भी इंजीनियरिंग टीम से तेज़ बढ़ता है।

जो कंपनियां अभी यह समझ लेती हैं, अपना समय बेहतर टूल्स बनाने में लगाएंगी। जो बाद में समझेंगी, ग्लू कोड रीराइट करने में लगाएंगी। दोनों ग्रुप एक ही जगह पहुंचेंगे। बस सवाल यह है कि वहां पहुंचने में कितना वक्त बर्बाद करते हैं।