Codex के लिए बेस्ट MCP सर्वर की रैंक-वार सूची, जिसमें OpenAI Docs MCP और Context7 से लेकर GitHub, Playwright, Chrome DevTools और Figma तक शामिल हैं। इसमें सीधे पेस्ट करने लायक config.toml स्निपेट्स, लिखने की अनुमति को काबू में रखने वाली अप्रूवल सेटिंग्स और स्टैक में इमेज जनरेशन जोड़ने का तरीका भी है।
Codex अपने दम पर कोड अच्छा लिखता है। लेकिन अकेले वह यह नहीं कर पाता: आज सुबह इंस्टॉल की गई लाइब्रेरी के वर्ज़न के डॉक्स पढ़ना, पुल रिक्वेस्ट खोलना, आपके चेकआउट पेज पर क्लिक करके देखना, या एक घंटे पहले प्रोडक्शन में आई एरर को देखना। MCP सर्वर यह अंतर भर देते हैं। हर सर्वर Model Context Protocol के ज़रिए Codex को टूल्स का एक सेट देता है, और सही टूल्स का छोटा-सा सेट एक सक्षम असिस्टेंट को ऐसे सहायक में बदल देता है जो किसी टिकट को विवरण से लेकर मर्ज़ हुए बदलाव तक ले जा सके।
यह रैंकिंग उन चीज़ों पर आधारित है जिन्हें डेवलपर असली प्रोजेक्ट्स में सबसे ज़्यादा इस्तेमाल करते हैं: डॉक्यूमेंटेशन, सोर्स कंट्रोल, ब्राउज़र, डिज़ाइन फ़ाइलें और एरर ट्रैकिंग। यह OpenAI के अपने Codex डॉक्यूमेंटेशन से शुरू होती है, जिसमें सुझाए गए सर्वरों की एक छोटी सूची दी गई है, और फिर उन अतिरिक्त सर्वरों को जोड़ती है जो एक काम करने वाले सेटअप में जगह बनाने लायक हैं। इस दौरान आपको config.toml स्निपेट्स मिलेंगे जिन्हें आप पेस्ट कर सकते हैं, अनुमतियों को कड़ा रखने का तरीका, और उसी टूल्स के सेट में इमेज जनरेशन जोड़ने पर एक नज़र।
💡 त्वरित जवाब: पहले OpenAI Docs MCP, Context7, GitHub और Playwright इंस्टॉल करें। Chrome DevTools, Figma और Sentry तभी जोड़ें जब किसी प्रोजेक्ट को उनकी ज़रूरत हो।
Codex अपनी सेटिंग्स ~/.codex/config.toml से पढ़ता है। यही एक फ़ाइल CLI, IDE एक्सटेंशन और डेस्कटॉप ऐप, तीनों में साझा होती है, इसलिए एक बार रजिस्टर किया गया सर्वर हर जगह दिखता है। हर सर्वर की अपनी [mcp_servers.<name>] टेबल होती है, और Codex स्टार्टअप पर सक्षम सर्वरों से कनेक्ट करता है।
MCP सर्वर एक छोटा प्रोग्राम होता है, या कोई होस्टेड एंडपॉइंट, जो टूल्स की एक सूची विज्ञापित करता है। Codex कनेक्ट होता है, वह सूची पढ़ता है, और किसी काम के बीच में उन टूल्स को कॉल कर सकता है। GitHub सर्वर पुल रिक्वेस्ट से जुड़े एक्शन उपलब्ध कराता है। डॉक्स सर्वर सर्च उपलब्ध कराता है। Codex तय करता है कि टूल कब कॉल करना है, और आपकी अप्रूवल सेटिंग्स तय करती हैं कि उसे पहले आपसे पूछना ज़रूरी है या नहीं।
इसका व्यावहारिक असर है अनुमानों में कमी। किसी API के याद किए हुए वर्ज़न पर लिखने के बजाय असिस्टेंट उसे देखकर जाँच लेता है। "यह ठीक होना चाहिए" कहने के बजाय वह ब्राउज़र खोलकर जाँच करता है।
ट्रांसपोर्ट इस बात पर निर्भर करता है कि आप कौन-से फ़ील्ड लिखते हैं। command का मतलब है कि Codex एक लोकल stdio प्रोसेस लॉन्च करता है। url का मतलब है कि वह एक रिमोट streamable HTTP सर्वर से बात करता है।
| Stdio सर्वर | Streamable HTTP सर्वर | |
|---|---|---|
| चयन का तरीका | command | url |
| चलता है | एक लोकल प्रोसेस जिसे Codex लॉन्च करता है | एक रिमोट सर्विस |
| आम सेटअप | npx पैकेज और args | OAuth या bearer token |
| क्रेडेंशियल | env या env_vars | auth (डिफ़ॉल्ट रूप से OAuth) या bearer_token_env_var |
| किसके लिए अच्छा | डॉक्स लुकअप, ब्राउज़र, लोकल फ़ाइलें | होस्टेड सेवाएँ जैसे इश्यू ट्रैकर |
💡 OAuth वाले रिमोट सर्वरों के लिए
codex mcp loginएक बार चलाएँ। टर्मिनल UI के अंदर/mcpदिखाता है कि अभी कौन-से सर्वर सक्रिय हैं।
नीचे का क्रम दो नियमों पर चलता है। जो सर्वर केवल पढ़ते हैं, वे उन सर्वरों से ऊपर रैंक होते हैं जो लिखते हैं। और जो सर्वर Codex को पुरानी जानकारी से बचाते हैं, वे उन सर्वरों से ऊपर रैंक होते हैं जो बस एक क्लिक बचाते हैं। छह में से पाँच सीधे उस सूची से आते हैं जिसकी सिफ़ारिश OpenAI अपने Codex डॉक्यूमेंटेशन में करता है।
| रैंक | सर्वर | किसके लिए सबसे अच्छा | लिखने का जोखिम |
|---|---|---|---|
| 1 | OpenAI Docs MCP | मौजूदा OpenAI API और Codex के जवाब | बहुत कम |
| 2 | Context7 | वर्ज़न-विशेष लाइब्रेरी डॉक्स | बहुत कम |
| 3 | GitHub | पुल रिक्वेस्ट, इश्यू, CI रन | मध्यम |
| 4 | Playwright | असली ब्राउज़र चलाना | मध्यम |
| 5 | Chrome DevTools | कंसोल, नेटवर्क, परफ़ॉर्मेंस | कम |
| 6 | Figma | असली डिज़ाइन फ़ाइलों से बनाना | कम |
रैंकिंग बस यह बताती है कि सामान्य रूप से क्या अच्छा है। आप पहले क्या इंस्टॉल करें, यह उस प्रोजेक्ट पर निर्भर करता है जो आपके सामने है:
| प्रोजेक्ट का प्रकार | पहले इंस्टॉल करें | बाद में जोड़ें |
|---|---|---|
| अकेला फ़्रंट-एंड ऐप | Context7, Playwright, Chrome DevTools | Figma |
| बैकएंड API सर्विस | Context7, GitHub, Sentry | केवल-पढ़ने वाला डेटाबेस सर्वर |
| CI वाली टीम रिपॉज़िटरी | GitHub, Linear, Context7 | Playwright, Sentry |
अगर ऐप खुद OpenAI API कॉल करता है, तो किसी भी पंक्ति में OpenAI Docs MCP जोड़ें। इसकी लागत लगभग कुछ नहीं है, और यह पुराने पैरामीटर से जुड़ी बग्स की पूरी एक श्रेणी को रोकता है।
Codex वही जानता है जिस पर उसे ट्रेन किया गया था, और वह जानकारी किसी नाम बदले गए पैरामीटर या नए एंडपॉइंट से पीछे हो सकती है। OpenAI Docs सर्वर Codex को अंदाज़ा लगाने के बजाय मौजूदा डॉक्यूमेंटेशन जाँचने देता है। यह केवल पढ़ता है, इसलिए कुछ बिगड़ने की गुंजाइश लगभग नहीं है।
अगर आपका ऐप OpenAI API कॉल करता है, या आप Codex से उसकी अपनी कॉन्फ़िगरेशन के बारे में सवाल पूछते हैं, तो यह सूची का सबसे ज़्यादा फ़ायदे वाला इंस्टॉल है। यह पहला स्थान इसलिए कमाता है क्योंकि यह उपयोगी भी है और लगभग जोखिम-मुक्त भी।
Context7 लाइब्रेरी और फ़्रेमवर्क के मौजूदा, वर्ज़न-विशेष डॉक्यूमेंटेशन लाता है और ज़रूरत पड़ने पर उसे कॉन्टेक्स्ट में डाल देता है। यह एजेंट की सबसे आम गलती पर वार करता है: किसी ऐसे API पर आत्मविश्वास से कोड लिखना जो दो मेजर वर्ज़न पहले बदल चुका था।
एक कमांड इसे रजिस्टर कर देती है:
codex mcp add context7 -- npx -y @upstash/context7-mcp
या वही चीज़ हाथ से लिखें, पहली npx डाउनलोड के लिए स्टार्टअप की लंबी अवधि के साथ:
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
startup_timeout_sec = 20
💡 अपनी
AGENTS.mdमें एक लाइन जोड़ें, जैसे "लाइब्रेरी डॉक्यूमेंटेशन के लिए Context7 इस्तेमाल करें", ताकि Codex हर बार कहे बिना उसकी ओर जाए।
ज़्यादातर टीमों के लिए, डॉक्स के बाद आधिकारिक GitHub सर्वर सबसे ज़्यादा असर डालने वाला कनेक्शन है। Codex पुल रिक्वेस्ट पढ़ और उन पर कमेंट कर सकता है, कई रिपॉज़िटरी में कोड खोज सकता है, इश्यू की छँटाई कर सकता है, और फ़ेल होने वाले CI रन की जाँच कर सकता है। इससे "यह बिल्ड लाल क्यों है?" दस मिनट की टैब-खोज से बदलकर एक प्रॉम्प्ट बन जाता है।
यह इस सूची का पहला सर्वर है जो चीज़ें बदल सकता है, इसलिए इसे सावधानी से कॉन्फ़िगर करें:
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_MCP_TOKEN"
default_tools_approval_mode = "prompt"
कॉपी करने से पहले GitHub के अपने README से एंडपॉइंट की पुष्टि कर लें, क्योंकि होस्टेड URL बदल सकते हैं। टोकन को एनवायरनमेंट वेरिएबल में रखें, उसे केवल उन्हीं रिपॉज़िटरी तक सीमित करें जिन पर आप असल में काम करते हैं, और केवल रीड एक्सेस से शुरू करें।
Microsoft का Playwright सर्वर Codex को चलाने के लिए एक असली ब्राउज़र देता है। यह पेज खोलता है, फ़ॉर्म भरता है, कंट्रोल पर क्लिक करता है, एक्सेसिबिलिटी ट्री के ज़रिए पेज पढ़ता है, और डिबगिंग सेशन के दौरान ब्राउज़र की स्थिति बनाए रखता है। फ़र्क जवाब के शब्दों में दिखता है: "मैंने बदलाव कर दिया" की जगह "मैंने बदलाव किया और पुष्टि की कि वह सही रेंडर होता है" आता है।
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
इसे चेकआउट फ़्लो, फ़ॉर्म वैलिडेशन, और ऐसे किसी भी मामले के लिए इस्तेमाल करें जहाँ बग तीन क्लिक के बाद ही आता है। क्योंकि यह फ़ॉर्म सबमिट कर सकता है और बटन क्लिक कर सकता है, इसे प्रोडक्शन के बजाय स्टेजिंग साइट पर इस्तेमाल करें।
OpenAI का डॉक्यूमेंटेशन Chrome DevTools और Playwright को विकल्प के रूप में सूचीबद्ध करता है, लेकिन दोनों अलग-अलग समस्याएँ हल करते हैं। Playwright एक फ़्लो को ऑटोमेट करता है। DevTools एक पेज की जाँच करता है। जब सवाल हो "यह धीमा क्यों है?" या "यह कंसोल एरर क्या है?", तो DevTools सर्वर Codex को सिर्फ़ सोर्स कोड से तर्क करने के बजाय नेटवर्क पैनल, कंसोल और परफ़ॉर्मेंस डेटा देखने देता है।
कई प्रोजेक्ट दोनों चलाते हैं। अगर आप केवल एक चुन सकते हैं, तो टेस्ट-जैसे काम के लिए Playwright चुनें और परफ़ॉर्मेंस व रेंडरिंग बग्स के लिए DevTools।
डिज़ाइन सर्वर के बिना Codex स्क्रीनशॉट या आपके विवरण से बनाता है, और स्पेसिंग बिगड़ जाती है। Figma सर्वर के साथ वह फ़ाइल से ही संरचित जानकारी ला सकता है: लेआउट, स्पेसिंग, रंग और कॉम्पोनेंट की बनावट। नतीजा पहला ड्राफ़्ट होता है जो उस चीज़ के कहीं ज़्यादा करीब होता है जो डिज़ाइनर ने असल में भेजा था।
यह छोटी सूची में आख़िरी स्थान पर सिर्फ़ इसलिए है क्योंकि यह कम प्रोजेक्ट्स के लिए मायने रखता है। जिस फ़्रंट-एंड टीम के पास सक्रिय डिज़ाइन फ़ाइल हो, वहाँ यह दूसरे स्थान तक ऊपर आ सकता है।
जब मुख्य छह सर्वर स्थिर हो जाएँ, तो कुछ और कनेक्शन खास तरह के कामों में अपनी उपयोगिता साबित करते हैं। एंडपॉइंट और परमिशन स्कोप के लिए हर विक्रेता का मौजूदा डॉक्यूमेंटेशन देख लें, क्योंकि ये ब्लॉग पोस्ट से तेज़ी से बदलते हैं।
Sentry एक MCP सर्वर प्रकाशित करता है जो Codex को स्टैक ट्रेस और हाल की एरर दे सकता है, ताकि बग रिपोर्ट किसी पैराफ़्रेज़ के बजाय असली विफलता से शुरू हो। Linear भी एक प्रकाशित करता है, जिससे Codex कुछ लिखने से पहले टिकट का टेक्स्ट और स्वीकृति मानदंड पढ़ सकता है। साथ मिलकर ये लूप बंद कर देते हैं: एरर बताती है क्या टूटा, और टिकट बताता है "ठीक हुआ" का मतलब क्या है।
डेटाबेस सर्वरों को लेकर चेतावनी ज़रूरी है। प्रोडक्शन डेटाबेस से जुड़ा सर्वर एक टाइपो को इंसिडेंट में बदल सकता है। उसे केवल-पढ़ने वाली रेप्लिका या लोकल कॉपी पर इस्तेमाल करें, और हर लिखने वाला टूल बंद रखें।
सर्वर जोड़ने के दो तरीके हैं, और दोनों से एक ही नतीजा मिलता है।
एक सर्वर के लिए कमांड लाइन सबसे तेज़ रास्ता है:
# local stdio server
codex mcp add playwright -- npx @playwright/mcp@latest
# remote streamable HTTP server
codex mcp add github --url https://api.githubcopilot.com/mcp/
# see what is configured, and log in to OAuth servers
codex mcp list
codex mcp login github
codex mcp add उसी config.toml में लिखता है, और लोकल सर्वरों के लिए, जिन्हें एनवायरनमेंट वेरिएबल चाहिए, आप --env NAME=VALUE पास कर सकते हैं। पूरी कमांड सूची के लिए codex mcp --help चलाएँ।
हर इंस्टॉल के बाद किसी सर्वर पर भरोसा करने से पहले ये तीन जाँचें एक जैसी करें:
/mcp खोलें और पुष्टि करें कि सर्वर सक्रिय दिख रहा है।अगर पहला चरण विफल हो, तो कारण आम तौर पर स्टार्टअप टाइमआउट, किसी एनवायरनमेंट वेरिएबल की कमी, या ऐसा पैकेज होता है जिसे पहली बार डाउनलोड करना ज़रूरी है। अगला सर्वर जोड़ने से पहले इसे ठीक करें, ताकि आपको हमेशा पता रहे कि कौन-सा बदलाव किस चीज़ को तोड़ गया।
टूल्स के ऐसे सेट के लिए, जिसे आप दोबारा इस्तेमाल करेंगे, फ़ाइल संपादित करें। इससे आप वे विकल्प भी सेट कर सकते हैं जिनके लिए CLI प्रॉम्प्ट नहीं करता। ये सबसे ज़्यादा मायने रखने वाले विकल्प हैं:
| फ़ील्ड | डिफ़ॉल्ट | यह क्या करता है |
|---|---|---|
startup_timeout_sec | 10 | Codex सर्वर के शुरू होने का कितना इंतज़ार करता है |
tool_timeout_sec | 60 | एक अकेली टूल कॉल कितनी देर चल सकती है |
enabled | on | सर्वर को बिना हटाए बंद करता है |
required | off | अगर सर्वर इनिशियलाइज़ न हो पाए तो स्टार्टअप विफल कर देता है |
enabled_tools | all | टूल्स की अलाउ लिस्ट जिन्हें Codex इस्तेमाल कर सकता है |
disabled_tools | none | टूल्स की डिनाय लिस्ट जिन्हें Codex इस्तेमाल नहीं कर सकता |
default_tools_approval_mode | varies | auto, prompt, writes, या approve |
हर जुड़ा सर्वर असिस्टेंट के छू सकने वाली चीज़ों का दायरा बढ़ाता है। कुछ आदतें इसे संभालने योग्य रखती हैं।
एक सर्वर दर्जनों टूल्स दिखा सकता है, और आपको शायद ही उन सब की ज़रूरत पड़ती है। ठीक-ठीक सूची बनाने के लिए enabled_tools इस्तेमाल करें कि Codex क्या कॉल कर सकता है, या खतरनाक कुछ टूल्स हटाने के लिए disabled_tools इस्तेमाल करें। छोटी टूल सूची का मतलब मॉडल के लिए पढ़ने को कम टेक्स्ट और गलत चुनाव की कम संभावना भी है।
required = true को केवल उन सर्वरों पर लगाएँ जिनके बिना कोई काम नहीं हो सकता। अगर कोई ऐसा सर्वर स्टार्ट न हो जो ज़रूरी नहीं पर उपयोगी है, तो आप चाहेंगे कि Codex चलता रहे, रुके नहीं।
default_tools_approval_mode फ़ील्ड डॉक्यूमेंटेशन में चार मान लेता है: auto, prompt, writes, और approve। किसी पर भरोसा करने से पहले हर एक का सटीक व्यवहार रेफ़रेंस पेज पर पढ़ लें। एक सामान्य नियम के तौर पर, जो भी सर्वर चीज़ें बना, बदल या हटा सकता है उसके लिए एक पूछने वाला मोड इस्तेमाल करें, और केवल-पढ़ने वाले डॉक्स सर्वरों को ढीली सेटिंग पर रखें।
💡 एक समझदार शुरुआती नीति: docs सर्वरों को ढीले मोड पर रखें, GitHub और Playwright को पूछने वाले मोड पर सेट करें, और डेटाबेस सर्वरों को केवल-पढ़ने वाला रखें जिसमें लिखना बंद हो।
Codex लैंडिंग पेज लिख सकता है, लेकिन हीरो इमेज नहीं बना सकता। PicassoIA एक MCP कनेक्शन और डेवलपर API देता है, ताकि असिस्टेंट उसी काम के हिस्से के रूप में विज़ुअल्स बना सके। कनेक्शन का विवरण आपके PicassoIA अकाउंट के MCP connections पेज पर है, जिसके लिए लॉगिन ज़रूरी है।
API और MCP कनेक्शन के ज़रिए चार मॉडल उपलब्ध हैं:
PicassoIA के सार्वजनिक पेजों पर सर्वर URL प्रकाशित नहीं है, इसलिए उसे अपने अकाउंट से कॉपी करें। अगर वह रिमोट URL देता है, तो उसे ऊपर दिखाए गए --url फ़्लैग के साथ रजिस्टर करें, फिर किसी वर्कफ़्लो को उस पर बनाने से पहले पुष्टि करें कि वह /mcp में दिखता है।
API असिंक्रोनस है: आप एक प्रेडिक्शन बनाते हैं, उसकी स्थिति पोल करते हैं, फिर परिणाम लाते हैं। इन सीमाओं के हिसाब से योजना बनाएँ:
कनेक्शन काम करने लगे तो एक प्रॉम्प्ट पैटर्न आज़माने लायक है: Codex से पेज का हीरो सेक्शन बनवाएँ, फिर इमेज टूल को 16:9 फ़ोटोग्राफ़िक प्रॉम्प्ट के साथ कॉल करवाएँ जो पेज के विषय से मेल खाए, और अंत में लौटाए गए इमेज URL को मार्कअप में रेफ़रेंस करवाएँ। एक काम, टैब बदलने की ज़रूरत नहीं, और इमेज का ब्रीफ़ उसी कॉन्टेक्स्ट से आता है जिससे कॉपी बनी है।
अगर Codex के भीतर इमेज जनरेशन कॉल टाइम आउट हो जाए, तो उस सर्वर के लिए tool_timeout_sec बढ़ाएँ। प्राइसिंग पेज और API डॉक्यूमेंटेशन पहुँच को थोड़े अलग शब्दों में बताते हैं, इसलिए उस पर निर्भर होने से पहले अपने अकाउंट के लिए प्लान की ज़रूरतें जाँच लें।
टेक्स्ट वाले हिस्से के लिए PicassoIA GPT 5.6 Sol और Claude Sonnet 5 जैसे चैट मॉडल भी होस्ट करता है, जो AGENTS.md का ड्राफ़्ट बनाने या Codex को काम सौंपने से पहले दो तरीकों की तुलना करने में काम आते हैं।
bearer_token_env_var या env_vars इस्तेमाल करें ताकि सीक्रेट्स उस फ़ाइल से बाहर रहें जिसे आप कमिट कर सकते हैं।npx रन में एक पैकेज डाउनलोड होता है, और दस सेकंड कम पड़ सकते हैं। startup_timeout_sec बढ़ाएँ।/mcp को कभी न जाँचना। जो सर्वर चुपचाप स्टार्ट होने में विफल हुआ, वह बिल्कुल उस सर्वर जैसा दिखता है जिसे Codex ने इस्तेमाल न करने का फ़ैसला किया।छोटी सूची से तीन सर्वर चुनें, उन्हें रजिस्टर करें, और Codex को एक असली काम दें: एक फ़ेल होता टेस्ट, पुरानी डिपेंडेंसी, या मोबाइल पर गलत दिखने वाला पेज। एक घंटे के भीतर आपको पता चल जाएगा कि कौन-से सर्वर अपनी जगह के लायक हैं।
फिर एक कदम और आगे जाएँ। PicassoIA खोलें, PicassoIA Image से हीरो इमेज बनाएँ, और उसे Codex के अभी बनाए पेज में डालें। अलग-अलग प्रॉम्प्ट आज़माएँ, नतीजे पर एडिटर आज़माएँ, और देखें कि एक ही बार बैठकर कितना लॉन्च पूरा हो सकता है।
अपनी भाषा चुनें
