2026 में, किसी कोड एजेंट को Obsidian वॉल्ट से जोड़ना अब कोई विचित्र विचार नहीं रहा। यह शायद, इस समय मौजूद सबसे कम आंका गया नॉलेज मैनेजमेंट सेटअप है। और फिर भी, लगभग हर कोई जो ऐसा करता है, पहले चरण पर ही अटका रहता है: Claude Code को एक फ़ोल्डर पर इंगित करना और उसे markdown पढ़ने और लिखने देना। यह काम करता है। लेकिन यह केवल शुरुआत है, और यह समझना कि अगला कदम, MCP, क्यों मायने रखता है, पहले यह समझने की आवश्यकता है कि हमारे पास पहले से क्या है और यह कहाँ टूटता है।
MCP के बिना पहले से क्या संभव है
जब Claude Code सीधे किसी वॉल्ट पर इंगित करता है, तो यह फ़ाइल सिस्टम एक्सेस वाले किसी भी एजेंट की तरह काम करता है: यह फ़ोल्डर संरचना पढ़ता है, प्रासंगिक सामग्री का पता लगाने के लिए grep और glob लागू करता है, और आपके द्वारा दिए गए कन्वेंशन (YAML frontmatter, wikilinks, सामग्री प्रकार के अनुसार फ़ोल्डर पदानुक्रम) का सम्मान करते हुए markdown फ़ाइलें लिखता या संपादित करता है। यहाँ कोई प्लगइन, कोई डेटाबेस, कोई API नहीं है: बस सादा टेक्स्ट और एक एजेंट जो समझदारी से इसे पढ़ना और लिखना जानता है।
परिणाम, जब सिस्टम अच्छी तरह से डिज़ाइन किया गया हो, तो दिखने से कहीं अधिक शक्तिशाली होता है। एक वास्तविक, काल्पनिक नहीं, संदर्भ के रूप में: एक वॉल्ट जिसका मैं बारीकी से अनुसरण करता हूँ, इसी विधि से, 78 कच्चे स्रोतों (पेपर, लेख, दस्तावेज़) से 180 आपस में जुड़े विकी पेजों (उनमें से 83 कॉन्सेप्ट पेज, बाकी टूल, लोग, तुलनाएँ और स्रोत सारांश) तक पहुँच गया है, सभी क्रॉस-रेफरेंस के साथ जिन्हें एजेंट स्वयं अपडेट रखता है जब भी नई सामग्री प्रवेश करती है। बिना किसी के एक भी पेज हाथ से लिखे।
प्रत्यक्ष फ़ाइल एक्सेस की सीमा
लेकिन इस मॉडल की एक संरचनात्मक सीमा है, न कि केवल एक प्रदर्शन सीमा। Claude Code को पहले से पता होना चाहिए कि आपका वॉल्ट कैसे व्यवस्थित है: कौन सा फ़ोल्डर अपरिवर्तनीय है, frontmatter कन्वेंशन क्या है, कॉन्सेप्ट कहाँ रहते हैं बनाम टूल। प्रत्येक नया वॉल्ट, व्यवहार में, एक अलग एकीकरण है जिसे सिस्टम प्रॉम्प्ट में शुरू से समझाया जाना चाहिए।
इसके अलावा, एजेंट किसी वॉल्ट से यह नहीं पूछ सकता कि "तुम क्या करने में सक्षम हो?" यह केवल वही पढ़ सकता है जो पहले से मौजूद है और सामान्य फ़ाइल ऑपरेशन (पढ़ना, लिखना, टेक्स्ट द्वारा खोज) निष्पादित कर सकता है। इसके लिए कोई तरीका नहीं है कि इसे कोई व्युत्पन्न ऑपरेशन उजागर किया जाए (मुझे इस नोट का बैकलिंक ग्राफ़ दो, यह Dataview क्वेरी चलाओ, मुझे बताओ कौन से पेज अनाथ हैं) बिना एजेंट के उस तर्क को हर बार शुरू से फिर से बनाए, रास्ते में संदर्भ और त्रुटि मार्जिन बर्बाद करते हुए।
MCP क्या हल करता है, गहराई से
MCP (Model Context Protocol) वह खुला मानक है जिसे Anthropic ने नवंबर 2024 में इसी समस्या को हल करने के लिए लॉन्च किया था: AI मॉडल और बाहरी सिस्टम के बीच एकीकरण। MCP से पहले, यदि N AI सहायकों को M विभिन्न टूल या डेटा स्रोतों से जुड़ने की आवश्यकता होती थी, तो N×M कस्टम एकीकरण की आवश्यकता होती थी: जब एक एप्लिकेशन Notion का समर्थन करना चाहता था, तो वह इसे शुरू से बनाता था; जब कोई दूसरा वही चाहता था, तो वह इसे फिर से शुरू से बनाता था। MCP उस N×M को N+M में बदल देता है: सामान्य क्लाइंट बनाए जाते हैं (प्रति एप्लिकेशन एक) और सामान्य सर्वर (प्रति सिस्टम एक), और कोई भी क्लाइंट बिना कस्टम एकीकरण के किसी भी सर्वर से बात कर सकता है।
सही उपमा USB-C है: पहले, प्रत्येक परिधीय का अपना कनेक्टर होता था; USB-C के साथ, डिवाइस को केवल प्रोटोकॉल बोलना होता है, बिना इस पर ध्यान दिए कि वह Mac या PC से जुड़ा है या नहीं।
आर्किटेक्चर की तीन परतें हैं। होस्ट उपयोगकर्ता-सामना वाला एप्लिकेशन है (Claude Code, Claude Desktop, या एक कस्टम एजेंट) जो अनुरोधित चीज़ की व्याख्या करता है और तय करता है कि क्या उसे बाहरी डेटा या टूल की आवश्यकता है। क्लाइंट होस्ट के अंदर रहता है और प्रत्येक सर्वर के साथ 1:1 कनेक्शन प्रबंधित करता है, अमूर्त अनुरोधों को ठोस MCP संदेशों में अनुवाद करता है और सत्र जीवनचक्र का प्रबंधन करता है। सर्वर प्रोटोकॉल को एक वास्तविक सिस्टम, इस मामले में एक Obsidian वॉल्ट, से जोड़ता है, MCP अनुरोधों को मूल संचालन में अनुवाद करता है।
दो गुण इसे एक साधारण अमूर्तन परत से अधिक बनाते हैं। पहला है गतिशील क्षमता खोज: कनेक्ट होने पर, क्लाइंट सर्वर से पूछता है कि वह क्या करने में सक्षम है, और सर्वर वास्तविक समय में जवाब देता है। यदि कल सर्वर कोई नया फ़ंक्शन जोड़ता है, तो क्लाइंट को उसका उपयोग करने के लिए पुनः प्रोग्राम करने की आवश्यकता नहीं है। दूसरा है बुद्धिमत्ता और डेटा के बीच वियुग्मन: जो कोई Obsidian के लिए MCP सर्वर बनाता है, उसे यह जानने की आवश्यकता नहीं है कि कौन सा मॉडल इसका उपयोग करेगा, और जो कोई एजेंट बनाता है, उसे हर बार मॉडल बदलने पर अपना एकीकरण फिर से बनाने की आवश्यकता नहीं है।
एक MCP सर्वर तीन प्रकार के प्रिमिटिव उजागर करता है। Resources वह डेटा है जिसे मॉडल पढ़ सकता है लेकिन संशोधित नहीं कर सकता: एक नोट की सामग्री, खोज परिणाम, बैकलिंक ग्राफ़। Tools वे क्रियाएँ हैं जिन्हें मॉडल सक्रिय रूप से आमंत्रित कर सकता है: एक नोट बनाना, एक टैग अपडेट करना, एक संरचित क्वेरी निष्पादित करना। Prompts पुन: प्रयोज्य और पैरामीटरीकृत निर्देश टेम्पलेट हैं, उदाहरण के लिए "इस स्रोत का सारांश दें और संबंधित विकी पेज उत्पन्न करें" एक नामित ऑपरेशन के रूप में, न कि मुक्त पाठ के रूप में जिसे हर बार फिर से लिखना पड़ता है।
विशेष रूप से Obsidian पर लागू
Obsidian के लिए विशेष रूप से बनाए गए MCP सर्वर पहले से ही इसके ओपन-सोर्स इकोसिस्टम में मौजूद हैं, जो आमतौर पर Obsidian के स्वयं के स्थानीय REST API प्लगइन द्वारा समर्थित होते हैं, जो वॉल्ट पर सिमैंटिक सर्च, नोट निर्माण और संपादन, टैग और मेटाडेटा प्रबंधन, या लिंक ग्राफ़ पढ़ने जैसे ऑपरेशन उजागर करते हैं, बिना एजेंट को पहले से सटीक फ़ोल्डर संरचना जानने की आवश्यकता के।
व्यवहार में जो बदलता है वह सूक्ष्म लेकिन महत्वपूर्ण है: MCP के बिना, Claude Code आपके वॉल्ट को उन नियमों से प्रबंधित करता है जो आपने उसे एक-एक करके समझाए थे। MCP के साथ, आपका वॉल्ट एक उपकरण बन जाता है जिसे Claude Code बिल्कुल उसी तरह संचालित कर सकता है जैसे वह किसी API या डेटाबेस को संचालित करता है, कनेक्शन के समय अपनी क्षमताओं की खोज करता है, न कि उन्हें पहले से याद करके। और वही कनेक्शन किसी भी अन्य MCP क्लाइंट के लिए काम करता है, न कि केवल Claude Code के लिए: वही सर्वर किसी दूसरे एप्लिकेशन में, एक अलग एजेंट को फ़ीड कर सकता है, बिना Obsidian की ओर से कोड की एक पंक्ति को छुए।
व्यावहारिक ढाँचा: परिपक्वता के तीन स्तर
यह जानने के लिए कि आपका अपना सेटअप कहाँ है, मैं इस ढाँचे का उपयोग करता हूँ:
स्तर 0: संदर्भ का मैन्युअल कॉपी-पेस्ट। हर बातचीत शुरू से शुरू होती है; उपयोगकर्ता अपने नोट्स के प्रासंगिक अंशों को चैट में चिपकाता है। यह विशिष्ट कार्यों के लिए काम करता है, लेकिन स्केल नहीं होता।
स्तर 1: प्रत्यक्ष फ़ाइल एक्सेस वाला एजेंट। यही वह जगह है जहाँ आज अधिकांश Claude Code + Obsidian सेटअप हैं, जिसमें इस लेख का 78→180 पेज का उदाहरण भी शामिल है। एजेंट सीधे वॉल्ट को पढ़ता और लिखता है, एक निर्देश फ़ाइल में समझाए गए कन्वेंशन का पालन करते हुए। यह पहले से ही स्तर 0 से काफी अधिक शक्तिशाली है, और एक एकल एजेंट द्वारा प्रबंधित एकल वॉल्ट के लिए, यह लंबे समय तक पर्याप्त हो सकता है।
स्तर 2: MCP के माध्यम से जुड़ा एजेंट। वॉल्ट को गतिशील रूप से खोजे जाने योग्य क्षमताओं वाले सर्वर के रूप में उजागर किया जाता है, जो विभिन्न मॉडलों और अनुप्रयोगों में पुन: प्रयोज्य है। यह तब समझ में आता है जब एक से अधिक एजेंट, एक से अधिक वॉल्ट, या फ़ाइल-दर-फ़ाइल पढ़ने और लिखने से परे ऑपरेशन को उजागर करने की आवश्यकता होती है।
AI-प्रबंधित वॉल्ट का लाभ उठाने के लिए सीधे स्तर 2 पर जाना आवश्यक नहीं है। स्तर 1 पहले से ही कोई सिस्टम न होने की तुलना में एक वास्तविक छलांग है। लेकिन यह समझना कि MCP क्या हल करता है, यह समझना है कि यह कहाँ जा रहा है: "मेरा AI मेरे नोट्स पढ़ सकता है" से "मेरा ज्ञान एक ऐसी प्रणाली है जिसे कोई भी AI संचालित कर सकता है।"
आपका अपना सेटअप अभी किस स्तर पर है? मुझे टिप्पणियों में बताएं। यदि पर्याप्त रुचि है, तो अगला लेख Obsidian के लिए अपना पहला MCP सर्वर सेट करने की चरण-दर-चरण मार्गदर्शिका होगी।
और यदि यह आपके लिए उपयोगी रहा है, तो मुझे फ़ॉलो करें @chesny
यह एजेंटों के बारे में एक श्रृंखला का पहला लेख है जो सिस्टम को पढ़ना बंद कर देते हैं और उन्हें संचालित करना शुरू कर देते हैं।
