MCP सर्वर क्या है? 2026 में MCP और MCP UI कैसे काम करते हैं

1 अप्रैल 2025 को Invariant Labs ने add नाम का एक टूल पब्लिश किया. यह दो संख्याएं लेता था और उनका जोड़ लौटाता था. लेकिन इसके विवरण में IMPORTANT से चिह्नित एक ब्लॉक भी था, जो क्लाइंट के इंटरफ़ेस में दिखता नहीं था. वह मॉडल से कहता था कि ~/.cursor/mcp.json और ~/.ssh/id_rsa पढ़े और दोनों फ़ाइलें एक फ़ालतू पैरामीटर के ज़रिए बाहर भेज दे. मॉडल ने बात मान ली. यूज़र को सिर्फ़ जोड़-घटाना दिखा.

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

MCP सर्वर क्या है

MCP सर्वर एक प्रोग्राम है जो Model Context Protocol (MCP) के ज़रिए AI ऐप्लिकेशन को टूल, डेटा और प्रॉम्प्ट उपलब्ध कराता है. आधिकारिक डॉक्यूमेंटेशन MCP को “AI ऐप्लिकेशन को बाहरी सिस्टम से जोड़ने का एक ओपन-सोर्स स्टैंडर्ड” बताता है. Claude, ChatGPT, Visual Studio Code या Cursor जैसा कोई AI क्लाइंट सर्वर से कनेक्ट होता है, पूछता है कि वह क्या-क्या देता है, और यूज़र की ओर से उन क्षमताओं को कॉल करता है.

Anthropic ने 25 नवंबर 2024 को MCP की घोषणा की, साथ में छह तैयार सर्वर थे: Google Drive, Slack, GitHub, Git, Postgres और Puppeteer. OpenAI ने मार्च 2025 में इसे अपनाया. Google DeepMind अप्रैल में साथ आया. दिसंबर 2025 में Anthropic ने यह प्रोटोकॉल Agentic AI Foundation को दान कर दिया, जो Linux Foundation के तहत एक डायरेक्टेड फ़ंड है और जिसकी सह-स्थापना Anthropic, Block और OpenAI ने की.

समस्या कनेक्शनों की बढ़ती संख्या है। MCP से पहले GitHub तक पहुँच चाहने वाला हर AI ऐप अपना कनेक्टर लिखता था और हर प्रदाता हर ऐप के लिए कनेक्शन बनाता था। दस मॉडल और दस टूल सौ एकीकरण तक माँग सकते थे। MCP इसे बीस करता है: हर क्लाइंट प्रोटोकॉल एक बार लागू करता है और हर सिस्टम एक सर्वर उपलब्ध कराता है।

इसे AI इंटीग्रेशन का शिपिंग कंटेनर समझिए. कंटेनर से पहले हर बंदरगाह हर माल को हाथ से लादता था, अपनी क्रेनों और अपने मज़दूरों के साथ. कंटेनर ने डिब्बे को मानक बना दिया, जिससे कोई भी जहाज़, क्रेन और ट्रक कोई भी माल ढो सकता था. उसने यह मानक नहीं बनाया कि डिब्बे के अंदर क्या जाएगा, और उसने अंदर का सामान कभी जांचा भी नहीं. MCP भी यही सौदा है. दूसरी बात याद रखिए; यह सुरक्षा वाले हिस्से में फिर लौटेगी.

MCP सर्वर कैसे काम करता है

मौजूदा स्पेसिफ़िकेशन, यानी वर्शन 2026-07-28, तीन भूमिकाओं के बीच JSON-RPC 2.0 मैसेज इस्तेमाल करता है. इसका अपना विवरण बस तीन लाइन का है: होस्ट “LLM ऐप्लिकेशन हैं जो कनेक्शन शुरू करते हैं”, क्लाइंट “होस्ट ऐप्लिकेशन के अंदर के कनेक्टर हैं”, और सर्वर “ऐसी सेवाएं हैं जो संदर्भ और क्षमताएं देती हैं”.

होस्ट, क्लाइंट, सर्वर

