MCP के साथ टूल्स जोड़ना: Codex को बाहरी एक्सेस देना

📚 सीरीज नेविगेशन: पिछला लेख [19 स्मरण शक्ति तंत्र Chronicle] सत्रों के पार जानकारी याद रखने के बारे में था। यह लेख इसके बाहरी संबंधों के बारे में है: Codex डिफ़ॉल्ट रूप से केवल आपके स्थानीय फ़ाइलों और कमांड लाइन तक पहुँच सकता है, यह आपके डेटाबेस, Figma या बाहरी दस्तावेज़ों तक नहीं पहुँच सकता। MCP वह प्रोटोकॉल है जिसके द्वारा आप एक साथ कई बाहरी टूल्स और डेटा स्रोतों को जोड़ सकते हैं। अगला लेख [21 उप-एजेंट (Subagents)] यह समझाएगा कि कैसे आप कार्यों को विभाजित करके उन्हें समानांतर में चलाने के लिए उप-एजेंट्स का उपयोग कर सकते हैं।

यहाँ मेरे एक अनुभव का उदाहरण है जब मैंने पहली बार MCP का उपयोग किया था।

मैं Claude Code से आया था, और मुझे कमांड चलाने की आदत थी—जैसे किसी सर्वर को जोड़ने के लिए claude mcp add --scope user xxx जहाँ --scope यह तय करता था कि नियम किन प्रोजेक्ट्स में लागू होंगे। जब मैंने Codex का उपयोग शुरू किया, तो मैंने बिना सोचे-समझे वैसी ही कमांड चलाई और --scope का उपयोग किया, जिसके बाद टर्मिनल ने एरर दिखाया कि यह पैरामीटर मान्य नहीं है। मुझे लगा कि वर्शन पुराना है, मैंने अपडेट किया, लेकिन कोई लाभ नहीं हुआ। मैंने कमांड को कई बार सुधारा, लेकिन फिर भी एरर आता रहा।

लगभग बीस मिनट की माथापच्ची के बाद मैंने आधिकारिक दस्तावेज़ों को देखा और समझा: Codex में --scope नाम की कोई सेटिंग नहीं होती। यह सभी MCP कॉन्फ़िगरेशन को एक ही config.toml फ़ाइल में सहेजता है, और "नियम किन प्रोजेक्ट्स में लागू होंगे" यह फ़ाइल के स्थान द्वारा तय होता है—होम डायरेक्टरी ~/.codex/config.toml में लिखने पर यह सभी प्रोजेक्ट्स पर लागू होता है, और प्रोजेक्ट डायरेक्टरी .codex/config.toml में लिखने पर केवल उसी प्रोजेक्ट पर लागू होता है। मैं Claude Code के नियमों को Codex पर लागू करने की कोशिश कर रहा था, इसलिए विफल हो रहा था।

मैं यह कहानी इसलिए बता रहा हूँ ताकि आप वह बीस मिनट बचा सकें: MCP प्रोटोकॉल दोनों सिस्टम पर समान रूप से काम करता है, लेकिन इसे कॉन्फ़िगर करने के तरीके अलग हैं। आज हम Codex में इसे सेटअप करना विस्तार से समझेंगे और एक वास्तविक सर्वर कनेक्ट करके देखेंगे।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

• एक सरल विवरण कि MCP क्या है, और यह Codex की किस सीमा को दूर करता है।
• दो प्रकार के सर्वर (स्थानीय STDIO, रिमोट Streamable HTTP) कब उपयोग करने चाहिए, इसकी तुलनात्मक तालिका।
• दो कॉन्फ़िगरेशन तरीके—codex mcp add कमांड द्वारा या config.toml में मैन्युअल रूप से लिखना, और "ग्लोबल बनाम प्रोजेक्ट स्तर" तय करना।
• enabled / disabled_tools / default_tools_approval_mode विकल्पों द्वारा टूल्स और अनुमतियाँ नियंत्रित करना।
• एक सरल अभ्यास: कुछ ही मिनटों में Context7 दस्तावेज़ सर्वर को जोड़ना और जाँचना।

⚠️ नीचे दी गई सभी विशिष्ट कमांड्स, कॉन्फ़िगरेशन विकल्प और डिफ़ॉल्ट मान Codex आधिकारिक दस्तावेज़ पर आधारित हैं; पैकेजों के नाम और मॉडल भविष्य में अपडेट के साथ बदल सकते हैं, इसलिए इन्हें अपनी स्थानीय स्थिति के अनुसार देखें।

