MCP क्या है, और हर AI टूल अचानक यही क्यों बोल रहा है?
पिछले दशक के ज़्यादातर हिस्से में, किसी AI मॉडल को कंपनी के टूल्स से जोड़ना हर जोड़ी के लिए एक कस्टम इंटीग्रेशन था। Model Context Protocol, वह खुला मानक जिसे Anthropic ने नवंबर 2024 में पेश किया, उसकी जगह एक ऐसा प्लग रखता है जो हर जगह फिट होता है — और OpenAI, Google और Microsoft तीनों ने तब से इसे अपना लिया है। यह वास्तव में कैसे काम करता है, और अपनी टीम के डेटा से जोड़ने से पहले एक असली चेकलिस्ट।
Claude का डेस्कटॉप ऐप खोलिए और उससे अपनी टीम के खुले pull request जाँचने को कहिए, और वह बस कर देता है। इसलिए नहीं कि Anthropic ने Claude के अंदर GitHub इंटीग्रेशन बनाया। इसलिए कि कहीं — आपकी IT टीम, कोई वेंडर, GitHub पर कोई डेवलपर — किसी ने MCP नाम का प्रोटोकॉल बोलने वाला छोटा प्रोग्राम लिखा, और Claude पहले से जानता है कि जो कुछ भी यह प्रोटोकॉल बोलता है उससे कैसे बात करनी है। अब यही बात ChatGPT, Google के Gemini और Microsoft Copilot पर भी लागू होती है। यही संगम, किसी एक फ़ीचर रिलीज़ से ज़्यादा, वजह है कि MCP वह चीज़ बन गया जिसके लिए लगभग हर AI वेंडर ने पिछला साल समर्थन बनाने में लगाया।
MCP वास्तव में क्या है
MCP का मतलब है Model Context Protocol। Anthropic ने इसे डिज़ाइन किया, और 25 नवंबर 2024 को स्पेसिफिकेशन के साथ पहले SDK ओपन-सोर्स किए। उसकी अपनी लॉन्च सामग्री ने इस विचार को एक उपमा से बताया जो चिपक गई: MCP को AI ऐप्लिकेशन के लिए USB-C पोर्ट समझिए — हर एक्सेसरी के लिए अलग केबल की जगह एक भौतिक कनेक्टर मानक। लॉन्च पर Anthropic ने उन शुरुआती अपनाने वालों के नाम लिए जो पहले से अपने उत्पादों में MCP समर्थन बना रहे थे, जिनमें एंटरप्राइज़ सॉफ़्टवेयर कंपनियाँ Block और Apollo, और डेवलपर-टूल बनाने वाले Zed, Replit, Codeium और Sourcegraph शामिल थे। Claude का डेस्कटॉप ऐप उसी दिन इस क्षमता के साथ आया कि किसी व्यक्ति की अपनी मशीन पर MCP सर्वर स्थानीय रूप से चलाए जा सकें।
जो समस्या यह हल करता है: N टूल गुणा M डेटा स्रोत
MCP जिस समस्या को हल करता है उसका एक नाम है जिसे इंजीनियर सहज रूप से इस्तेमाल करते हैं: N-गुणा-M इंटीग्रेशन समस्या। मान लीजिए कोई कंपनी पाँच AI टूल इस्तेमाल करती है जिन्हें कंपनी के डेटा पर काम करना है — Claude, ChatGPT, GitHub Copilot, Cursor, और एक आंतरिक सपोर्ट बॉट — और वह डेटा आठ जगहों पर रहता है: Slack, GitHub, एक Postgres डेटाबेस, Salesforce, Notion, Google Drive, Jira, और एक आंतरिक API। साझा प्रोटोकॉल के बिना, हर टूल को हर स्रोत से उपयोगी तरीके से जोड़ना चालीस तक अलग इंटीग्रेशन लगते हैं — पाँच गुणा आठ — हर एक का अपना प्रमाणीकरण, अपनी त्रुटि-संभाल, और अपना रखरखाव का बोझ, हर बार जब उन API में से कोई बदलता है। छठा AI टूल जोड़िए और संख्या अड़तालीस हो जाती है। व्यवहार में, किसी ने पूरे चालीस नहीं बनाए। हर AI वेंडर ने उतने ही बनाए जितने उसे इंजीनियरिंग समय के लायक लगे, और बाकी मैनुअल रहा: कॉपी, पेस्ट, दोबारा समझाना, फिर वही सब दोहराना।
MCP गुणा को जोड़ में बदल देता है। जो कंपनी चाहती है कि Claude उसका Postgres डेटाबेस पढ़े, वह Claude-विशिष्ट Postgres कनेक्टर नहीं बनाती। वह एक MCP सर्वर बनाती है — या किसी और का प्रकाशित सर्वर दोबारा इस्तेमाल करती है — जो Postgres को उपलब्ध कराता है, और वह सर्वर Claude, ChatGPT, Gemini या किसी और MCP-संगत एजेंट के साथ बिना और कोड के काम करता है। Anthropic की अपनी सूची ने, लॉन्च पर, Google Drive, Slack, GitHub, Git, Postgres और Puppeteer नाम के ब्राउज़र-ऑटोमेशन टूल के लिए पहले से बने सर्वर बताए। बात कभी यह नहीं थी कि Anthropic उन सबको बनाएगी। बात यह थी कि कोई भी बना सकता है, और उपलब्ध सर्वरों की सूची इतनी बढ़ चुकी है कि कोई अकेली कंपनी उसे संभाल नहीं सकती।
प्रोटोकॉल वास्तव में कैसे काम करता है
ढाँचा हटा दीजिए तो MCP एक काफी सादा क्लाइंट-सर्वर प्रोटोकॉल है, जानबूझकर बिना चमक के। यह तीन भूमिकाएँ तय करता है। Host वह ऐप्लिकेशन है जिसे कोई व्यक्ति सच में खोलता है — Claude Desktop, Cursor जैसा IDE, ChatGPT ऐप। Host अपने भीतर एक MCP Client रखता है, जो एक MCP Server से सीधा, स्टेटफुल कनेक्शन खोलता है — एक छोटा प्रोग्राम जो एक खास सिस्टम को उपलब्ध कराता है: डेटाबेस, टिकटिंग टूल, फ़ाइल सिस्टम, आंतरिक API। क्लाइंट और सर्वर JSON-RPC 2.0 प्रारूप के संदेश बदलते हैं, एक हल्का रिमोट-प्रोसीजर-कॉल प्रारूप जो मौजूदा इंफ्रास्ट्रक्चर में पहले से आम है, दो ट्रांसपोर्ट में से एक पर: stdio, जब सर्वर उसी मशीन पर स्थानीय रूप से चलने वाला प्रोग्राम हो, या Streamable HTTP, जब वह कहीं और चल रही होस्टेड सेवा हो।
सर्वर जो उपलब्ध करा सकता है वह तीन प्रिमिटिव तक सिमटता है। Tools वे फ़ंक्शन हैं जिन्हें मॉडल कोई कार्रवाई करने के लिए कॉल कर सकता है — create_task, run_query, send_message — और बातचीत के आधार पर मॉडल तय करता है कब किसी को कॉल करना है। Resources रीड-ओनली संदर्भ हैं जिन्हें Host खींचकर मॉडल को दे सकता है, बिना मॉडल के माँगे — किसी फ़ाइल की सामग्री, डेटाबेस स्कीमा, सपोर्ट टिकट। Prompts दोबारा इस्तेमाल होने वाले, उपयोगकर्ता-चालित टेम्पलेट हैं — तैयार “इस थ्रेड का सार बताओ” या “स्टेटस अपडेट का मसौदा बनाओ” जिसे कोई व्यक्ति स्पष्ट रूप से चलाता है, न कि कुछ ऐसा जो मॉडल खुद करने का फ़ैसला करे। अच्छा बना सर्वर साफ़ बताता है कि दी गई क्षमता के लिए वह तीनों में से कौन-सा दे रहा है, क्योंकि यही फ़र्क तय करता है कि जुड़ा AI टूल किसी चीज़ को देख सकता है या बदल सकता है।
और किसने अपनाया, और कब
MCP के पहले कुछ महीने सिर्फ़ Anthropic का प्रोजेक्ट थे। यह तेज़ी से बदला, और AI में सचमुच असामान्य तरीके से: सीधे प्रतिद्वंद्वी अपना प्रोटोकॉल जारी करने के बजाय एक कंपनी के प्रोटोकॉल पर जुट गए। OpenAI ने मार्च 2025 में अपने Agents SDK में MCP समर्थन जोड़ा, ताकि डेवलपर एजेंट वर्कफ़्लो को किसी भी MCP सर्वर से जोड़ सकें, OpenAI-विशिष्ट कस्टम टूल इंटीग्रेशन बनाने के बजाय। अगले महीने Google DeepMind ने पुष्टि की कि Gemini और उसकी अपनी एजेंट-डेवलपमेंट किट भी MCP का समर्थन करेगी — एक कदम जिसे Google ने अपने पूरक प्रोटोकॉल Agent2Agent के साथ जोड़ा, जिसका मकसद स्वतंत्र एजेंटों को टूल्स के बजाय एक-दूसरे से तालमेल बिठाने देना है। मई 2025 तक Microsoft Windows 11 पर नेटिव MCP समर्थन ले आई थी, जिसे वह Windows AI Foundry कहती है, और समर्थन GitHub Copilot तथा Copilot Studio के अंदर भी पहुँचा।
मॉडल आर्किटेक्चर, कीमत या प्लेटफ़ॉर्म रणनीति की बात हो तो ये चारों कंपनियाँ ज़्यादातर बातों पर सहमत नहीं हैं। चारों अब ऐसे उत्पाद जारी करती हैं जो एजेंट को टूल से जोड़ने के लिए वही प्रोटोकॉल बोलते हैं। इस उद्योग में यह इतना दुर्लभ है कि यही असली कहानी है — MCP जिस किसी एक फ़ीचर को संभव बनाता है उससे ज़्यादा।
यह भरोसे का सवाल क्यों है, सिर्फ़ पाइपलाइन का नहीं
यह संगम सचमुच उपयोगी है, और यही वजह है कि MCP अंधे भरोसे के बजाय जाँच का हक़दार है। जो प्रोटोकॉल किसी एजेंट के लिए आपकी कंपनी के सिस्टम से जुड़ना मामूली बना देता है, वही खराब ढंग से बने या कॉन्फ़िगर किए गए कनेक्शन के लिए उन्हीं सिस्टम तक पहुँचना भी मामूली बना देता है। MCP खुद इसे नहीं रोकता। स्पेसिफिकेशन बताता है कि क्लाइंट और सर्वर एक-दूसरे से कैसे बात करते हैं — यह कुछ नहीं कहता कि कनेक्शन कौन दे सकता है, वह कनेक्शन क्या छू सकता है, या कुछ गलत होने पर कोई नोटिस करेगा या नहीं। वे फ़ैसले पूरी तरह उसके पास हैं जिसने आपके सामने वाला खास सर्वर या क्लाइंट बनाया या कॉन्फ़िगर किया। कुछ वेंडर यह सब सावधानी से बनाते हैं। कुछ बनाते ही नहीं, और प्रोटोकॉल उन्हें रोकेगा नहीं।
MCP एक वायर प्रोटोकॉल है, एक्सेस-कंट्रोल सिस्टम नहीं। यह मानकीकृत करता है कि एजेंट किसी टूल से कुछ करवाने को कैसे कहता है। वह माँग सीमित, लॉग की हुई और रद्द करने योग्य है या नहीं, यह फ़ैसला किसी ने उसके ऊपर लिया — या नहीं लिया।
कोई MCP सर्वर जोड़ने से पहले की चेकलिस्ट
इससे पहले कि आपकी टीम कोई MCP सर्वर जोड़े — चाहे वह वेंडर का उत्पाद हो, GitHub पर मिला ओपन-सोर्स टूल हो, या घर में बना कुछ हो — छह सवाल एक नियंत्रित कनेक्शन को खुले दरवाज़े से अलग करते हैं। इनमें से कोई भी स्पेसिफिकेशन पढ़ने की माँग नहीं करता। वे बस यह माँग करते हैं कि मंज़ूरी क्लिक करने से पहले कोई पूछे, और कनेक्शन स्क्रीन जो जवाब लौटाए उसे सच में पढ़े।
| यह पूछिए | अच्छा कैसा दिखता है | इस पर ध्यान दीजिए |
|---|---|---|
| यह कौन-से स्कोप या Tools माँगता है? | ब्योरेवार नाम वाली, विशिष्ट सूची जिसे मंज़ूरी से पहले पढ़ सकें — “टास्क बनाओ, इस चैनल के संदेश पढ़ो”। | खुली छूट “पूरे अकाउंट की पहुँच”, बिना इस सूची के कि यह वास्तव में क्या कर सकता है। |
| यह रीड-ओनली है, या लिख और काम भी कर सकता है? | अलग डिफ़ॉल्ट में पढ़ने की पहुँच; डेटा बदलने वाली हर कार्रवाई को अपनी दिखाई देने वाली मंज़ूरी चाहिए। | एक साथ लिखने की पहुँच अपने-आप शामिल, बिना यह बताए कौन-सी क्षमता क्या करती है। |
| यह प्रति व्यक्ति है या पूरी टीम में साझा? | प्रति व्यक्ति हर व्यक्ति अपने लॉगिन से साइन इन करता है; एजेंट केवल वही देख सकता है जो वह व्यक्ति देख सकता है। | साझा एक API कुंजी या सर्विस अकाउंट, जिसे पूरी टीम इस्तेमाल करती है और जो व्यक्तिगत अनुमतियों को दरकिनार करता है। |
| क्या इसके हर काम का ऑडिट लॉग मौजूद है? | लॉग किया हर टूल कॉल दर्ज — किसने जोड़ा, उसने क्या छुआ, और कब। | बिना लॉग AI टूल खुद जो बताना चुने उसके अलावा कोई रिकॉर्ड नहीं। |
| क्या इसे तुरंत रद्द किया जा सकता है? | तत्काल एक टॉगल, तुरंत प्रभावी, उस सेटिंग पेज से जिसे आप नियंत्रित करते हैं। | विलंबित रद्द करने के लिए सपोर्ट टिकट या वेंडर को कॉल करना पड़ता है, या यह संभव ही नहीं। |
| क्या इसे रद्द करने से कुछ और टूटता है? | पृथक उसी एक कनेक्शन तक सीमित; बंद करने से केवल वही प्रभावित होता है। | उलझा हुआ अन्य टूल्स के साथ क्रेडेंशियल साझा करता है, इसलिए एक रद्द करने से चुपचाप तीन और टूट जाते हैं। |
अच्छी तरह बना कनेक्शन वास्तव में कैसा दिखता है
FabricLoop का अपना MCP सेटअप उस चेकलिस्ट का एक ठोस जवाब है — इसलिए नहीं कि यह असामान्य है, बल्कि इसलिए कि हर हिस्सा ऊपर के छह सवालों में से एक से सीधे जुड़ता है, और मार्केटिंग संस्करण के बजाय असली कार्यप्रणाली बताना ज़रूरी है। FabricLoop दोनों भूमिकाएँ एक साथ निभाता है: यह एक MCP सर्वर है जिससे बाहर के टूल जुड़ते हैं, ताकि Cursor, Claude या ChatGPT किसी खास व्यक्ति की अपनी FabricLoop अनुमतियों से टास्क बना सकें, टिप्पणी जोड़ सकें या नोट पढ़ सकें — और यह एक MCP क्लाइंट है जो बाहर की ओर जुड़ता है, ताकि कोई चैनल वेंडर का MCP ऐप, जैसे GitHub या Linear, खींच सके और उसे टीममेट की तरह @mention कर सके।
हर कनेक्शन, किसी भी दिशा में, किसी व्यक्ति से शुरू होता है, वर्कस्पेस से नहीं। Cursor जैसा बाहरी क्लाइंट जोड़ना app.fabricloop.com/oauth/consent पर OAuth सहमति स्क्रीन खोलता है, जहाँ वह व्यक्ति वर्कस्पेस चुनता है और उन खास Tools को मंज़ूर करता है जो क्लाइंट माँग रहा है — उसके बाद क्लाइंट केवल उसी स्क्रीन पर दिए गए स्कोप के साथ, उसी एक व्यक्ति की अनुमतियों के तहत काम कर सकता है, कभी साझा सर्विस अकाउंट से नहीं। उलटी दिशा भी इसी तरह चलती है: एडमिन पूरी टीम के लिए वेंडर का MCP ऐप चालू कर सकता है, लेकिन हर व्यक्ति अपना साइन-इन पूरा करता है तभी वह उसके लिए काम करता है, और एडमिन उस ऐप को रीड-ओनली मोड पर रख सकता है या वेंडर जो कुछ भी उपलब्ध कराता है उसके बजाय खास Tools की अनुमति-सूची तक सीमित कर सकता है।
हर जुड़ा क्लाइंट सेटिंग स्क्रीन पर Revoke बटन के बगल में दिखता है, जो उसे तुरंत डिस्कनेक्ट कर देता है — उस व्यक्ति का अपना पेज, सपोर्ट टिकट नहीं। Enterprise प्लान पर वह गतिविधि — MCP को दी गई अनुमतियाँ और जुड़े एजेंट ने वास्तव में क्या किया, सहित — एक ऑडिट लॉग में जाती है जिसे सुरक्षा टीम माँग पर देख सकती है, घटना के बाद चैट थ्रेड से खींचे स्क्रीनशॉट में नहीं।
इसमें कुछ भी असाधारण इंजीनियरिंग नहीं है। यह फ़ैसलों का एक छोटा, जानबूझकर सादा सेट है, जिसे लगातार दोहराया जाता है: दायरा तय कीजिए, किसी व्यक्ति से जोड़िए, लॉग कीजिए, और इसे ऐसे रद्द करने योग्य बनाइए कि कोई और चीज़ न टूटे। यही तर्क यह साइट सुपाठ्यता के बारे में व्यापक रूप से रखती है — जिस पहुँच का आप नाम ले सकें, लॉग कर सकें और रद्द कर सकें, वह उस पहुँच से बेहतर है जिसके बारे में किसी को सोचना ही न पड़े — और MCP यह तभी देता है जब कोई उसे इसी तरह बनाए। प्रोटोकॉल पाइपलाइन को मानक बनाता है। यह गवर्नेंस को अपने-आप लागू नहीं करता।
जो फ़ैसला वास्तव में मायने रखता है
MCP जाने वाला नहीं है, और इस मोड़ पर उसका विरोध करना USB का विरोध करने जैसा है। हर बड़ा मॉडल प्रदाता अब इसे जारी करता है, उपलब्ध सर्वरों की सूची बढ़ती रहती है, और जो एजेंट आपके टूल्स तक नहीं पहुँच सकता, वह ज़्यादातर असली कामों के लिए ऐसा एजेंट है जो बहुत कुछ नहीं कर सकता। दिलचस्प फ़ैसला यह नहीं है कि AI टूल को अपने सिस्टम से जुड़ने दें या नहीं — धीरे-धीरे उस फ़ैसले का कोई रूप आपके लिए पहले ही लिया जा रहा है, एक इंटीग्रेशन के बाद दूसरा, जब आपकी टीम जिन टूल्स का पहले से इस्तेमाल करती है वे किसी फ़ीचर के नीचे चुपचाप MCP समर्थन जोड़ देते हैं जिस पर आपने बारीक अक्षरों की शर्तें पढ़े बिना क्लिक कर दिया। जो फ़ैसला अभी भी सच में आपका है, वह यह है कि मंज़ूरी क्लिक करने से पहले आप क्या जाँचते हैं।
MCP ने मानकीकृत किया कि AI एजेंट किसी टूल से कुछ करवाने को कैसे कहता है। उसने यह मानकीकृत नहीं किया कि वह माँग मंज़ूर करना सुरक्षित है या नहीं — वह हिस्सा अब भी, और आगे भी, “मंज़ूर करें” क्लिक करने वाले व्यक्ति का फ़ैसला रहेगा।