होस्ट वह ऐप्लिकेशन है जिसमें आप टाइप करते हैं: Claude Desktop, कोई IDE, या आपका अपना एजेंट. इसके अंदर हर सर्वर कनेक्शन के लिए एक क्लाइंट चलता है. सर्वर दूसरी तरफ़ बैठता है और असली सिस्टम से बात करता है, चाहे वह Postgres डेटाबेस हो, GitHub API हो या आपकी डिस्क का कोई फ़ोल्डर. होस्ट तय करता है कि मॉडल क्या देखेगा और यूज़र को किस चीज़ की मंज़ूरी देनी होगी. सर्वर तय करता है कि नीचे वाला सिस्टम क्या करेगा.

1. होस्ट Claude Desktop · कोई IDE · आपका अपना एजेंट

   मॉडल को टूल दिखाता है, यूज़र से सहमति मांगता है

2. क्लाइंट हर सर्वर कनेक्शन के लिए एक

   stdio या Streamable HTTP पर JSON-RPC बोलता है

3. MCP सर्वर टूल · रिसोर्स · प्रॉम्प्ट

   बताता है कि वह क्या देता है और कॉल चलाता है

4. नीचे का सिस्टम डेटाबेस · SaaS API · लोकल फ़ाइलें

   असली काम करता है

टूल, रिसोर्स और प्रॉम्प्ट

एक सर्वर तीन तरह की चीज़ें दे सकता है:

• टूल ऐसे फ़ंक्शन हैं जिन्हें मॉडल चला सकता है: create_issue, query_orders, send_email. हर टूल का एक नाम, एक विवरण और उसके इनपुट के लिए एक JSON Schema होता है.
• रिसोर्स यूज़र या मॉडल के पढ़ने के लिए संदर्भ और डेटा हैं: कोई फ़ाइल, डेटाबेस स्कीमा या कोई रिकॉर्ड.
• प्रॉम्प्ट टेम्पलेट वाले मैसेज और वर्कफ़्लो हैं जिन्हें यूज़र चुन सकता है, जैसे “इस पुल रिक्वेस्ट का सारांश बनाओ”.

सबसे ज़्यादा ध्यान टूल को मिलता है क्योंकि वे काम करते हैं. इसी वजह से सबसे ज़्यादा जोखिम भी उन्हीं में है.

एक टूल कॉल, कदम दर कदम

2026-07-28 के संशोधन ने MCP को स्टेटलेस बना दिया. अब कोई initialize हैंडशेक नहीं है; हर रिक्वेस्ट अपने प्रोटोकॉल वर्शन और क्लाइंट की क्षमताओं को _meta फ़ील्ड में लेकर चलती है, और सर्वर को server/discover मेथड लागू करना होता है ताकि क्लाइंट पहले ही पूछ सके कि वे क्या सपोर्ट करते हैं. अब एक टूल कॉल ऐसे चलता है:

1. यूज़र कहता है: इस बग के लिए एक टिकट बनाओ

2. कदम 1

   खोज

   • क्लाइंट वर्शन और क्षमताओं के लिए server/discover कॉल कर सकता है
3. कदम 2

   टूल की सूची

   • tools/list नाम, विवरण और इनपुट स्कीमा लौटाता है
4. कदम 3

   मॉडल टूल चुनता है

   • होस्ट टूल की परिभाषाएं मॉडल को देता है
5. कदम 4

   यूज़र की सहमति

   • स्पेसिफ़िकेशन कहता है कि होस्ट को कोई भी टूल चलाने से पहले स्पष्ट सहमति लेनी होगी
6. कदम 5

   कॉल

   • आर्ग्युमेंट के साथ tools/call, प्रोटोकॉल वर्शन _meta में

7. इनपुट अधूरा? सर्वर input_required लौटाता है; क्लाइंट जवाबों के साथ दोबारा कोशिश करता है

   कदम 6

   नतीजा

8. नतीजा संदर्भ के रूप में मॉडल के पास लौटता है