---

01 पहले समझें: MCP वास्तव में Codex की किस सीमा को दूर करता है

निष्कर्ष यह है: Codex डिफ़ॉल्ट रूप से केवल "स्थानीय स्तर पर काम करने वाला" एक सहायक है, और MCP इसके साथ बाहरी टूल्स और डेटा स्रोतों को जोड़ने का एक माध्यम है।

पिछले लेखों में आपने देखा है कि Codex क्या कर सकता है—फ़ाइलें पढ़ना, कोड बदलना, कमांड चलाना। ये सभी गतिविधियां स्थानीय थीं। यह चाहे जितना बुद्धिमान हो, Figma पर बनाए गए डिज़ाइन को नहीं देख सकता, किसी लाइब्रेरी के नवीनतम API दस्तावेज़ों की जाँच नहीं कर सकता, और ब्राउज़र को नियंत्रित नहीं कर सकता। इन चीज़ों के लिए आपको स्वयं स्क्रीनशॉट लेने होते थे या विवरण लिखकर इसे देने होते थे।

तुलना: फोन के मल्टी-पोर्ट एडेप्टर से। नए स्मार्टफोन में अक्सर केवल एक Type-C पोर्ट होता है, जिसमें आप पेन ड्राइव, HDMI केबल या SD कार्ड एक साथ नहीं लगा सकते। समाधान यह है कि आप एक एडेप्टर खरीदें—जो फोन के पोर्ट से जुड़कर आपको USB, HDMI और कार्ड रीडर की सुविधा दे सके। MCP (Model Context Protocol, यानी AI टूल्स को बाहरी सिस्टम से जोड़ने का एक ओपन स्टैंडर्ड) Codex के लिए इसी एडेप्टर की तरह है: इसे एक बार सेटअप करने पर कई बाहरी टूल्स इसके सामने उपलब्ध हो जाते हैं।

आधिकारिक दस्तावेज़ में इसकी परिभाषा सरल है:

Model Context Protocol (MCP) मॉडल को टूल्स और संदर्भ से जोड़ता है। इसका उपयोग करके आप Codex के साथ थर्ड-पार्टी दस्तावेज़ जोड़ सकते हैं, या इसे अपने ब्राउज़र, Figma और अन्य डेवलपर टूल्स से जोड़ सकते हैं।

यहाँ एक महत्वपूर्ण शब्द है—स्टैंडर्ड (Standard)। MCP कोई बंद या निजी प्रोटोकॉल नहीं है, बल्कि एक सार्वजनिक मानक है। इसका लाभ यह है कि "एक बार कॉन्फ़िगर करने पर इसे कहीं भी उपयोग किया जा सकता है": यदि आप किसी टूल के लिए MCP सर्वर बनाते हैं, तो उसका उपयोग Codex भी कर सकता है और अन्य MCP समर्थित क्लाइंट्स (Claude Code, Cursor...) भी कर सकते हैं। Codex में भी यही MCP प्रोटोकॉल लागू होता है, बस सेटिंग्स लिखने का तरीका अलग है।

Codex की एक विशेषता यह है: Codex स्टार्टअप पर सर्वर द्वारा दी जाने वाली instructions (निर्देश) फ़ील्ड को पढ़ता है, जिसे यह सर्वर की उपयोग नीति के रूप में उपयोग करता है—जिसमें आमतौर पर टूल्स के उपयोग की सीमाएं और निर्देश होते हैं। सरल शब्दों में, अच्छे सर्वर अपने साथ उपयोग नियमावली प्रदान करते हैं, जिसे Codex पढ़ता है।

आपको MCP की आवश्यकता कब होनी चाहिए? निर्णय सरल है: जब भी आप स्वयं को "किसी अन्य टूल से जानकारी कॉपी करके Codex में पेस्ट करते हुए" पाएं, तो आपको एक MCP सर्वर जोड़ने पर विचार करना चाहिए। कुछ वास्तविक परिदृश्य:

• "Figma के नए डिज़ाइन के अनुसार लॉगिन पेज का स्टाइल बदलें"—यह स्वयं डिज़ाइन देख सकता है, आपको स्क्रीनशॉट देने की आवश्यकता नहीं है।
• "नवीनतम API दस्तावेज़ के अनुसार इस कोड को दुबारा लिखें"—यह सीधे नवीनतम दस्तावेज़ों की जाँच कर सकता है, जिससे पुराना कोड लिखने का जोखिम नहीं रहता।
• "ब्राउज़र खोलकर मोबाइल स्क्रीन साइज़ पर इस पेज का स्क्रीनशॉट लें"—यह स्वयं ब्राउज़र को नियंत्रित कर सकता है।

💡 संक्षेप में: Codex डिफ़ॉल्ट रूप से केवल स्थानीय फ़ाइलों और कमांड्स तक ही सीमित रहता है, यह डिज़ाइन, दस्तावेज़ों या ब्राउज़र तक नहीं पहुँच सकता; MCP इसे बाहरी दुनिया से जोड़ने का एक साझा माध्यम है, जो सर्वर की instructions का भी उपयोग करता है।

यह आरेख दिखाता है कि Codex स्थानीय स्तर पर फ़ाइलों और कमांड्स तक सीमित है, लेकिन MCP एक USB हब की तरह काम करता है, जो इसे GitHub, डेटाबेस और Figma जैसे बाहरी सर्वरों से जोड़ता है।

---

02 दो प्रकार के सर्वर: स्थानीय (Local) बनाम क्लाउड (Cloud)

MCP सर्वर एक से अधिक प्रकार के होते हैं। इनमें अंतर समझना आवश्यक है ताकि आप सही कॉन्फ़िगरेशन लिख सकें। मुख्य प्रश्न यह है: क्या यह सर्वर आपकी अपनी मशीन पर चल रहा है, या इंटरनेट पर किसी पते पर होस्ट किया गया है?

तुलना: घर के उपकरणों से, जिनमें से कुछ बिजली बोर्ड से चलते हैं और कुछ वाई-फाई से। टेबल फैन या ट्यूबलाइट घर के बिजली बोर्ड से जुड़ते हैं; जबकि स्मार्ट स्पीकर को इंटरनेट और क्लाउड से जुड़ना होता है। MCP सर्वर भी इसी प्रकार होते हैं—एक जो आपकी मशीन पर स्थानीय रूप से चलता है, और दूसरा जो रिमोटली होस्ट होता है और आप उससे कनेक्ट करते हैं।

आधिकारिक तौर पर दो प्रकार के सर्वर समर्थित हैं:

प्रकार	स्थान	स्टार्टअप प्रक्रिया	सबसे उपयुक्त
STDIO (स्थानीय)	आपकी मशीन पर, कमांड द्वारा शुरू किया जाता है	स्टार्टअप कमांड प्रदान करना (जैसे npx ...)	स्थानीय फ़ाइलें पढ़ने, स्थानीय ब्राउज़र को नियंत्रित करने या स्थानीय उपकरणों से जुड़ने के लिए
Streamable HTTP (रिमोट)	इंटरनेट पते (URL) पर होस्ट	URL एड्रेस प्रदान करना	क्लाउड सर्विसेज, रिमोट दस्तावेज़ या डिज़ाइन सर्वर, लॉगिन विवरण के साथ

शुरुआती लोगों के लिए कुछ महत्वपूर्ण बातें:

STDIO सर्वर का मुख्य हिस्सा "स्टार्टअप कमांड" है। यह इस प्रकार काम करता है कि "Codex पृष्ठभूमि में एक छोटा प्रोग्राम चलाता है"—आप इसे एक स्टार्टअप कमांड (जैसे npx -y @upstash/context7-mcp) प्रदान करते हैं, और Codex सत्र शुरू होते ही इसे चला देता है। इसलिए आपकी मशीन पर आवश्यक रनटाइम पर्यावरण (जैसे Node.js) होना चाहिए। STDIO सर्वर को पर्यावरण वेरिएबल्स (--env या कॉन्फ़िगरेशन में env) भी प्रदान किए जा सकते हैं, जिनका उपयोग क्रेडेंशियल्स के लिए किया जाता है।

HTTP सर्वर क्लाउड सेवाओं से जुड़ते हैं, और लॉगिन के दो तरीके होते हैं। आधिकारिक तौर पर Streamable HTTP सर्वर निम्नलिखित दो प्रकार के लॉगिन का समर्थन करते हैं:

• Bearer token: कॉन्फ़िगरेशन में क्रेडेंशियल वाले पर्यावरण वेरिएबल का नाम लिखना।
• OAuth (ऑथराइज़ेशन लॉगिन): इसके लिए कमांड लाइन पर codex mcp login <server-name> चलाई जाती है।

Figma या अन्य क्लाउड दस्तावेज़ सर्वरों के लिए केवल URL और क्रेडेंशियल्स की आवश्यकता होती है, स्थानीय मशीन पर कुछ भी इंस्टॉल करने की आवश्यकता नहीं होती।

Claude Code की तरह अन्य टूल्स में पाए जाने वाले पुराने तरीकों (जैसे SSE) के विपरीत, Codex केवल STDIO और Streamable HTTP का ही समर्थन करता है, जिससे भ्रम की स्थिति नहीं रहती।

कनेक्शन की प्रक्रिया को इस आरेख से समझें:

यह आरेख दिखाता है कि Codex स्थानीय फाइलों तक सीमित है, लेकिन MCP प्रोटोकॉल STDIO (स्थानीय प्रोसेस) और Streamable HTTP (रिमोट पते) द्वारा इसे बाहरी सिस्टम से जोड़ता है।

💡 संक्षेप में: स्थानीय उपकरणों के लिए STDIO का उपयोग करें (स्टार्टअप कमांड प्रदान करें, स्थानीय रनटाइम आवश्यक है), और क्लाउड सेवाओं के लिए Streamable HTTP का उपयोग करें (URL प्रदान करें और Bearer token या OAuth द्वारा क्रेडेंशियल्स सेट करें)।

---

03 सर्वर कैसे जोड़ें: कमांड द्वारा बनाम config.toml फ़ाइल में लिखकर

प्रकार समझने के बाद, आइए जोड़ने की प्रक्रिया को समझें। Codex में दो विकल्प उपलब्ध हैं, और ध्यान रखें कि सभी सेटिंग्स config.toml फ़ाइल में सहेजी जाती हैं।

आधिकारिक विवरण:

Codex stores MCP configuration alongside other configuration in config.toml. Defaults to ~/.codex/config.toml, but you can scope it using .codex/config.toml in trusted projects.

यह Claude Code से एक मुख्य अंतर है—वह भूल जो मैंने की थी: Claude Code में --scope विकल्प का उपयोग किया जाता था, जबकि Codex में यह सेटिंग नहीं होती। यहाँ यह फ़ाइल के स्थान द्वारा तय होता है:

फ़ाइल का स्थान	प्रभाव का दायरा	उदाहरण
~/.codex/config.toml (ग्लोबल)	आपके सभी प्रोजेक्ट्स पर	"वह सर्वर जिसका मैं सभी प्रोजेक्ट्स में उपयोग करना चाहता हूँ"
प्रोजेक्ट की .codex/config.toml	केवल वर्तमान प्रोजेक्ट पर (प्रोजेक्ट पर भरोसा होने पर)	"यह सर्वर केवल इसी प्रोजेक्ट के लिए है"

एक और महत्वपूर्ण बात: कमांड लाइन और IDE एक्सटेंशन दोनों एक ही कॉन्फ़िगरेशन का उपयोग करते हैं। CLI में जोड़े गए सर्वर स्वचालित रूप से VS Code में भी उपलब्ध हो जाते हैं।

प्रोजेक्ट स्तर की कॉन्फ़िगरेशन केवल तभी लागू होती है जब आपने प्रोजेक्ट पर भरोसा (Trust) किया हो, ताकि अनधिकृत प्रोजेक्ट्स सुरक्षा का उल्लंघन न कर सकें।

तरीका 1: codex mcp कमांड का उपयोग (सबसे तेज़)

STDIO सर्वर जोड़ने के लिए codex mcp add का उपयोग करें, ध्यान रखें कि -- के बाद की कमांड स्टार्टअप कमांड होती है:

codex mcp add <server-name> --env VAR1=VALUE1 -- <stdio startup command>

Context7 (दस्तावेज़ों की जाँच के लिए एक उपयोगी सर्वर) को जोड़ने का उदाहरण:

codex mcp add context7 -- npx -y @upstash/context7-mcp

यहाँ -- के बाद npx -y @upstash/context7-mcp स्टार्टअप कमांड है, जहाँ -y विकल्प पैकेज को बिना पुष्टि के इंस्टॉल करने के लिए है। अन्य विकल्पों की जाँच के लिए codex mcp --help चलाएं। OAuth समर्थित HTTP सर्वरों के लिए जोड़ने के बाद codex mcp login <server-name> चलाएं।

