ऐसे MCP सर्वर की समस्या ठीक करें जो शुरू नहीं हो पा रहा या टास्क हल नहीं कर पा रहा
solvethree_capabilities से शुरू करें, जिसके लिए API कुंजी की ज़रूरत नहीं है। अगर यह प्रतिक्रिया देता है, तो सर्वर शुरू हो चुका है और MCP कनेक्शन काम कर रहा है। लॉन्चर सेटिंग बदलना बंद करें और इसके बजाय क्रेडेंशियल, प्रॉक्सी और टास्क इनपुट जाँचें।
इस पेज पर
लॉन्चर को होस्ट के बाहर चलाएँ
दिए गए लॉन्चर को उस मशीन के टर्मिनल में चलाएँ जिस पर आपका MCP होस्ट चलता है। समस्या को नियंत्रित परिस्थितियों में दोहराने के लिए Node.js 22 और उसके साथ आए npx का उपयोग करें; जाँचें कि आप किसी पुराने, अलग से इंस्टॉल किए गए लॉन्चर का उपयोग तो नहीं कर रहे हैं।
node --version
npx --yes --package=https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz solvethree-mcp
# The process waits for JSON-RPC on stdin. Silence is not a failed startup.
# Use the MCP host to initialize and list tools. Press Ctrl-C to stop this check.
# Never paste an API key or proxy password into troubleshooting logs.बिना कुछ प्रिंट किए खुली रहने वाली प्रोसेस ज़रूरी नहीं कि अटक गई हो। यह स्थानीय stdio सर्वर है: यह stdin पर MCP JSON-RPC संदेशों की प्रतीक्षा करता है। कनेक्शन इनिशियलाइज़ करने और टूल की सूची पाने के लिए अपने MCP होस्ट का उपयोग करें; केवल एक्ज़ीक्यूटेबल चलाने से वह हैंडशेक नहीं होता।
अगर यह बंद हो जाए, तो पहले लॉन्च त्रुटि पढ़ें। एक्ज़ीक्यूटेबल न मिलने की त्रुटि इंस्टॉलेशन या PATH की समस्या बताती है; पैकेज डाउनलोड की त्रुटि टास्क हल होने से पहले आती है। इनमें से कोई भी गलत API कुंजी, प्रॉक्सी या साइट प्रोफ़ाइल का प्रमाण नहीं है।
अगर टर्मिनल में काम करता है, लेकिन होस्ट में नहीं
solvethree को स्थानीय stdio सर्वर के रूप में रजिस्टर करें, रिमोट HTTP एंडपॉइंट के रूप में नहीं। होस्ट को लॉन्चर उदाहरण में दिखाए गए आर्ग्युमेंट के साथ npx चलाना चाहिए। कोई होस्टेड MCP एंडपॉइंट नहीं है।
- होस्ट को npx नहीं मिल रहा है।
होस्ट के PATH की तुलना अपने टर्मिनल के PATH से करें। डेस्कटॉप एप्लिकेशन को आपके शेल का सेटअप विरासत में मिले, यह ज़रूरी नहीं है।
यह आज़माएँ: npx वाली डायरेक्टरी को होस्ट के लिए उपलब्ध कराएँ या स्थानीय रूप से काम करने वाले उसी एक्ज़ीक्यूटेबल का पूर्ण पाथ कॉन्फ़िगर करें।
- होस्ट Node.js या npx का अलग संस्करण चला रहा है।
जाँचें कि होस्ट को कौन-से एक्ज़ीक्यूटेबल मिल रहे हैं, सिर्फ़ यह नहीं कि आपका टर्मिनल कौन-से संस्करण उपयोग करता है।
यह आज़माएँ: होस्ट को परीक्षण किए गए इंस्टॉलेशन का उपयोग करने के लिए सेट करें। उसका एनवायरनमेंट बदलने के बाद होस्ट को रीस्टार्ट करें।
- इनिशियलाइज़ेशन में अमान्य JSON या अप्रत्याशित आउटपुट की सूचना मिलती है।
stdout पर लिखे जा रहे शेल बैनर, रैपर संदेश या डीबग प्रिंट जाँचें।
यह आज़माएँ: stdout को MCP JSON-RPC के लिए आरक्षित रखें। निदान संबंधी आउटपुट stderr पर भेजें, जहाँ होस्ट उसे प्रोटोकॉल ट्रैफ़िक समझे बिना एकत्र कर सके।
- स्टार्टअप के दौरान होस्ट प्रतीक्षा करना बंद कर देता है।
स्टार्टअप लॉग जाँचें और धीमे लॉन्च व पहले ही बंद हो चुकी प्रोसेस के बीच अंतर पहचानें।
यह आज़माएँ: Codex-शैली के कॉन्फ़िगरेशन में startup_timeout_sec के लिए दस्तावेज़ित मान 60 का उपयोग करें। ज़्यादा देर प्रतीक्षा करने से गायब एक्ज़ीक्यूटेबल या स्पष्ट लॉन्च त्रुटि ठीक नहीं होगी।
- होस्ट कहता है कि solvethree का एक टूल रजिस्टर नहीं है।
पुष्टि करें कि सर्वर इनिशियलाइज़ हुआ है और डिस्कवरी से मिले टूल की जाँच करें।
यह आज़माएँ: सर्वर रजिस्ट्रेशन ठीक करें या दोबारा कनेक्ट करके टूल डिस्कवरी फिर से करें। किसी टूल का गायब होना API प्रमाणीकरण त्रुटि या समाधान की विफलता नहीं है।
सर्वर solvethree_capabilities, solvethree_create_recaptcha, solvethree_create_kasada, solvethree_create_tmpt और solvethree_get_task उपलब्ध कराता है। अगर डिस्कवरी सफल होती है, लेकिन होस्ट इनमें से किसी नाम को कॉल नहीं कर पाता, तो टास्क अनुरोध भेजने से पहले यह असंगति दूर करें।
अगर टूल काम करते हैं, लेकिन टास्क नहीं बनता
- 1.
होस्ट प्रोसेस का एनवायरनमेंट जाँचें
होस्ट के एनवायरनमेंट के ज़रिए SOLVETHREE_API_KEY और SOLVETHREE_PROXY उपलब्ध कराएँ। किसी अलग टर्मिनल में वेरिएबल एक्सपोर्ट करने से यह सुनिश्चित नहीं होता कि होस्ट उसे पढ़ सकता है। Codex-शैली के कॉन्फ़िगरेशन में env_vars में दोनों नाम शामिल होने चाहिए; यह पास-थ्रू सूची उनके मान उपलब्ध नहीं कराती। कुंजी या प्रॉक्सी क्रेडेंशियल प्रिंट किए बिना जाँचें कि वे मौजूद हैं।
- 2.
प्रॉक्सी की जाँच वहीं करें जहाँ टूल उसे वास्तव में पढ़ता है
solvethree_create_recaptcha अपनी एकमात्र प्रॉक्सी SOLVETHREE_PROXY से पढ़ता है। एनवायरनमेंट में मान न होने की समस्या को ठीक करने के लिए उस टूल में proxy आर्ग्युमेंट जोड़ने की कोशिश न करें। प्रॉक्सी URL को HTTP या HTTPS इस्तेमाल करना चाहिए और उसमें पाथ, क्वेरी या फ़्रैगमेंट नहीं होना चाहिए।
- 3.
reCAPTCHA साइट प्रोफ़ाइल जाँचें
API कुंजी से पहचाने जाने वाले वर्कस्पेस में अनुरोधित साइट और reCAPTCHA प्रकार के लिए एक सक्रिय प्रोफ़ाइल होनी चाहिए। कैप्चर एक्शन भी जाँचें: एक सामान्य होस्टनेम प्रोफ़ाइल ज़रूरी नहीं कि हर एक्शन के लिए काम करे। टास्क में site और action देने से प्रोफ़ाइल नहीं बनती। इसे ठीक करने के लिए कंसोल के साइट प्रोफ़ाइल पेज या प्रोफ़ाइल सेटअप गाइड का उपयोग करें।
- 4.
टूल के इनपुट जाँचें
solvethree_create_recaptcha के लिए site को होस्टनेम के रूप में दें, साथ में action और requestId दें। recaptchaType वैकल्पिक है और उसका डिफ़ॉल्ट enterprise-v3 है। site की जगह पेज URL न दें और इस टूल में API के अन्य टास्क प्रकार न जोड़ें।
क्षमताओं की खोज से प्रमाणीकरण या प्रॉक्सी ऐक्सेस की जाँच नहीं होती। capabilities कॉल सफल होने के बाद आने वाली प्रमाणीकरण या अनुरोध-सत्यापन त्रुटि समाधान के अनुरोध से संबंधित है, लॉन्चर से नहीं। किसी रिस्पॉन्स को सफल टास्क पेलोड मानने से पहले असफल HTTP रिस्पॉन्स को हैंडल करें।
विफल टास्क और टाइम आउट हुई कॉल में अंतर करें
| परिणाम | अगली कार्रवाई |
|---|---|
| pending या solving | टास्क अभी पूरा नहीं हुआ है। उसकी जगह नया टास्क बनाने के बजाय solvethree_get_task से उसे प्राप्त करें। |
| failed | errorCode और error पढ़ें, फिर उस टास्क की पोलिंग बंद करें। उदाहरण के लिए, site-unreachable एक टास्क त्रुटि है। विफल समाधानों का शुल्क वापस किया जाता है; यह न मानें कि हर विफलता का मतलब अपर्याप्त क्रेडिट है। |
| तैयार | समाधान उपलब्ध है। MCP सर्वर ब्राउज़र नहीं चलाता और न ही फ़ॉर्म भरता है, और समाधान तैयार होने से यह साबित नहीं होता कि लक्ष्य ने कुछ स्वीकार किया है। |
होस्ट का टाइमआउट टास्क की स्थिति नहीं है। Codex-शैली का कॉन्फ़िगरेशन tool_timeout_sec का मान 100 इस्तेमाल करता है, लेकिन रिस्पॉन्स खो जाने से भी यह साबित नहीं होता कि टास्क बनाना विफल हुआ। हर create टूल को requestId चाहिए और वह अधिकतम एक टास्क बनाता है।
अगर आपको टास्क ID मिला है, तो उस टास्क को प्राप्त करें। अन्यथा, मौजूदा टास्क वापस पाने के लिए उसी requestId के साथ वही create अनुरोध दोहराएँ। केवल कॉल टाइम आउट होने के कारण नया requestId न बनाएँ। बदले हुए टास्क इनपुट के साथ ID दोबारा इस्तेमाल करने पर टकराव होता है।
टास्क तैयार होने पर, लौटाई गई ब्राउज़र पहचान और सफल प्रॉक्सी के साथ उसका समाधान सबमिट करें। अगर वेबसाइट उसके बाद अनुरोध अस्वीकार करती है, तो MCP स्टार्टअप के बजाय उस सबमिशन की जाँच करें। समाधान का डेटा निजी रखें: MCP होस्ट को यह डेटा मिलता है।
स्रोत और API संदर्भ
अपना पहला टास्क चलाएँ।
$5 वर्कस्पेस क्रेडिट के साथ शुरुआत करें।