कदम 6 इस संशोधन में नया है. जिस सर्वर को और जानकारी चाहिए, वह अब क्लाइंट को अपनी अलग रिक्वेस्ट नहीं भेजता. वह input_required से चिह्नित नतीजा लौटाता है, क्लाइंट जवाब इकट्ठा करता है और मूल कॉल दोबारा करता है. स्पेसिफ़िकेशन इसे Multi Round-Trip Request पैटर्न कहता है.

ट्रांसपोर्ट: stdio और Streamable HTTP

स्पेसिफ़िकेशन दो मानक ट्रांसपोर्ट तय करता है:

• stdio: क्लाइंट सर्वर को सबप्रोसेस के रूप में चलाता है और स्टैंडर्ड इनपुट और आउटपुट पर नई लाइन से अलग किए गए JSON-RPC मैसेज का लेन-देन करता है. ज़्यादातर लोकल सर्वर ऐसे ही चलते हैं, और इसका मतलब है कि सर्वर आपकी मशीन पर आपकी अनुमतियों के साथ चलता है.
• Streamable HTTP: हर मैसेज एक ही एंडपॉइंट पर HTTP POST होता है, और जवाब JSON ऑब्जेक्ट या रिक्वेस्ट तक सीमित इवेंट स्ट्रीम के रूप में लौटते हैं. रिमोट, होस्टेड सर्वर ऐसे ही चलते हैं.

पुराना HTTP+SSE ट्रांसपोर्ट औपचारिक रूप से डिप्रिकेटेड है. 2026-07-28 के संशोधन ने प्रोटोकॉल-स्तर के सेशन और Mcp-Session-Id हेडर भी हटा दिए; जिस सर्वर को कई कॉल के बीच स्टेट चाहिए, वह अब अपना हैंडल खुद बनाता है और उसे एक सामान्य टूल आर्ग्युमेंट के रूप में वापस पाता है.

ऑथराइज़ेशन

MCP में ऑथराइज़ेशन वैकल्पिक है, और यह सिर्फ़ HTTP पर लागू होता है. stdio पर स्पेसिफ़िकेशन कहता है कि सर्वर को क्रेडेंशियल एनवायरनमेंट से लेने चाहिए. HTTP पर, एक सुरक्षित MCP सर्वर OAuth 2.1 रिसोर्स सर्वर की तरह काम करता है. उसे OAuth Protected Resource Metadata (RFC 9728) पब्लिश करना होता है ताकि क्लाइंट उसका ऑथराइज़ेशन सर्वर ढूंढ सकें. क्लाइंट को बताना होता है कि टोकन ठीक किस सर्वर के लिए है (RFC 8707 रिसोर्स इंडिकेटर). सर्वर को हर वह टोकन ठुकराना होता है जो उसके लिए जारी नहीं हुआ, और सुरक्षा गाइडेंस “टोकन पासथ्रू” को, यानी क्लाइंट का टोकन बिना बदले किसी नीचे वाली API तक भेजने को, साफ़ तौर पर वर्जित बताती है.

यह आख़िरी नियम जितना दिखता है, उससे ज़्यादा अहम है. जो सर्वर मिला हुआ हर टोकन आगे बढ़ा देता है, वह हर टोकन रखने वाले के लिए प्रॉक्सी बन जाता है.

MCP UI क्या जोड़ता है: ऐसे सर्वर जो इंटरफ़ेस लौटाते हैं

टेक्स्ट जवाब उसी पल बेकार हो जाते हैं जब यूज़र को चालीस पंक्तियों की तुलना करनी हो, बारह फ़ील्ड वाला फ़ॉर्म बदलना हो या बदलावों के एक बैच को एक-एक करके मंज़ूर करना हो. “MCP UI” वह नाम है जिससे लोग इसका हल खोजते हैं: सर्वर एक इंटरैक्टिव इंटरफ़ेस लौटाता है जो AI क्लाइंट के अंदर, बातचीत के बगल में दिखता है.