सत्र के भीतर वर्तमान MCP सर्वरों की सूची देखने के लिए स्लैश कमांड चलाएं:

/mcp

तरीका 2: config.toml फ़ाइल में मैन्युअल रूप से लिखना (अधिक नियंत्रण के लिए)

बारीक नियंत्रणों (टूल्स को सीमित करना, टाइमआउट बदलना, अनुमतियाँ सेट करना) के लिए आप सीधे config.toml फ़ाइल को संपादित कर सकते हैं। प्रत्येक सर्वर को [mcp_servers.<server-name>] सेक्शन के तहत लिखा जाता है।

STDIO सर्वर के लिए इस प्रकार लिखें (ऊपर दिए गए Context7 का उदाहरण):

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

यहाँ command स्टार्टअप कमांड है और args उसके पैरामीटर हैं। अन्य विकल्पों में env (पर्यावरण वेरिएबल्स), cwd (कार्य निर्देशिका) शामिल हैं।

Streamable HTTP सर्वर के लिए URL और क्रेडेंशियल्स लिखें (Figma का उदाहरण):

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

यहाँ url सर्वर का पता है; bearer_token_env_var क्रेडेंशियल वाले पर्यावरण वेरिएबल का नाम है—सुरक्षा के लिए टोकन को सीधे फ़ाइल में न लिखें, केवल वेरिएबल का नाम लिखें। आप http_headers का भी उपयोग कर सकते हैं।

ℹ️ यह config.toml वही मुख्य कॉन्फ़िगरेशन फ़ाइल है जिसे हमने पिछले लेख में समझा था। MCP इसका एक हिस्सा (mcp_servers) है। codex mcp add कमांड भी इसी फ़ाइल में सेटिंग्स लिखती है।

💡 संक्षेप में: Codex में सभी MCP सेटिंग्स config.toml में लिखी जाती हैं—यहाँ --scope नहीं होता, बल्कि फ़ाइल का स्थान दायरा तय करता है; सर्वर को codex mcp add द्वारा या फ़ाइल में [mcp_servers.<name>] तालिका लिखकर जोड़ा जा सकता है।

---

04 टूल्स और अनुमतियाँ नियंत्रित करना

सर्वर जोड़ने का मतलब यह नहीं है कि इसे हर काम करने की खुली अनुमति है—आप इसकी अनुमतियों को सीमित कर सकते हैं। Codex फ़ाइल में कई विकल्प प्रदान करता है ताकि प्रत्येक सर्वर की गतिविधियों को नियंत्रित किया जा सके।

तुलना: सहायक को कार्यालय में प्रवेश कार्ड देने से। आप सहायक को पूरे कार्यालय में कहीं भी जाने का कार्ड नहीं देंगे—आप तय करेंगे कि वह किस कमरे में जा सकता है, कब जा सकता है, और संवेदनशील फाइलों को छूने से पहले उसे अनुमति लेनी होगी। MCP सर्वर के लिए अनुमतियाँ तय करना भी वैसा ही है: सर्वर में कई टूल्स हो सकते हैं, आप तय करते हैं कि कौन सा टूल चलेगा, कौन सा ब्लॉक रहेगा, और किस टूल के लिए अनुमोदन आवश्यक होगा।

अक्सर उपयोग किए जाने वाले विकल्पों का विवरण:

विकल्प	विवरण	डिफ़ॉल्ट व्यवहार
enabled	सर्वर को अस्थायी रूप से अक्षम करना (सेटिंग्स हटाए बिना)	false सेट करने पर बंद
enabled_tools	स्वीकृत टूल्स की सूची (केवल ये चलेंगे)	न लिखने पर सभी स्वीकृत
disabled_tools	प्रतिबंधित टूल्स की सूची	—
default_tools_approval_mode	सर्वर टूल्स के लिए डिफ़ॉल्ट अनुमोदन व्यवहार	auto / prompt / approve
startup_timeout_sec	सर्वर स्टार्टअप टाइमआउट (सेकंड में)	डिफ़ॉल्ट 10
tool_timeout_sec	टूल निष्पादन टाइमआउट (सेकंड में)	डिफ़ॉल्ट 60

नियम:

व्हाइटलिस्ट (enabled_tools) ब्लैकलिस्ट (disabled_tools) से पहले लागू होती है। आप पहले स्वीकृत टूल्स की सूची बना सकते हैं, और फिर ब्लैकलिस्ट द्वारा उनमें से कुछ को प्रतिबंधित कर सकते हैं। उदाहरण के लिए, Chrome DevTools में: enabled_tools = ["open", "screenshot"] द्वारा दो टूल्स सक्षम किए गए, और फिर disabled_tools = ["screenshot"] द्वारा स्क्रीनशॉट को प्रतिबंधित कर दिया गया, जिससे केवल open टूल ही काम करेगा।

default_tools_approval_mode के तीन विकल्प होते हैं, इन्हें सैंडबॉक्स अनुमतियों से भ्रमित न करें। यह केवल इस बात को नियंत्रित करता है कि सर्वर के टूल को चलाने से पहले आपसे अनुमोदन माँगा जाए या नहीं:

• auto: सिस्टम सुरक्षा स्तर के अनुसार निर्णय लेता है।
• prompt: प्रत्येक टूल रन से पहले अनुमोदन पॉप-अप दिखाता है।
• approve: टूल्स को बिना पूछे सीधे चलने देता है (विश्वसनीय सर्वरों के लिए)।

आप tools.<tool-name>.approval_mode द्वारा किसी विशिष्ट टूल के लिए भी नियम बदल सकते हैं। जैसे "सर्वर के बाकी टूल्स बिना पूछे चलें, लेकिन संवेदनशील टूल से पहले हमेशा पूछा जाए"।

टाइमआउट सेटिंग्स: स्टार्टअप के लिए 10 सेकंड और टूल रन के लिए 60 सेकंड। यदि कोई स्थानीय सर्वर शुरू होने में अधिक समय लेता है, तो डिफ़ॉल्ट 10 सेकंड समाप्त होने पर स्टार्टअप एरर आ सकता है। ऐसी स्थिति में टाइमआउट बढ़ाएं:

[mcp_servers.slow_server]
command = "python"
args = ["-m", "slow_server"]
startup_timeout_sec = 30   # स्टार्टअप टाइमआउट बढ़ाना
tool_timeout_sec = 120     # टूल निष्पादन टाइमआउट बढ़ाना

एक विस्तृत कॉन्फ़िगरेशन का उदाहरण:

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
disabled_tools = ["screenshot"]          # यहाँ केवल open काम करेगा
default_tools_approval_mode = "prompt"   # टूल्स के लिए हमेशा अनुमति माँगी जाएगी
startup_timeout_sec = 20
enabled = true

[mcp_servers.chrome_devtools.tools.open]
approval_mode = "approve"                # open टूल को बिना पूछे चलने की अनुमति

💡 संक्षेप में: config.toml में प्रत्येक सर्वर की सेटिंग्स को सीमित किया जा सकता है—enabled द्वारा चालू/बंद करना, व्हाइटलिस्ट/ब्लैकलिस्ट द्वारा टूल्स को नियंत्रित करना, default_tools_approval_mode द्वारा अनुमोदन व्यवहार सेट करना, और टाइमआउट बदलना।

---

05 थर्ड-पार्टी सर्वर से जुड़े सुरक्षा जोखिम

यह अनुभाग छोटा है, लेकिन अत्यंत महत्वपूर्ण है—यह सीधे सुरक्षा जोखिमों (लेख 16) से संबंधित है।

नियम स्पष्ट है: MCP सर्वर थर्ड-पार्टी कोड होते हैं, और OpenAI उनकी सुरक्षा की गारंटी नहीं देता। जब आप स्थानीय STDIO सर्वर जोड़ते हैं, तो आप अपनी मशीन पर किसी अन्य के लिखे प्रोग्राम को चलाने की अनुमति दे रहे होते हैं; और जब आप HTTP सर्वर जोड़ते हैं, तो आप बाहरी सामग्री को Codex की पहुँच में ला रहे होते हैं। दोनों ही मामलों में सावधानी आवश्यक है।

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

