MCP, यानी Model Context Protocol, एक ओपन स्टैंडर्ड है जो AI असिस्टेंट को हर टूल के लिए अलग कोड लिखे बिना फ़ाइलों, डेटाबेस, कैलेंडर और क्रिएटिव टूल्स से जोड़ता है। यह आर्टिकल क्लाइंट, सर्वर, टूल्स और रिसोर्स को सरल उपमाओं, असली उदाहरणों और ध्यान रखने योग्य जोखिमों के साथ समझाता है।
किसी AI असिस्टेंट से अपना कैलेंडर देखने, स्प्रेडशीट पढ़ने या आपकी रिपॉज़िटरी का बग ठीक करने को कहें, तो अक्सर एक विनम्र माफ़ी मिलती है। मॉडल तेज़ है, लेकिन वह एक बंद कमरे में बैठा है, जहाँ न आपकी फ़ाइलों का दरवाज़ा है, न आपके ऐप्स का और न ही लाइव वेब का। MCP, यानी Model Context Protocol, वही दरवाज़ा है। यह एक ओपन स्टैंडर्ड है, जो AI ऐप्स को एक साझा कनेक्शन के ज़रिए बाहरी टूल्स और डेटा से जोड़ता है, ठीक वैसे जैसे एक ही पोर्ट से लैपटॉप मॉनिटर, हार्ड ड्राइव और कैमरे से बात करता है। यह आर्टिकल बताता है कि MCP क्या है, यह कैसे काम करता है और रोज़मर्रा के उपयोग में यह कैसा दिखता है। हर विचार को किसी ऐसी चीज़ से जोड़ा गया है जिसकी आप कल्पना कर सकें।
💡 त्वरित उत्तर: MCP AI ऐप्स और उन टूल्स के बीच एक सामान्य भाषा है, जिन पर वे निर्भर रहते हैं। Anthropic ने इसे नवंबर 2024 में पेश किया था, और अब कई दूसरी कंपनियों के प्रोडक्ट भी इसे सपोर्ट करते हैं।
MCP का पूरा नाम है Model Context Protocol। प्रोटोकॉल नियमों का वह तय सेट है, जिससे दो प्रोग्राम आपस में बात करते हैं। Context वह जानकारी है, जिसकी किसी मॉडल को उपयोगी जवाब देने के लिए ज़रूरत होती है: आपके दस्तावेज़, आपका डेटा, आपके प्रोजेक्ट की स्थिति। इन सबको मिलाकर, MCP मॉडल तक context पहुँचाने, और मॉडल को उस पर कार्रवाई करने देने के नियमों का सेट है।
ऐसे प्रोटोकॉल के बिना, AI मॉडल केवल वही जानता है जो उसने ट्रेनिंग के दौरान सीखा, और जो टेक्स्ट आप चैट में पेस्ट करते हैं। इसीलिए वह यह नहीं बता सकता कि आज आपके इनबॉक्स में क्या है या आज सुबह आपके कोडबेस में क्या बदला। MCP उसे यह पूछने का एक सुरक्षित और मानक तरीका देता है।
Anthropic का अपना दस्तावेज़ MCP की तुलना AI ऐप्स के लिए USB-C पोर्ट से करता है, और यह तुलना अच्छी तरह फ़िट बैठती है। USB-C से पहले हर गैजेट का अपना केबल और अपना प्लग होता था। एक पोर्ट और एक तय सिग्नल स्टैंडर्ड से कोई भी डिवाइस किसी दूसरे डिवाइस से बात कर सकता है।
MCP सॉफ़्टवेयर के लिए यही काम करता है। MCP बोलने वाला AI ऐप किसी भी MCP सर्वर से जुड़ सकता है, चाहे उसे उसी कंपनी ने बनाया हो या किसी अजनबी ने, जिसने उसे पिछले हफ़्ते ही प्रकाशित किया हो।
MCP से पहले, AI को किसी टूल से जोड़ना हर बार एक अलग काम होता था। मान लीजिए आपके पास 5 AI ऐप्स हैं और 20 टूल्स हैं, जिन्हें आप उनसे इस्तेमाल कराना चाहते हैं। हर जोड़ी को अपना अलग ब्रिज चाहिए, तो आपके सामने अधिकतम 100 अलग-अलग इंटीग्रेशन होंगे, जिनमें से हर एक की अपनी अलग बारीकियाँ और अपना रखरखाव खर्च होगा।
MCP उस गुणा को जोड़ में बदल देता है। हर AI ऐप एक MCP क्लाइंट बनाता है, और हर टूल एक MCP सर्वर बनाता है। यानी 100 के बजाय 5 + 20 = 25 हिस्से।
| सेटअप | AI ऐप्स | टूल्स | बनाने वाले हिस्से |
|---|---|---|---|
| MCP के बिना | 5 | 20 | अधिकतम 100 |
| MCP के साथ | 5 | 20 | 25 |
एक यूनिवर्सल ट्रेवल एडैप्टर इसे समझने का अच्छा मानसिक चित्र है। आप हर देश के लिए अलग चार्जर नहीं ले जाते। आप एक ऐसा एडैप्टर ले जाते हैं, जिसके स्लाइडिंग पिन हों, और दीवार के सॉकेट का फ़र्क बहुत कम मायने रखता है। मॉडल और उसके आसपास की दुनिया के बीच के कनेक्शन के लिए MCP वही एडैप्टर है।
एक और फ़ायदा यह है कि एक बार लिखा गया सर्वर नए AI ऐप्स आने के बाद भी काम करता रहता है। इसलिए जो मेहनत आपने एक कनेक्शन पर लगाई, वह असिस्टेंट बदलने पर बेकार नहीं जाती।
एक बार इनके नाम जान लेने के बाद इसके हिस्से सरल लगते हैं। तीन भूमिकाएँ, तीन तरह के बिल्डिंग ब्लॉक, और एक मैसेज फ़ॉर्मेट।
एक रेस्टोरेंट इन भूमिकाओं को आसानी से याद रखने में मदद करता है। आप ग्राहक हैं, और AI मॉडल टीम का वह हिस्सा है जो तय करता है कि क्या ऑर्डर करना है। क्लाइंट वेटर है, जो अनुरोध को उस फ़ॉर्मेट में लिखता है जिसकी किचन को उम्मीद है, और उसे आगे पहुँचाता है। सर्वर किचन है, जो असली काम करता है और तैयार डिश वापस भेजता है।
वेटर कभी खाना नहीं पकाता, और किचन को यह जानने की ज़रूरत नहीं होती कि टेबल छह पर कौन बैठा है। दोनों तरफ़ को बस ऑर्डर की पर्ची का सम्मान करना होता है, और वह पर्ची ही प्रोटोकॉल है।
एक सर्वर तीन तरह के बिल्डिंग ब्लॉक उपलब्ध करा सकता है। ज़्यादातर सर्वर इनमें से एक या दो ही इस्तेमाल करते हैं।
| बिल्डिंग ब्लॉक | इस्तेमाल का फ़ैसला कौन करता है | सरल अर्थ | उदाहरण |
|---|---|---|---|
| Tools | मॉडल | वे कार्रवाइयाँ जो AI कर सकता है | इश्यू बनाना, संदेश भेजना, इमेज जनरेट करना |
| Resources | ऐप | वह डेटा जिसे AI पढ़ सकता है | एक फ़ाइल, डेटाबेस की एक पंक्ति, एक दस्तावेज़ |
| Prompts | यूज़र | तैयार टेम्पलेट | "इस पull request की समीक्षा करें" |
Tools वे हैं जिन पर लोग सबसे पहले ध्यान देते हैं। गैराज की पेगबोर्ड दीवार की कल्पना करें, जहाँ हर हाथ का औज़ार अपनी निशान लगी जगह पर टँगा होता है। हर MCP टूल का भी एक नाम होता है, उसके काम का छोटा विवरण होता है, और उन इनपुट्स की सूची होती है जिनकी उसे ज़रूरत होती है। मॉडल उन विवरणों को पढ़कर तय करता है कि कौन सा टूल काम के लिए सही है, जैसे आप बोर्ड देखकर सही रिंच उठाते हैं।
Resources एक लाइब्रेरी की तरह काम करते हैं। AI कुछ बदल नहीं रहा होता। वह शेल्फ़ से एक किताब निकाल रहा होता है, ताकि उसके अंदर की बातें पढ़ सके। एक resource टेक्स्ट फ़ाइल हो सकता है, डेटाबेस रिकॉर्ड हो सकता है, या कल का लॉग हो सकता है। आम तौर पर होस्ट तय करता है कि कौन से resources जोड़े जाएँ, और मॉडल उन्हें context के रूप में पढ़ता है।
Prompts शॉर्टकट मेन्यू जैसे हैं। सर्वर "इस हफ़्ते के टिकट्स का सारांश बनाएँ" जैसा सेव किया हुआ टेम्पलेट दे सकता है, और आप निर्देश खुद टाइप करने के बजाय उसे चुन लेते हैं।
अंदर से, MCP मैसेज JSON-RPC 2.0 का इस्तेमाल करते हैं, जो एक सादा टेक्स्ट फ़ॉर्मेट है और कहता है "इस मेथड को इन आर्गुमेंट्स के साथ कॉल करें।" इन मैसेज को ले जाने के दो आम तरीके हैं:
एक टूल कॉल कुछ इस तरह दिखती है:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "city": "Lisbon" }
}
}
उस मैसेज में कोई जादू नहीं है। यह एक टूल का नाम और कुछ आर्गुमेंट्स है। किसी ऐप में लोकल सर्वर जोड़ना आम तौर पर उतना ही सीधा होता है, बस कुछ लाइनों की कॉन्फ़िगरेशन, जो बताती है कि कौन सा प्रोग्राम शुरू करना है:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Documents"]
}
}
}
यह एंट्री AI को सिर्फ़ एक फ़ोल्डर तक पहुँच देती है, और कुछ नहीं।
मान लीजिए आप एक ऐसे ऐप में, जो डेटाबेस सर्वर से जुड़ा है, पूछते हैं, "मेरे कौन से इनवॉइस की अवधि निकल चुकी है?" तब क्या होता है, देखें।
💡 ध्यान देने योग्य बात: मॉडल आपके डेटाबेस को सीधे नहीं छूता। वह केवल अनुरोध करता है, और यह सर्वर तय करता है कि क्या अनुमति है। यही बँटवारा MCP को बिज़नेस सेटिंग में काम करने लायक बनाता है।
अब हज़ारों MCP सर्वर मौजूद हैं, जो टूल्स के पीछे की कंपनियों द्वारा बनाए गए आधिकारिक सर्वरों से लेकर छोटे कम्युनिटी प्रोजेक्ट्स तक हैं। चार श्रेणियाँ इनका दायरा दिखाती हैं।
रेफ़रेंस filesystem server AI को आपके चुने हुए फ़ोल्डरों के भीतर फ़ाइलें पढ़ने, खोजने और बदलने देता है। उसे अपने बिखरे डाउनलोड फ़ोल्डर का नाम तारीख के हिसाब से बदलने को कहें, या नोट्स के ढेर से किसी क्लाइंट के नाम का हर ज़िक्र निकालने को कहें, तो वह एक-एक फ़ाइल करके मेहनत का काम कर देता है।
डेवलपर्स MCP के पहले भारी उपयोगकर्ता थे। एक GitHub सर्वर इश्यू पढ़ सकता है और pull request खोल सकता है। एक डेटाबेस सर्वर केवल-पढ़ने वाली क्वेरी चला सकता है। इन दोनों से जुड़ा कोडिंग असिस्टेंट फ़ेल होने वाला टिकट ढूँढ सकता है, संबंधित कोड पढ़ सकता है, और विंडो के बीच आपको कुछ कॉपी न करना पड़े, इसलिए सीधे एक फ़िक्स सुझा सकता है।
Playwright पर बना ब्राउज़र ऑटोमेशन सर्वर AI को एक पेज खोलने, किसी फ़ॉर्म में क्लिक करने, और यह बताने देता है कि क्या टूटा। डिज़ाइन और प्रोजेक्ट टूल्स भी अपने सर्वर प्रकाशित करते हैं, ताकि कोई असिस्टेंट लेआउट पढ़ सके या टास्क बोर्ड अपडेट कर सके।
क्रिएटिव काम MCP पर बहुत अच्छी तरह फ़िट बैठता है, क्योंकि जनरेशन एक टूल कॉल है, जिसका साफ़ इनपुट (एक प्रॉम्प्ट) और साफ़ आउटपुट (एक फ़ाइल) होता है। PicassoIA अपने इमेज और वीडियो मॉडल के लिए MCP कनेक्शन देता है, जिनमें PicassoIA Image और PicassoIA Image Editor Pro शामिल हैं। कनेक्ट होने के बाद, कोई AI ऐप टूल्स की एक छोटी सूची देखता है:
| टूल | यह क्या करता है |
|---|---|
generate_image | एक इमेज जॉब शुरू करता है और ID लौटाता है |
edit_image | टेक्स्ट निर्देश से मौजूदा इमेज बदलता है |
get_generation | जॉब की जाँच करता है और तैयार फ़ाइलों के URL लौटाता है |
cancel_generation | चल रहे जॉब को रोकता है |
यह उदाहरण बताता है कि टूल डिस्क्रिप्शन क्यों मायने रखते हैं। इमेज जॉब में थोड़ा समय लगता है, इसलिए generate_image तुरंत तस्वीर नहीं लौटाता। वह एक job ID लौटाता है। AI को विवरण पढ़कर यह समझना होता है, और थोड़ी देर बाद get_generation कॉल करके नतीजा लेना होता है। इस क्रम के लिए किसी ने स्क्रिप्ट नहीं लिखी। मॉडल ने यह टूल्स की सूची से खुद समझा। वीडियो टूल्स भी यही submit-then-check पैटर्न अपनाते हैं, और एक अकाउंट एक साथ 5 जॉब तक चला सकता है। चूँकि कनेक्शन स्टैंडर्ड का पालन करता है, वही टूल्स MCP सपोर्ट करने वाले किसी भी ऐप से चलते हैं, और हर एक के लिए अलग इंटीग्रेशन की ज़रूरत नहीं पड़ती।
लोग अक्सर पूछते हैं कि क्या MCP APIs की जगह ले लेता है। ऐसा नहीं है। ज़्यादातर MCP सर्वर अंदर से एक सामान्य API को कॉल करते हैं। MCP वह परत है, जो उस API को मॉडल के लिए उपयोगी बनाती है।
| सामान्य API | MCP | |
|---|---|---|
| किसके लिए बना है | कोड लिखने वाले डेवलपर्स | कार्रवाई चुनने वाले AI मॉडल |
| क्षमताएँ कैसे बताई जाती हैं | लोगों के लिए लिखा गया दस्तावेज़ | टूल की सूची, जिसे मॉडल रन टाइम पर पढ़ता है |
| नई क्षमता जोड़ना | नया इंटीग्रेशन कोड लिखना | दूसरा सर्वर कनेक्ट करना |
| AI ऐप्स में पुन: उपयोग | हर ऐप को अपना इंटीग्रेशन चाहिए | कोई भी MCP क्लाइंट कनेक्ट हो सकता है |
| मैसेज फ़ॉर्मेट | हर सेवा का अलग | एक साझा फ़ॉर्मेट |
Function calling मॉडल की एक क्षमता है: फ़ंक्शनों की सूची दिए जाने पर, वह उनमें से एक को चलाने का संरचित अनुरोध लौटा सकता है। MCP उस क्षमता के आसपास का ढाँचा है। यह तय करता है कि फ़ंक्शन कहाँ से आते हैं, उन्हें कैसे बताया जाता है, और कॉल उस तक कैसे पहुँचती है जो उसे चलाता है।
💡 याद रखने का सरल तरीका: function calling मॉडल का बटन दबाने का फ़ैसला है। MCP हर बटन के पीछे लगी मानक वायरिंग है।
MCP सपोर्ट ज़्यादातर होस्ट ऐप में रहता है, इसलिए एक ही सर्वर अलग-अलग मॉडलों के साथ काम कर सकता है। जो बदलता है, वह यह है कि कोई मॉडल सही टूल कितनी अच्छी तरह चुनता है और इनपुट कितनी अच्छी तरह भरता है। PicassoIA के ये लैंग्वेज मॉडल टूल-भारी काम के लिए आम पसंद हैं:
| मॉडल | उसके पेज पर बताया गया | किसके लिए अच्छा है |
|---|---|---|
| Claude Sonnet 5 | कोडिंग कार्यों को स्वचालित करना | कोड और रिपॉज़िटरी का काम |
| GPT 5.6 Sol | जटिल कोडिंग कार्यों को हल करना | कठिन, कई चरणों वाले कोडिंग कार्य |
| Gemini 3.5 Flash | तेज़ चैट, कोड और इमेज | त्वरित खोज और हल्का टूल उपयोग |
| Kimi K2.6 | AI एजेंट बनाना और कोड लिखना | एजेंट-शैली के वर्कफ़्लो |
ऐसा मॉडल खोजें जो निर्देशों का ध्यान से पालन करे और साफ़-सुथरे, सही फ़ॉर्मेट वाले इनपुट दे। छोटे टूल सेट से शुरू करें, क्योंकि मिलते-जुलते टूल्स की लंबी सूची किसी भी मॉडल को उलझा सकती है। सरल खोज के लिए तेज़ मॉडल इस्तेमाल करें, और भारी मॉडल उन कामों के लिए बचाकर रखें जिनमें कई टूल्स एक के बाद एक चलाने होते हैं।
AI को असली टूल्स देने का मतलब है उसे असली पहुँच देना। यही इसका मकसद है, और यही सावधान रहने का कारण भी।
कोई टूल वेब पेज, ईमेल या साझा दस्तावेज़ से टेक्स्ट ला सकता है। अगर किसी ने उस टेक्स्ट में छिपे निर्देश डाले हैं, तो मॉडल उन्हें आदेश मान सकता है। उदाहरण के लिए, कोई वेब पेज एक छिपी लाइन रख सकता है जो असिस्टेंट से अपने निर्देश अनदेखा करके आपकी फ़ाइलें कहीं और भेजने को कहे। टूल जो कुछ भी लौटाता है, उसे भरोसे के लायक न मानें, हर टूल को क्या करने की अनुमति है उसे सीमित करें, और जो कुछ भेजता, मिटाता या खर्च करता है उसके लिए मंज़ूरी वाले प्रॉम्प्ट चालू रखें।
MCP क्या करता है, यह महसूस करने का सबसे तेज़ तरीका है कि आप AI को आपके लिए टूल इस्तेमाल करते हुए देखें। किसी MCP-सक्षम ऐप को अपने Picasso IA अकाउंट से कनेक्ट करें (कनेक्शन सेटिंग्स आपके अकाउंट एरिया में picassoia.com/en/mcp/accounts पर हैं), फिर सादी भाषा में एक इमेज माँगें। आप असिस्टेंट को जॉब सबमिट करते, उसकी स्थिति जाँचते और तैयार फ़ाइल लौटाते देखेंगे, यानी पूरा प्रोटोकॉल अमल में।
ऐसे प्रॉम्प्ट आज़माएँ:
इनमें से हर एक ऊपर की तालिका के किसी टूल से जुड़ता है, और हर एक दिखाता है कि MCP एक वाक्य को कार्रवाई में कैसे बदलता है। जब आप देखना चाहें कि प्लेटफ़ॉर्म और क्या देता है, तो picassoia.com/en/all-models पर हर मॉडल ब्राउज़ करें, फिर लौटकर अपने असिस्टेंट को इस्तेमाल करने के लिए एक नया टूल दें।
अपनी भाषा चुनें