स्थिति ठीक-ठीक बताना ज़रूरी है। विचार समुदाय के MCP-UI प्रोजेक्ट से शुरू हुआ। OpenAI ने Apps SDK में समान व्यवस्था बनाई। MCP परियोजना ने दोनों के साथ 21 नवंबर 2025 को साझा मानक प्रस्तावित किया और 26 जनवरी 2026 को MCP Apps पहला आधिकारिक MCP विस्तार प्रकाशित किया। MCP-UI पैकेज अब यह विनिर्देश लागू करते हैं और आगे के सुधारों के लिए समुदाय का प्रयोग स्थल बने हुए हैं।

तो आज MCP UI का मतलब है MCP Apps. यह आधिकारिक है, और यह एक एक्सटेंशन है, कोर प्रोटोकॉल नहीं. एक्सटेंशन वैकल्पिक होते हैं: क्लाइंट और सर्वर दोनों को इन्हें सपोर्ट करना होता है, और डॉक्यूमेंटेशन साफ़ कहता है कि “होस्ट का सपोर्ट हर क्लाइंट में अलग होता है.” MCP Apps डॉक्यूमेंटेशन सपोर्ट करने वाले होस्ट के रूप में Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam और Archestra.AI को गिनाता है. जिस सर्वर के टूल UI लौटाते हैं, उसे ऐसे क्लाइंट के लिए भी काम करना होगा जो सिर्फ़ टेक्स्ट दिखाता है.

तकनीकी रूप से, यह MCP के अपने ही हिस्सों को दोबारा इस्तेमाल करता है:

1. टूल के विवरण में _meta.ui.resourceUri होता है, जो एक ui:// रिसोर्स की ओर इशारा करता है.
2. होस्ट वह रिसोर्स, यानी स्क्रिप्ट समेत एक HTML पेज, लाता है और टूल कॉल होने से पहले ही उसे प्रीलोड कर सकता है.
3. होस्ट उसे एक सैंडबॉक्स्ड iframe में दिखाता है, जो पैरेंट पेज, उसकी कुकीज़ या उसका स्टोरेज नहीं पढ़ सकता.
4. ऐप और होस्ट postMessage पर MCP की JSON-RPC बोली में बात करते हैं. ऐप टूल कॉल का अनुरोध कर सकता है, और होस्ट तय करता है कि किन्हें अनुमति देनी है.

कीमत असली है. अब आप किसी और के ऐप्लिकेशन के अंदर एक वेब फ़्रंट एंड भेज रहे हैं, ऐसी कंटेंट सिक्योरिटी पॉलिसी के साथ जो आपको घोषित करनी होगी, ऐसे रेंडरिंग नियमों के साथ जिन पर आपका कंट्रोल नहीं, और हर उस होस्ट के लिए टेक्स्ट विकल्प के साथ जो इसे अनदेखा करता है. फ़ायदा यह है कि मंज़ूरी का काम अब चैट ट्रांसक्रिप्ट नहीं रहता. डॉक्यूमेंटेशन की अपनी उपयुक्त उदाहरणों की सूची “खर्च की रिपोर्ट मंज़ूर करना, कोड बदलावों की समीक्षा करना या इश्यू छांटना” पर ख़त्म होती है, और यही इसका ईमानदार केंद्र है: MCP UI फ़ैसलों में सबसे अच्छा है, सजावट में नहीं.

केवल पढ़ने वाला Tajo उदाहरण

Tajo के Alto MCP में query_contacts है, जो जुड़े कार्यक्षेत्र में सहेजे संपर्क खोजता है। ईमेल से एक मौजूदा संपर्क खोजकर उसका ID, ईमेल सहमति की स्थिति और आखिरी बार दिखने का समय जाँचें। अलग get_contact_topic_status टूल उसके विषय सदस्यताओं को पढ़ता है।

ये कार्यक्षेत्र से पढ़े गए डेटा हैं। ये प्रदाता से नया डेटा नहीं लाते, सिंक शुरू नहीं करते या संदेश नहीं भेजते। ये सभी प्रदाता कनेक्टर चालू होने का प्रमाण भी नहीं हैं। गायब या पुराने डेटा की जाँच स्रोत पर करें। खाली नतीजे से यह सिद्ध नहीं होता कि व्यक्ति Brevo में नहीं है।