बाहरी पेजों से जुड़ने वाले सर्वरों में जोखिम अधिक क्यों होता है? क्योंकि वे प्रॉम्प्ट इंजेक्शन (prompt injection) का मार्ग बन सकते हैं—जिसका विवरण लेख 16 में दिया गया था। वेब पेजों या दस्तावेज़ों में दुर्भावनापूर्ण निर्देश छिपे हो सकते हैं, जिन्हें पढ़ने पर Codex विचलित हो सकता है। इसलिए अनुमतियों को सीमित करना और अनुमोदन सेट करना महत्वपूर्ण है—अपरिचित सर्वरों के लिए हमेशा prompt (अनुमोदन आवश्यक) सेट करें, और खतरनाक टूल्स को ब्लॉक रखें।

जोड़ने के नियम:

परिदृश्य	नियम
आधिकारिक तौर पर अनुशंसित सर्वर (OpenAI Docs, Context7, Figma, Playwright आदि)	✅ विश्वसनीय हैं
बड़ी कंपनियों द्वारा जारी सर्वर (GitHub, Sentry आदि)	✅ विश्वसनीय हैं
GitHub पर कम प्रसिद्ध थर्ड-पार्टी सर्वर	⚠️ कोड की जाँच करें, सोच-समझकर निर्णय लें
किसी सर्वर के लिए default_tools_approval_mode = "approve" सेट करना	⚠️ केवल पूरी तरह विश्वसनीय सर्वरों के लिए ही ऐसा करें
किसी सर्वर को उत्पादन डेटा में लिखने की अनुमति देना	❌ जहाँ तक संभव हो केवल रीड-ओनली एक्सेस ही दें

न्यूनतम अनुमतियाँ देना सुरक्षा सुनिश्चित करने का सबसे बुनियादी नियम है। Codex सैंडबॉक्स सीमाएं लागू रखता है—लेकिन यदि आप स्वयं किसी दुर्भावनापूर्ण सर्वर को बिना पूछे चलने की अनुमति दे देते हैं, तो सैंडबॉक्स भी मदद नहीं कर पाएगा।

💡 संक्षेप में: MCP सर्वर थर्ड-पार्टी कोड होते हैं जिनकी सुरक्षा ऑडिट स्वयं करनी होगी; केवल विश्वसनीय और आधिकारिक सर्वरों का ही उपयोग करें, अनुमतियों को सीमित रखें, और संवेदनशील गतिविधियों के लिए हमेशा अनुमोदन सक्रिय रखें।

---

06 अभ्यास: Context7 दस्तावेज़ सर्वर जोड़ना और उपयोग करना

आइए Context7 सर्वर जोड़कर इसका व्यावहारिक अभ्यास करें—यह आधिकारिक तौर पर अनुशंसित एक निःशुल्क सर्वर है जिसका उपयोग कोडिंग दस्तावेज़ों की जाँच के लिए किया जाता है। इसके उपयोग के लिए किसी भुगतान की आवश्यकता नहीं होती और कॉन्फ़िगरेशन भी सरल है।

⚠️ आवश्यकता: Context7 npx द्वारा चलता है, इसलिए आपकी मशीन पर Node.js होना आवश्यक है (जाँच के लिए कमांड लाइन पर node -v चलाएं)। यदि नेटवर्क की समस्या हो तो वीपीएन चालू करें।

चरण 1: सर्वर जोड़ें (टर्मिनल में चलाएं, codex सत्र से बाहर)

codex mcp add context7 -- npx -y @upstash/context7-mcp

अपेक्षित परिणाम: एक संदेश दिखाई देगा कि context7 सर्वर जोड़ दिया गया है। यह कमांड ~/.codex/config.toml फ़ाइल में [mcp_servers.context7] तालिका लिख देती है (आप फ़ाइल खोलकर इसकी जाँच कर सकते हैं)।

चरण 2: सत्र में जाकर कनेक्शन की जाँच करें

codex

सत्र में प्रवेश करने के बाद चलाएं:

/mcp

आपको सूची में context7 दिखाई देगा—इसका अर्थ है कि सर्वर कनेक्ट हो गया है। यदि यह दिखाई नहीं देता, तो Node.js या नेटवर्क की जाँच करें।

चरण 3: दस्तावेज़ों की जाँच करने के लिए कहें

इसे एक विशिष्ट लाइब्रेरी के बारे में पूछें और दस्तावेज़ सर्वर का उपयोग करने के लिए कहें:

कृपया Context7 का उपयोग करके React Router के नवीनतम वर्शन के रूट कॉन्फ़िगरेशन का उदाहरण दिखाएं, और दस्तावेज़ों का संदर्भ दें।

