पिछले अध्याय में हमने दिमाग (LLM) से टूल जोड़कर खुद लूप घुमाने वाला न्यूनतम एजेंट चलाया। उस अनुभव से आपको समझ आ गया होगा — एजेंट की असली ताक़त "वह किन औज़ारों से जुड़ा है" इससे लगभग तय होती है। इस अध्याय में, उन औज़ारों को हर बार खुद बनाने की थकान से निकलकर, MCP (Model Context Protocol) नाम के साझा मानक से बाहरी टूल और डेटा से मानक तरीके से जुड़ना सीखेंगे। MCP का जन्म Claude में हुआ, और अब यह पूरी इंडस्ट्री में फैलकर कनेक्शन का मानक बनता जा रहा है।
लक्ष्य है "औज़ार खुद बनाए बिना, मानक मानक से सुरक्षित रूप से जोड़ना"
टूल कनेक्शन ही एजेंट का दिल क्यों है
LLM खुद, कितना भी समझदार हो, बस "शब्द गढ़ना" ही कर सकता है। ताज़ा स्टॉक जानना हो या फ़ाइल में एक पंक्ति लिखनी हो, बाहरी दुनिया को छूने का ज़रिया न हो तो नामुमकिन है। एजेंट "पता लगाओ, अमल करो, जाँचो" वाला लूप घुमा पाता है, इसकी वजह ही यह है कि उसके पास बाहर पर असर डालने वाले टूल (औज़ार) हैं।
यानी, एजेंट की क्षमता की ऊपरी सीमा, जुड़े हुए औज़ारों की गुणवत्ता और गिनती से तय होती है। एक ही LLM हो, फिर भी सिर्फ़ कैलकुलेटर रखने वाले एजेंट और डेटाबेस, खोज, फ़ाइल, अंदरूनी API से जुड़े एजेंट — दोनों की क्षमताओं में ज़मीन-आसमान का फ़र्क़ है। दिमाग को और बढ़िया बदलने के बजाय, अच्छे औज़ार ठीक से जोड़ने से महसूस होने वाली क्षमता कहीं ज़्यादा बढ़ती है — यह कोई अनोखी बात नहीं।
💡 "समझदार होना" से ज़्यादा "औज़ार पूरे होना"। बेहतरीन इंसान भी, औज़ार-पेटी खाली हो तो कुछ नहीं कर सकता। एजेंट डेवलपमेंट का ज़्यादातर समय असल में "कौन-सा औज़ार, कैसे सुरक्षित रूप से देना है" के डिज़ाइन में लगता है। यह अध्याय उसका केंद्र है।
सादी टूल डेफ़िनिशन की सीमा
पिछले अध्याय में, हमने टूल अपने हाथ से डिफ़ाइन किया। फ़ंक्शन लिखा, नाम-आर्ग्युमेंट-विवरण LLM को दिया, और कॉल आने पर चलाकर नतीजा लौटाया — यह बहाव अपने आप में सही है, और आज भी बुनियाद है। समस्या यह है कि इसे हर बार, हर औज़ार के लिए, हर प्रोजेक्ट के लिए दोबारा बनाना पड़ता है।
जैसे "डेटाबेस खोजने वाला टूल" ही लें। कनेक्शन का काम लिखो, क्वेरी बनाओ, नतीजा साफ़-सुथरा करो, एरर सँभालो, प्रमाणीकरण जानकारी सुरक्षित रखो… यह पूरा सेट, आपके प्रोजेक्ट में भी, बगल की टीम में भी, दूसरी भाषा में भी, हर कोई अलग-अलग बना रहा है। एक ही औज़ार को, दुनिया भर के डेवलपर बार-बार पहिये का पुनराविष्कार करके बना रहे हैं — यही सादी टूल डेफ़िनिशन की हक़ीक़त है।
किसी एक प्रोजेक्ट के लिए लिखा टूल, उसी फ़्रेमवर्क और भाषा से बँधा रहता है, कहीं और ले जाना मुश्किल।
M तरह के टूल को N एजेंट प्लेटफ़ॉर्म से जोड़ें, तो सिद्धांत रूप में N×M तरह के कनेक्शन कोड चाहिए।
जुड़े हुए स्रोत की स्पेसिफ़िकेशन बदले, हर बार जगह-जगह बिखरे अपने-बनाए टूल अलग-अलग सुधारने पड़ते हैं।
यह उस ज़माने जैसा है जब हर पेरिफ़ेरल के लिए अलग ख़ास केबल चाहिए होती थी। प्रिंटर के लिए प्रिंटर वाला, माउस के लिए माउस वाला सॉकेट — जितने उपकरण बढ़ें, जोड़ने के तरीके उतने फूलते जाएँ। "एक साझा सॉकेट" हो तो यह पूरी झंझट एक साथ मिट जाती है। यहीं MCP आता है।
MCP क्या है — टूल कनेक्शन का साझा मानक
MCP (Model Context Protocol), AI और बाहरी टूल-डेटा को मानक तरीके से जोड़ने के लिए एक खुला (ओपन) मानक है। Anthropic ने इसे 2024 के आख़िर में Claude के लिए जारी किया, और उसके बाद तरह-तरह के AI टूल व सेवाओं ने इसे अपनाया। 2026 में यह वेंडर की सरहद पार कर व्यापक रूप से अपनाया जा रहा है, और एक तटस्थ संचालन व्यवस्था के तहत बढ़ते हुए इंडस्ट्री मानक बन गया है। यह किसी एक कंपनी का उत्पाद नहीं, बल्कि कोई भी लागू कर सके ऐसा साझा स्पेसिफ़िकेशन है — यह अहम है।
MCP की सोच को एक वाक्य में कहें तो, "AI टूल कनेक्शन का USB"। जैसे USB आने पर किसी भी कंपनी का पेरिफ़ेरल एक ही सॉकेट से चलने लगा, वैसे ही MCP-समर्थित औज़ार, MCP-समर्थित किसी भी एजेंट में "जोड़ो तो चल पड़े"। बनाने वाला और इस्तेमाल करने वाला एक ही तयशुदा नियम मानें, तो N×M का जोड़-नरक "N+M" में सिमट जाता है।
आपका बनाया एजेंट, या Claude जैसे ऐप यहाँ आते हैं। "अभी कौन-से औज़ार जुड़े हैं?" — यह सर्वर से पूछकर, ज़रूरी टूल बुलाने वाला पक्ष।
फ़ाइल संचालन, DB खोज, SaaS कनेक्शन आदि क्षमताओं को "टूल" के रूप में एकसाथ सार्वजनिक करने वाला पक्ष। एक सर्वर कई टूल रख सकता है।
दोनों एक तयशुदा तरीके से बातचीत करते हैं। क्लाइंट जुड़ते ही, पहले "इस्तेमाल करने योग्य टूल की सूची" और "हर एक का विवरण-आर्ग्युमेंट" सर्वर से लेता है। LLM उस सूची को देखकर, लक्ष्य के मुताबिक़ टूल चुनकर बुलाता है, और सर्वर उसे चलाकर नतीजा लौटाता है — यह आना-जाना, हर औज़ार के अलग क्रियान्वयन के बिना बन जाता है, यही MCP का दिल है।
क्लाइंट → सर्वर :"इस्तेमाल करने योग्य टूल बताओ" सर्वर → क्लाइंट:"search_docs / read_file / query_db ये तीन, विवरण ऐसा है" LLM का निर्णय :"query_db को, आर्ग्युमेंट {sql:\"...\"} से बुलाऊँ" क्लाइंट → सर्वर :"query_db चलाओ" सर्वर → क्लाइंट:"नतीजा यह पंक्ति-डेटा है"
सार्वजनिक करने के मुख्यतः 2 तरीके हैं। अपनी मशीन पर प्रोसेस के रूप में चलाने वाला लोकल प्रकार, और नेटवर्क के पार से जुड़ने वाला रिमोट प्रकार। लोकल अपनी फ़ाइलों या डेवलपमेंट DB के लिए, और रिमोट टीम में साझा किए जाने वाले SaaS कनेक्शन आदि के लिए उपयुक्त है। दोनों में "टूल सूची लेकर बुलाओ" वाला तयशुदा नियम एक ही है, और क्लाइंट की तरफ़ बरताव में लगभग कोई फ़र्क़ नहीं।
📖 पहले पूरा खाका। MCP का उद्भव, शब्दावली और समर्थन-स्थिति को आसानी से समझाने वाला "MCP क्या है" व्याख्या लेख पहले पढ़ लें, तो इस अध्याय की बात झट समझ आएगी। स्पेसिफ़िकेशन की बारीकियाँ और वर्शन तेज़ी से बदलते हैं, इसलिए लागू करने से पहले आधिकारिक दस्तावेज़ में नवीनतम ज़रूर देखें।
MCP सर्वर इस्तेमाल करना और बनाना
MCP की सबसे बढ़िया बात यह है कि दुनिया में पहले से सार्वजनिक सर्वरों को ज्यों का त्यों इस्तेमाल कर सकते हैं। अक्सर काम आने वाले औज़ार, आमतौर पर कोई न कोई MCP सर्वर के रूप में तैयार कर चुका है। अपने बनाए एजेंट से जोड़ दें, तो पहिये का पुनराविष्कार किए बिना क्षमता एकदम से बढ़ जाती है।
तयशुदा फ़ोल्डर का पढ़ना-लिखना। दस्तावेज़ पढ़वाने, या नतीजा फ़ाइल में लिखवाने की बुनियाद।
SQL चलाना या स्कीमा देखना। "हिसाब लगाओ" के जवाब में, असली डेटा से पूछकर जवाब दे पाना।
वेब खोज या अंदरूनी नॉलेज खोज। ताज़ा जानकारी या आधार खींच लाने वाला "पता लगाने का हाथ" बनता है।
टास्क प्रबंधन, चैट, स्टोरेज आदि। मौजूदा कारोबारी टूल को एजेंट के हाथ-पैर बना पाते हैं।
जोड़ने का तरीका अपने आप में सरल है। जिस सर्वर को इस्तेमाल करना हो उसे शुरू करें (या URL बताएँ), और क्लाइंट की सेटिंग में सर्वर की जगह और प्रमाणीकरण जानकारी रजिस्टर कर दें — बस। इसके बाद एजेंट जुड़ते समय टूल सूची लेता है, और ज़रूरत के मुताबिक़ बुलाता है। आपको "DB खोज टूल के भीतर का हिस्सा" लिखने की ज़रूरत नहीं। दिए गए टूल को, लक्ष्य के हिसाब से जोड़-मिलाना ही अब आपका काम है।
⚠️ "सुविधाजनक है इसलिए सब जोड़ दो" ठीक नहीं। हर एक सर्वर जोड़ने पर, टूल की गिनती जितने विवरण LLM को देने पड़ते हैं वे बढ़ते हैं, निर्णय बिखरता है, और गलत संचालन की गुंजाइश भी फैलती है। उस एजेंट के लक्ष्य के लिए सचमुच ज़रूरी औज़ार ही चुनकर जोड़ना नियम है। बहुत ज़्यादा औज़ार उल्टा सटीकता घटा देते हैं।
अपना सर्वर भी बना सकते हैं
जिस औज़ार का बना-बनाया सर्वर न हो — अंदरूनी ख़ास API, विशेष कारोबारी लॉजिक आदि — उसके लिए बस खुद MCP सर्वर लिख लें, इतना ही। यहीं MCP की ख़ूबी है — एक बार सर्वर के रूप में सार्वजनिक कर दिया, तो समर्थन करने वाले किसी भी एजेंट से एक जैसा इस्तेमाल किया जा सकता है। किसी एक प्रोजेक्ट के लिए बनाया औज़ार, अगले प्रोजेक्ट में भी, टीम के दूसरे एजेंट में भी, दोबारा लिखे बिना काम आ जाता है।
सर्वर बनाने के भीतर का हिस्सा है "जो क्षमता देनी है उसे टूल के रूप में डिफ़ाइन करो, नाम-आर्ग्युमेंट-विवरण घोषित करो, और बुलाए जाने पर काम चलाकर नतीजा लौटाओ"। पिछले अध्याय में लिखी सादी टूल डेफ़िनिशन जैसी ही सोच है, पर आउटपुट "किसी ख़ास एजेंट" के बजाय "MCP नाम के साझा सॉकेट" की ओर होता है — यही निर्णायक फ़र्क़ है। बनाने की मेहनत एक बार, और इस्तेमाल जितनी बार चाहें।
🛠 क्रियान्वयन में उतरना हो तो। Claude से एजेंट या टूल कनेक्शन बनाने का ठोस कोड, Claude Agent SDK परिचय में व्यावहारिक रूप से है। SDK में MCP सर्वर सँभालने की व्यवस्था मौजूद है, और बने-बनाए सर्वर का कनेक्शन हो या अपना बनाना, आधिकारिक दस्तावेज़ के तरीके पर आगे बढ़ सकते हैं।
कौन-से टूल, कैसे दें
औज़ार "जोड़ पाने" के बाद, अगला सवाल है "क्या, कैसे देना है"। यह एजेंट की गुणवत्ता और सुरक्षा तय करने वाला डिज़ाइन का अहम बिंदु है, और अगले अध्यायों की बुनियाद भी बनता है। 3 सिद्धांत पकड़ लें।
उस टास्क के लिए ज़रूरी औज़ार व दायरा ही दें। "बस पढ़ने से काम बन जाए तो लिखने की अनुमति मत दो"। DB हो तो सिर्फ़-पढ़ने वाला सीमित खाता, फ़ाइल हो तो सिर्फ़ लक्ष्य फ़ोल्डर — यह नियम है।
LLM टूल के विवरण के भरोसे ही तय करता है कि इस्तेमाल करना है या नहीं। "क्या करता है, कब इस्तेमाल करना है, आर्ग्युमेंट का मतलब, कब इस्तेमाल नहीं करना" ठोस रूप में लिखें। धुँधला विवरण दुरुपयोग पैदा करता है।
लिखना, मिटाना, चार्जिंग, कमांड चलाना जैसे वापस न लौटाए जा सकने वाले संचालन को पढ़ने वालों के बराबर मत रखें। चलाने से पहले पुष्टि, लक्ष्य की सीमा, और रिकॉर्ड ज़रूर साथ लगाएँ।
ख़ासकर ③ अहम है। "पता लगाने" वाले औज़ार (खोज, संदर्भ, पढ़ना) गलती से बुलाए जाएँ तो बड़ा नुक़सान कम ही होता है। दूसरी ओर "बदलने" वाले औज़ार (लिखना, मिटाना, भेजना, चलाना) — एक बार का गलत संचालन वापस न लौटाया जा सकने वाला नतीजा पैदा कर देता है। पढ़ने वाले और लिखने वाले को होशपूर्वक अलग करना, और दूसरे पर गार्ड की परतें चढ़ाना — यही नियम है।
| प्रकार | उदाहरण | जोखिम | देने का ढंग |
|---|---|---|---|
| पढ़ने वाले | खोज, संदर्भ, फ़ाइल पढ़ना | कम (जानकारी सँभालने में सावधानी) | अपेक्षाकृत खुला। दायरा सीमित रखें |
| लिखने वाले | फ़ाइल अपडेट, DB लिखना, भेजना | ऊँचा (वापस लेना मुश्किल) | पुष्टि, सीमा, रिकॉर्ड अनिवार्य |
| चलाने वाले | कमांड चलाना, बाहरी कॉल, चार्जिंग | सर्वाधिक (बेकाबू होना, दुरुपयोग का द्वार) | सिद्धांततः गार्ड + इंसानी मंज़ूरी बीच में |
🔒 यह सब अध्याय 6 में विस्तार से करेंगे। ख़तरनाक टूल का नियंत्रण, प्रॉम्प्ट इंजेक्शन से बचाव, और मंज़ूरी-फ़्लो का डिज़ाइन — एजेंट को प्रोडक्शन में उतारते वक़्त ये ऐसे विषय हैं जिन्हें टाला नहीं जा सकता। अध्याय 6 "गार्डरेल और सुरक्षा" में इन्हें एकसाथ देखेंगे, इसलिए इस अध्याय से बस "औज़ारों में जोखिम का फ़र्क़ होता है" वाली समझ साथ ले जाएँ। भरोसा न हो ऐसे MCP सर्वर को यूँ ही न जोड़ना भी एक अहम आदत है।
ब्राउज़र संचालन जैसे उन्नत टूल
औज़ारों में भी, हाल के वर्षों में ख़ासकर चर्चित है ब्राउज़र संचालन। स्क्रीन देखना, लिंक पर जाना, फ़ॉर्म भरना, बटन दबाना — इंसान जो ब्राउज़र में करता है, वह एजेंट को सौंप दें, तो ख़ास API न रखने वाली कई वेब सेवाएँ भी उसके "हाथ-पैर" बन जाती हैं। MCP सर्वर के रूप में ब्राउज़र संचालन देने वाले क्रियान्वयन भी सामने आए हैं, और जोड़ने की मुश्किल घटती जा रही है।
पर, यह सबसे ताक़तवर और सबसे ज़्यादा जोखिम वाले औज़ारों में से एक भी है। स्क्रीन पर लिखे निर्देश को ज्यों का त्यों मान लेने का ख़तरा (गुमराही, झूठी जानकारी), अनचाही क्लिक या भेजना, प्रमाणीकरण जानकारी का उजागर होना — पिछले खंड की "चलाने वाले" वाली सावधानियाँ हूबहू यहाँ लागू होती हैं। पहले देखने, जानकारी लेने जैसे पढ़ने-वाले उपयोग से शुरू करें, और लिखने वाले संचालन पर सावधानी से गार्ड लगाना समझदारी है।
🌐 कहाँ तक सौंपा जा सकता है? ब्राउज़र संचालन एजेंट की व्यावहारिक ताक़त और सीमाओं की, AI ब्राउज़र के कामों को कहाँ तक स्वचालित कर सकता है में ठोस रूप से जाँच की गई है। "जादुई नहीं, पर दायरा सीमित रखें तो व्यावहारिक" — यह दूरी समझ लें तो औज़ार चुनने का निर्णय नहीं डगमगाएगा।
सिर्फ़ ब्राउज़र नहीं, जितना उन्नत औज़ार, उतना ही "क्या हो सकता है" और "क्या घट सकता है" — दोनों बड़े होते जाते हैं। जितना ताक़तवर औज़ार दें, उतनी ही सावधानी से अनुमति-विवरण-गार्ड के 3 सिद्धांत — यही संदेश इस अध्याय में बार-बार दोहराया गया है।
- एजेंट की क्षमता जुड़े हुए औज़ारों की गुणवत्ता और गिनती से तय होती है। दिमाग से ज़्यादा औज़ार का डिज़ाइन असर करता है।
- सादी टूल खुद बनाना दोबारा इस्तेमाल में मुश्किल, और N×M का जोड़-नरक बन जाता है। एक साझा सॉकेट चाहने लगते हैं।
- MCP AI और बाहरी टूल को मानक तरीके से जोड़ने वाला खुला मानक है। क्लाइंट (इस्तेमाल करने वाला) और सर्वर (देने वाला) एक ही तयशुदा नियम से बात करने वाला "AI का USB"।
- बने-बनाए MCP सर्वर (फ़ाइल/DB/खोज/SaaS) को जोड़कर इस्तेमाल किया जा सकता है, और अपने ख़ास औज़ार को अपना सर्वर बनाकर दोबारा काम में लाया जा सकता है।
- देने के सिद्धांत हैं ①अनुमति न्यूनतम ②विवरण की गुणवत्ता ③ख़तरनाक औज़ार अलग। ब्राउज़र संचालन जैसे ताक़तवर औज़ार जितने ताक़तवर, उतनी सावधानी।
औज़ार जुटाना समझ लेने पर, अगला चरण है "एजेंट को बढ़ाना"। एक एजेंट में न सँभलने वाला काम, कई एजेंटों में बाँटकर और तालमेल कराकर हल करने के डिज़ाइन की ओर बढ़ते हैं। अगले अध्याय 4 "मल्टी-एजेंट डिज़ाइन" में, भूमिका-बँटवारा और एजेंटों के बीच सहयोग (A2A) सीखेंगे।