Tajo MCP दस्तावेज़ की मदद से समर्थित क्लाइंट जोड़ें और अपने अधिकृत कार्यक्षेत्र में वास्तव में उपलब्ध टूल देखें। होस्ट MCP Apps समर्थित हो तो संवादात्मक पैनल समीक्षा आसान बना सकता है; टेक्स्ट नतीजे को फिर भी परिणाम बताना चाहिए।

टूल कॉल टिकाऊ सिंक नहीं है

नियमित सिंक को शेड्यूल, स्थिर रिकॉर्ड पहचान, सहेजी प्रगति, पुनः प्रयास के निर्णय और पूरे हुए लेखन का रिकॉर्ड भी चाहिए। ये काम चलाने वाले ऐप की ज़िम्मेदारियाँ हैं। MCP टूल तक पहुँच मानकीकृत करता है; टूल की सूची से ये व्यावसायिक नियम नहीं बनते।

टाइमआउट के बाद पढ़ना आम तौर पर दोहराया जा सकता है। भेजना या भुगतान पहले ही हो चुका हो सकता है। दोबारा कोशिश से पहले निष्पादन रिकॉर्ड रखें और परिणाम मिलाएँ। मॉडल का विश्वास कार्रवाई की अनुमति नहीं देता, न दोहराव को सुरक्षित बनाता है।

संपर्क को गंतव्य में लिखने के लिए Brevo API गाइड देखें। गणना वाले फ़ील्ड को कब अलग बनाए रखे जाने वाले सिंक की ज़रूरत है, इसके लिए reverse ETL पढ़ें।

सुरक्षा का बिल प्रोटोकॉल के साथ आता है

आपत्ति को पूरा रखना ज़रूरी है: “MCP एक संभावना पर चलने वाले मॉडल को ऐसे फ़ंक्शन की सूची थमा देता है जो डेटा मिटा सकते हैं और ईमेल भेज सकते हैं, फिर उनके विवरण के लिए अजनबियों के लिखे टेक्स्ट पर भरोसा करता है. यह इंटीग्रेशन स्टैंडर्ड नहीं है. यह स्पेसिफ़िकेशन वाला सप्लाई-चेन हमला है.” इसका ज़्यादातर हिस्सा सही है. स्पेसिफ़िकेशन ख़ुद इस आधार से सहमत है. इसका सुरक्षा सेक्शन कहता है कि टूल “मनमाने कोड के चलने का प्रतिनिधित्व करते हैं और उनके साथ उचित सावधानी बरतनी चाहिए”, कि टूल के विवरण “अविश्वसनीय माने जाने चाहिए, जब तक वे किसी भरोसेमंद सर्वर से न मिले हों”, और कि MCP “इन सुरक्षा सिद्धांतों को प्रोटोकॉल के स्तर पर लागू नहीं कर सकता”.

अब तक का रिकॉर्ड यह है:

• टूल पॉइज़निंग (tool poisoning). Invariant Labs का अप्रैल 2025 का खुलासा, यानी ऊपर वाला add टूल. उसी पोस्ट में रग पुल (rug pull) का ज़िक्र था, जिसमें सर्वर आपकी मंज़ूरी के बाद टूल का विवरण बदल देता है, और शैडोइंग (shadowing) का, जिसमें एक दुर्भावनापूर्ण सर्वर किसी भरोसेमंद सर्वर के प्रति मॉडल का व्यवहार दोबारा लिख देता है.
• लोकल सर्वर में सेंध. जुलाई 2025 में JFrog ने mcp-remote के वर्शन 0.0.5 से 0.1.15 में CVE-2025-6514 का खुलासा किया, जिससे एक दुर्भावनापूर्ण सर्वर यूज़र की मशीन पर कमांड चला सकता था. उसी गर्मी में CVE-2025-49596 ने Anthropic के अपने MCP Inspector को निशाना बनाया, जो डिफ़ॉल्ट रूप से बिना ऑथेंटिकेशन के आता था.
• स्कोप का फैलाव. आधिकारिक सुरक्षा बेस्ट प्रैक्टिस इस पैटर्न का नाम लेती हैं: टोकन को शुरू में ही files:* या admin:* दे दिया जाता है, क्योंकि सर्वर ने हर स्कोप की सूची दी और क्लाइंट ने सब मांग लिए.
• आधिकारिक चिंता. मई 2026 में अमेरिका की National Security Agency ने कहा कि MCP का “तेज़ी से फैलाव उसके सुरक्षा मॉडल के विकास से आगे निकल गया है.”