Codex Context7 टूल का उपयोग करके नवीनतम दस्तावेज़ों को प्राप्त करेगा—पहली बार टूल रन होने पर यह आपसे अनुमति मांगेगा, अनुमति दें। इसके बाद यह नवीनतम जानकारी दिखाएगा जो पुरानी यादों पर आधारित नहीं होगी। आप देख पाएंगे कि प्रक्रिया में Context7 का उपयोग किया गया है।

चरण 4: हटाना (वैकल्पिक)

अभ्यास के बाद सर्वर हटाने के लिए विवरण देखने के लिए चलाएं:

codex mcp --help

मदद संकेतों के अनुसार सर्वर को हटा सकते हैं; या सीधे ~/.codex/config.toml फ़ाइल से [mcp_servers.context7] तालिका को हटा दें या enabled = false लिख दें। फ़ाइल संपादन भी एक आसान तरीका है।

इस प्रकार आपने पूरी प्रक्रिया को स्वयं करके देख लिया है।

💡 संक्षेप में: अभ्यास के चरण हैं—codex mcp add द्वारा जोड़ना → /mcp से कनेक्शन जाँचना → दस्तावेज़ देखने के लिए कहना और पहली बार अनुमति देना → फ़ाइल या कमांड द्वारा हटाना।

---

07 सारांश

इस लेख में हमने Codex को बाहरी सिस्टम्स से जोड़ने वाले MCP प्रोटोकॉल को समझा है।

मुख्य बिंदुओं का सारांश:

विषय	विवरण	मुख्य बिंदु
MCP का उद्देश्य	बाहरी सिस्टम से जुड़ना	Codex की सीमा समाप्त करना और डिज़ाइन, दस्तावेज़ों तथा ब्राउज़र से जोड़ना; instructions का उपयोग
स्थानीय सर्वर	STDIO सर्वर	स्टार्टअप कमांड (जैसे npx ...), स्थानीय रनटाइम आवश्यक
रिमोट सर्वर	Streamable HTTP	URL एड्रेस और Bearer token या OAuth लॉगिन
फ़ाइल स्थान	दायरा तय करना	ग्लोबल ~/.codex/config.toml या प्रोजेक्ट .codex/config.toml (भरोसा आवश्यक)
जोड़ना	विधियाँ	codex mcp add कमांड या config.toml में मैन्युअल प्रविष्टि
नियंत्रण	अनुमतियाँ	enabled, व्हाइटलिस्ट/ब्लैकलिस्ट, अनुमोदन सेटिंग्स, टाइमआउट
सुरक्षा	थर्ड-पार्टी जोखिम	क्रेडेंशियल्स सीमित रखें, अपरिचित को ब्लॉक करें, और प्रॉम्प्ट इंजेक्शन का ध्यान रखें

अब आप यह कर सकते हैं: MCP के महत्व को समझाना, STDIO और HTTP सर्वरों में अंतर बताना, फ़ाइल स्थान द्वारा दायरा तय करना, सर्वर जोड़ना और कनेक्शन जाँचना, अनुमतियाँ और टाइमआउट नियंत्रित करना, और सुरक्षा सीमाओं का ध्यान रखना। यह क्षमता Codex को एक व्यापक कोडिंग टूल में बदल देती है।

Codex में काम करने के तरीके को समझने के लिए config.toml नियमों को याद रखें।

---

अगला लेख [21 उप-एजेंट (Subagents)]—MCP द्वारा Codex की क्षमताएं बढ़ जाती हैं, लेकिन अधिक काम होने पर एक ही सत्र में संदर्भ (Context) बहुत अधिक भर सकता है। अगले लेख में हम कार्य को विभाजित करने का तरीका देखेंगे: कार्यों को छोटे उप-एजेंट्स में बाँटना, जहाँ मुख्य एजेंट काम सौंपता है, उप-एजेंट काम करते हैं और संदर्भ आपस में मिश्रित नहीं होता। यह बड़े प्रोजेक्ट्स में काम को आसान बनाने का एक बेहतरीन तरीका है।

---

अनुशंसित पठन

• चार प्रकार के वर्कफ़्लो: बग फिक्स, रिफैक्टर और परीक्षण
• मॉडल का चुनाव: सही कार्य के लिए सही मॉडल चुनना
• प्रोजेक्ट मैनुअल AGENTS.md: स्टार्टअप नियमों को जोड़ना