MCP API अर्थव्यवस्था को निगल रहा है

Model Context Protocol API इंटीग्रेशन के साथ वही कर रहा है जो REST ने SOAP के साथ किया था: हाथ से लिखी गई इंटीग्रेशन परत की जगह ऐसी चीज़ ले रहा है जिसे एजेंट खुद खोज और इस्तेमाल कर सकते हैं।

ज़्यादातर सीनियर इंजीनियर जब पहली बार MCP सर्वर देखते हैं, उसे JSON-RPC के आसपास का एक रैपर कहकर खारिज कर देते हैं। है भी। 2005 में HTTP पर REST भी यही था।

MCP असल में उसी सवाल का जवाब देता है जिसका जवाब REST बीस साल तक खराब देता रहा: एक सॉफ़्टवेयर अपनी क्षमताएं ऐसे दूसरे सॉफ़्टवेयर को कैसे दिखाए जिसने उसे कभी नहीं देखा? REST का जवाब था "डॉक पढ़ो और क्लाइंट लिखो"। वह जवाब तभी काम करता है जब पढ़ने वाला इंसानी डेवलपर हो।

REST API क्लाइंट कोड लिखने वाले इंसानों के लिए बनी थीं। एंडपॉइंट, डॉक्स, सही क्रम में सही पैरामीटर के साथ हाथ से लिखे fetch कॉल। हर इंटीग्रेशन कस्टम है।

यह तब काम करता है जब उपभोक्ता इंसानी डेवलपर हो। LLM उपभोक्ता हो तो टूट जाता है। LLM आपकी Swagger फाइल पढ़कर यह तय नहीं करता कि बारह में से कौन तीन एंडपॉइंट जोड़ने हैं। उसे इनपुट में ही क्षमता का विवरण चाहिए: टूल का नाम, क्या करता है, इनपुट स्कीमा, आउटपुट स्कीमा, साइड इफेक्ट।

MCP बिल्कुल वही आकार देता है। एक `tools/list` कॉल हर क्षमता को एक JSON स्कीमा के साथ लौटाता है जिस पर मॉडल इनफरेंस के समय तर्क कर सके। कोई SDK नहीं, कोई कोड जेनरेशन नहीं, कोई ऑनबोर्डिंग टिकट नहीं।

MCP को परिवर्तनकारी बनाने वाली कोई एक फ़ीचर नहीं है। रनटाइम कंपोज़िशन है।

जब हर सेवा खुद को MCP टूल्स के रूप में दिखाती है, तो एजेंट उन्हें इनफरेंस के समय खोज और जोड़ सकते हैं। एक सपोर्ट एजेंट CRM से पढ़ता है, बिलिंग सर्विस से पूछता है, Slack संदेश लिखता है, और टिकट खोलता है — ऐसे टूल्स से जिनके बारे में उसे तीस सेकंड पहले पता चला। कोई हार्डकोडेड इंटीग्रेशन नहीं। कोई प्रोवाइडर-विशिष्ट मिडलवेयर नहीं।

यह एजेंट पर लागू Unix दर्शन है। छोटे, केंद्रित टूल जो आपस में जुड़ते हैं। कंपोज़र अब शेल स्क्रिप्ट नहीं है; यह एक मॉडल है जो तर्क कर सकता है कि कौन से टूल किस क्रम में मिलाने हैं।

एजेंट्स को किसी भी टूल से जोड़ना तुच्छ रूप से आसान बनाने से, उन्हें दुर्भावनापूर्ण टूल्स से जोड़ना भी तुच्छ रूप से आसान हो जाता है। टूल पॉइज़निंग — जब विवरण एक व्यवहार का वादा करता है और कार्यान्वयन कुछ और करता है — MCP युग का SQL इंजेक्शन है।

आज MCP सर्वर भेजने वाली ज़्यादातर टीमें यह नहीं सोच रहीं। वे चीज़ों को चलाने पर केंद्रित हैं। वेब के इतिहास में हर बड़ा सुरक्षा संकट ठीक इसी तरह शुरू हुआ है।

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

अगर आप ऐसा सॉफ़्टवेयर बना रहे हैं जिसे दूसरा सॉफ़्टवेयर उपभोग करेगा, तो आपको अब तक MCP इंटरफ़ेस भेज ही रहा होना चाहिए। अर्थशास्त्र मजबूर करता है।

एक REST इंटीग्रेशन डेवलपर के कई दिन लेता है। एक MCP टूल कुछ मिनट लेता है। जब इंटीग्रेशन 100 गुना सस्ता हो जाता है, तो आपको उसी चीज़ का 100 गुना नहीं मिलता — आपको पूरी श्रेणियां मिलती हैं ऐसी इंटीग्रेशनों की जो पहले बनाने लायक नहीं थीं। Stripe पहले से MCP सर्वर भेज रहा है। Linear भी। Supabase भी।

हर SaaS अंततः MCP टूल्स दिखाएगा। हर आंतरिक सेवा का MCP इंटरफ़ेस होगा। एकमात्र असली सवाल है कि क्या आप अपने प्रतिस्पर्धी से पहले एक भेजते हैं।