आपत्ति ग़लत कहां होती है? नतीजे में. हल कभी यह नहीं था कि मॉडल को सिस्टम से जोड़ना बंद कर दिया जाए; टीमें यह पहले से कर रही थीं, प्रॉम्प्ट और स्क्रिप्ट में चिपकाई गई कच्ची API कुंजियों के साथ, बिना किसी ऑडिट ट्रेल के. हल यह है कि MCP सर्वर को किसी भी दूसरी विशेषाधिकार वाली डिपेंडेंसी की तरह बरता जाए:

• सर्वर सिर्फ़ उन्हीं स्रोतों से इंस्टॉल करें जिन्हें आप MCP के बाहर भी वही क्रेडेंशियल सौंप देते.
• लंबे समय तक चलने वाली कुंजियां रखने वाली लोकल बाइनरी के बजाय OAuth और सीमित स्कोप वाले रिमोट सर्वर को प्राथमिकता दें.
• हर राइट के लिए इंसानी मंज़ूरी ज़रूरी रखें, और लॉग करें कि किसने क्या मंज़ूर किया.
• सर्वर के वर्शन पिन करें, और जब किसी टूल का विवरण बदले तो दोबारा समीक्षा करें.
• पूरी API नहीं, काम के हिसाब से बने टूल खोलें; जो डिलीट एंडपॉइंट कभी खोला ही नहीं गया, मॉडल उसका ग़लत इस्तेमाल नहीं कर सकता.

प्रोटोकॉल ने डिब्बे को मानक बनाया. माल की जांच अब भी आपका काम है.

MCP सर्वर बनाएं या मौजूदा सर्वर इस्तेमाल करें

mcp.so जैसी सार्वजनिक डायरेक्टरी कम्युनिटी के बनाए सर्वरों की सूची रखती हैं, और कई SaaS वेंडर अपने सर्वर पब्लिश करते हैं. उदाहरण के लिए, Brevo एक MCP सर्वर देता है जो अलग-अलग सर्वरों में भी बंटा है, ताकि किसी एजेंट को कैम्पेन के बिना सिर्फ़ कॉन्टैक्ट दिए जा सकें. फ़ैसला मेहनत से कम और इस बात से ज़्यादा जुड़ा है कि टूल का आकार किसके हाथ में होना चाहिए.

आपके एजेंट को कौन-सा MCP सर्वर इस्तेमाल करना चाहिए?

1. वेंडर ऐसा सर्वर पब्लिश करता है जो काम पूरा करता है

   वेंडर का सर्वर इस्तेमाल करें

   यह API के साथ चलता है और वेंडर इसकी देखरेख करता है.

2. एक ही सिस्टम, लेकिन आपको कम या ज़्यादा सुरक्षित एक्शन चाहिए

   इसे सीमित स्कोप के साथ इस्तेमाल करें

   कम से कम स्कोप दें और सिर्फ़ वे टूल समूह खोलें जिनकी एजेंट को ज़रूरत है.

3. इंटरनल डेटा या ऐसा सिस्टम जिसका कोई सर्वर नहीं

   एक छोटा सर्वर बनाएं

   आपकी अपनी API पर काम के हिसाब से बने कुछ टूल, आपके अपने ऑथ के साथ.

4. काम दो या ज़्यादा सिस्टम में फैला है

   एक नियंत्रित लेयर बनाएं या अपनाएं

   सभी सिस्टम के लिए टूल, सहमति के नियम और ऑडिट हिस्ट्री का एक ही सेट.

एक बुनियादी सर्वर बनाना आसान हिस्सा है. किसी आधिकारिक SDK के साथ, एक टूल वाला चालू stdio सर्वर एक दोपहर का काम है. कीमत बाद में चुकानी पड़ती है: HTTP वर्शन के लिए OAuth, डिप्रिकेशन (2026-07-28 के संशोधन ने Roots, Sampling और Logging, और साथ ही Dynamic Client Registration को डिप्रिकेट किया), और ऐसे टूल विवरण लिखने का लगातार काम जिन्हें मॉडल सही पढ़े. हर एंडपॉइंट के लिए एक टूल बनाकर API को लपेटना सबसे आम ग़लती है. हर टूल विवरण ऐसा टेक्स्ट है जिसे मॉडल को पढ़ना और तौलना पड़ता है, इसलिए काम के हिसाब से बने टूल की छोटी सूची पूरी API सतह से बेहतर है.

MCP, API, इंटीग्रेशन और iPaaS

MCP API की जगह नहीं लेता. लगभग हर MCP सर्वर किसी API के ऊपर एक रैपर है. असली काम अब भी API में होता है, अपनी रेट लिमिट, डेटा मॉडल और ख़ासियतों के साथ. MCP यह बदलता है कि उसे कौन कॉल कर सकता है: एक मॉडल, रनटाइम पर, विवरण पढ़कर कॉल चुनता है, बजाय इसके कि कोई डेवलपर उसे पहले से कोड में लिख दे.

यह फ़र्क उन दो दूसरी चीज़ों से एक साफ़ रेखा खींचता है जिनसे इसे अक्सर मिला दिया जाता है:

• इंटीग्रेशन और iPaaS (मुख्य प्लेटफ़ॉर्म की तुलना यहां है) डेटा को शेड्यूल या ट्रिगर पर, तय तरीके से, आगे बढ़ाते हैं, चाहे कोई चैट में हो या न हो. 40,000 ऑर्डर का CRM में रात का सिंक इस पर निर्भर नहीं होना चाहिए कि कोई मॉडल 40,000 टूल कॉल करने का फ़ैसला करे.
• रिवर्स ETL वेयरहाउस से मॉडल किया गया डेटा वापस ऑपरेशनल टूल में भेजता है. रिवर्स ETL क्या है और यह कब सही बैठता है अपने आप में अलग विषय है, और यह एक पाइपलाइन है, बातचीत नहीं.
• MCP उन पलों के लिए है जब किसी व्यक्ति या एजेंट को उन सिस्टम में, ज़रूरत के वक़्त, कुछ पूछना, जांचना या करना हो.

ग़लती दोनों दिशाओं में होती है. कुछ टीमें बल्क सिंक के लिए MCP सर्वर बनाती हैं, और उन्हें धीमी, महंगी और दोहराई न जा सकने वाली पाइपलाइन मिलती है. दूसरी टीमें सावधानी से इंटीग्रेशन बनाती हैं और फिर उन्हें क्वेरी करने के लिए अपने AI असिस्टेंट को कच्ची API कुंजी थमा देती हैं, और उन्हें बिना नियंत्रण का एक पिछला दरवाज़ा मिलता है.

समर्थित एकीकरण में स्थायी काम और उसकी जाँच करने वाले टूल के लिए अनुमति की स्पष्ट सीमा होनी चाहिए। विशेष प्रक्रिया के कनेक्टर, अनुमत कार्रवाइयाँ और दर्ज नतीजे जाँचें। एकीकरण दस्तावेज़ सेटअप निर्देशों को उन रास्तों से अलग करता है जिन्हें अभी उत्पादन प्रमाण चाहिए। MCP अलग स्वीकृत टूल दे सकता है; उनकी सूची नियमित सिंक या सभी नियंत्रण चालू होने का प्रमाण नहीं है।

22 महीनों में MCP छह रेफ़रेंस सर्वर से Linux Foundation का ऐसा प्रोजेक्ट बन गया जिसे Claude, ChatGPT, VS Code और Cursor सभी बोलते हैं. मॉडल को सिस्टम से जोड़ना अब सस्ता हिस्सा है. वहां उसे क्या करने की अनुमति है, यह तय करना ही असली काम है.