छोटा जवाब
जब MCP टूल कॉल का टाइमआउट होता है, तो आप नहीं बता सकते कि बदलाव हुआ या नहीं। हो सकता है आपके AI का जवाब खो गया हो, काम नहीं। दोबारा कोशिश से पहले जाँचें: टूल में देखें कि उसने क्या बनाना चाहा था। वह न मिले, तभी दोबारा करें। भेजने वाली कार्रवाई अपने आप कभी दोबारा न करें।
इस गाइड में
टाइमआउट से यह क्यों पता नहीं चलता कि बदलाव हुआ या नहीं?
आपके AI ने टूल से एक बदलाव करने को कहा, फिर इंतज़ार किया। कोई जवाब नहीं आया, तो आपका AI ऐप इंतज़ार छोड़कर विफलता दर्ज करता है। वह लेबल इंतज़ार के बारे में बताता है, बदलाव के बारे में नहीं। जो बदलाव पहले ही हो चुका है, उसे दोबारा करें तो दो टिकट, दो पेज या दो संदेश बन जाते हैं।
डेवलपर ऐसे बदलाव को write कहते हैं। तीन बातें हो सकती हैं।
| क्या हुआ | क्या बदलाव टूल में है? | दोबारा कोशिश करने पर |
|---|---|---|
| अनुरोध कभी पहुँचा ही नहीं। | नहीं। | सही कदम: बदलाव एक बार होता है। |
| टूल अभी भी काम कर रहा है। | अभी नहीं। यह तब दिखता है जब आपका AI हार मान चुका हो। | बदलाव दो बार होता है, जब तक उसे दोहराना नुकसानरहित न हो। |
| टूल काम पूरा कर चुका, और जवाब खो गया। | हाँ। | बदलाव दो बार होता है, जब तक उसे दोहराना नुकसानरहित न हो। |
MCP specification इसकी उम्मीद रखती है। क्लाइंट को हर अनुरोध पर टाइमआउट सेट करना चाहिए, और समय पूरा होने पर अनुरोध रद्द करके इंतज़ार छोड़ देना चाहिए। रद्द करना कोई गारंटी नहीं। सर्वर उसे अनदेखा कर सकता है, जब काम पूरा हो चुका हो या रोका न जा सके। वह जवाब भेजे जाने के बाद भी पहुँच सकता है।
Stripe की API गाइड भी यही कहती है: कनेक्शन टूटने के बाद आपको पता न हो कि अनुरोध चला या नहीं। वह सर्वर की गड़बड़ी को भी नतीजा अज्ञात मानने को कहती है।
टाइमआउट के बाद क्या करें, क्रम से?
ये क्रम से करें। पहले दो में एक मिनट लगता है।
- दोबारा कोशिश रोकेंअभी
अपने AI को बताएँ कि कॉल दोहराए नहीं: “Don’t retry. First check whether it was made.” अकेली दोबारा कोशिश ही वह तरीका है जिससे बदलाव दो बार होता है।
- टूल में देखें, चैट में नहीं1 मिनट
टूल खुद खोलें: Notion का पेज, GitHub के issues, फ़ोल्डर। जिस शीर्षक या id को आपने माँगा था, उसे खोजें। चैट सिर्फ़ इतना जानती है कि कॉल विफल हुई।
- जो मिला उसे पढ़ें2 मिनट
मिला और पूरा है: बदलाव हो चुका है। आगे बढ़ें और उसे दोहराएँ नहीं।
मिला, आधा हुआ है: छूटा हिस्सा किसी अपडेट से पूरा करें, नए बनाने से नहीं।
नहीं मिला: या तो वह पहुँचा ही नहीं, या अभी चल रहा है। एक मिनट रुककर फिर देखें। - एक बार दोबारा कोशिश करें, और सिर्फ़ सुरक्षित कॉलफिर
अगर अब भी नहीं मिला, तो एक बार दोबारा कोशिश करें। नीचे की तालिका बताती है कि कौन सी कॉल दोहराना सुरक्षित है। भेजने से पहले देखें कि वह कहाँ पहुँचता है।
- अगर बार-बार टाइमआउट हो, तो कारण ठीक करेंबाद में
जो कॉल हमेशा टाइमआउट होती है, उसकी सीमा बहुत छोटी है या काम बहुत बड़ा। उस सर्वर के लिए सीमा बढ़ाएँ, या हर कॉल में कम काम माँगें।
कौन सी कॉल दोबारा कोशिश के लिए सुरक्षित है?
कोई कॉल दोबारा कोशिश के लिए सुरक्षित है, जब दो बार करने से नतीजा वही रहे जो एक बार करने से होता। पढ़ना इसमें आता है। कई बदलाव नहीं आते। HTTP मानक PUT (कोई मान सेट करना) और DELETE को दोहराने के लिए सुरक्षित मानता है, और नीचे की पंक्तियाँ उसी को मानती हैं। किसी टूल का अपना idempotentHint या विवरण इनसे ऊपर है।
| कॉल | क्या ऐसे ही दोबारा करें? | पहले कैसे जाँचें |
|---|---|---|
| पढ़ना: खोजना, सूची, खोलना | हाँ। इससे कुछ नहीं बदलता। | जाँचने को कुछ नहीं। |
| कोई मान सेट करना: स्टेटस, शीर्षक, लेबल | आमतौर पर हाँ। एक ही मान दो बार सेट करने से नतीजा वही रहता है, जैसे HTTP PUT में। | उस फ़ील्ड को पढ़कर। अगर उसके बाद किसी इंसान ने उसे बदला है, तो दोबारा कोशिश उनका बदलाव ऊपर लिख देगी। |
| किसी चीज़ में जोड़ना: टिप्पणी, पंक्ति, लाइन | नहीं। दो बार करने से वह दो बार जुड़ेगा। | आइटम खोलकर अपना जोड़ा हुआ हिस्सा ढूँढकर। |
| बनाना: पेज, issue, फ़ाइल | नहीं। दोबारा कोशिश से दूसरा बन जाएगा। | उस शीर्षक या id से खोजकर, जो आपने दिया था। दोबारा कोशिश तभी करें जब कुछ भी न मिले। |
| हटाना | आमतौर पर, जब वह एक ठीक-ठीक आइटम का नाम ले, जैसे HTTP DELETE की तरह। “सबसे नया” नहीं: दूसरी कॉल किसी और आइटम पर लगेगी। | आइटम ढूँढकर। नहीं मिला, मतलब हो गया। |
| भेजना: संदेश, ईमेल, सूचना | अपने आप कभी नहीं। भेजा गया संदेश वापस नहीं लिया जा सकता। | देखें कि वह कहाँ पहुँचा: भेजे गए की सूची, चैनल, दूसरी तरफ़। अगर पता न चले, तो दोबारा भेजने से पहले पूछें। |
क्या idempotency key डुप्लिकेट रोक सकती है?
कभी-कभी। idempotency key एक अनोखा लेबल है जो अनुरोध के साथ भेजा जाता है। अगर वही लेबल दो बार आए, तो सेवा काम एक बार करती है और पहला जवाब दोहरा देती है। यह उस अनुरोध के लिए बना है जिसका कोई जवाब नहीं आया।
- Stripe पर key कैसे काम करती है। उसके v1 API में
POSTअनुरोधों पर key ली जाती है। वह पहला नतीजा सहेजती है, गड़बड़ी भी, और उसी key के साथ दोबारा कोशिश पर वही लौटाती है। वह key कम से कम 24 घंटे रखती है। वही key दूसरे पैरामीटर के साथ आए, तो वह ठुकरा दी जाती है। - दोबारा कोशिश में क्या करना है। वही key और वही पैरामीटर भेजें। Stripe कहता है कि पहले नतीजे का पता चलने तक नई key के साथ दोबारा कोशिश न करें। हर कोशिश पर नई key से कोई सुरक्षा नहीं मिलती।
- MCP आपको क्या देता है।
tools/callअनुरोध में एक टूल का नाम और उसके arguments होते हैं। specification की schema इसके लिए कोई idempotency key तय नहीं करती। फिर भी टूल उसे अपने एक argument के रूप में ले सकता है, इसलिए उसके arguments पढ़ें। - टूल क्या घोषित कर सकता है।
idempotentHintबताता है कि वही arguments के साथ टूल दोबारा बुलाने का कोई अतिरिक्त असर नहीं होता। यह सिर्फ़ एक संकेत है। specification कहती है कि क्लाइंट को ऐसे सर्वर के संकेतों पर फ़ैसले कभी नहीं टिकाने चाहिए जिन पर उसे भरोसा नहीं।
तो key एक बोनस है, योजना नहीं। जब टूल कोई key नहीं देता, तो ऊपर की जाँच आपकी रक्षा करती है।
MCP का टाइमआउट कैसे बदलें?
बहुत छोटी सीमा ईमानदार काम को काट देती है। बहुत लंबी सीमा आपको इंतज़ार में रखती है। इसे कहाँ सेट करना है, यह आपके AI ऐप पर निर्भर है। यहाँ Claude Code की सेटिंग्स हैं।
| सेटिंग | क्या सीमित करती है | डिफ़ॉल्ट |
|---|---|---|
MCP_TOOL_TIMEOUT | एक टूल कॉल कितनी देर चल सकती है, मिलीसेकंड में। | 100000000 ms, लगभग 28 घंटे |
.mcp.json में timeout | वही, एक सर्वर के लिए। यह उस सर्वर के लिए वेरिएबल को बदल देती है। यह सख़्त सीमा है: प्रगति की सूचनाएँ इसे नहीं बढ़ातीं। | वेरिएबल की वैल्यू |
CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT | कॉल कितनी देर बिना जवाब और बिना प्रगति के चुप रह सकती है, इससे पहले वह रुक जाए। 0 से यह जाँच बंद होती है। | नेटवर्क सर्वर के लिए 5 मिनट, stdio के लिए 30 मिनट |
MCP_TIMEOUT | सर्वर शुरू करना। रिमोट सर्वर के लिए यह नीचे वाले हर अनुरोध के टाइमर में भी गिना जाता है। | 30000 ms, 30 सेकंड |
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS | जब मुख्य बातचीत में चलती कॉल बैकग्राउंड टास्क में चली जाती है। 0 से यह बंद होती है। वर्शन 2.1.212 या उसके बाद का। | 120000 ms, 2 मिनट |
रिमोट सर्वर का 60 सेकंड का डिफ़ॉल्ट। HTTP, SSE या claude.ai कनेक्टर के रूप में पहुँचने वाले सर्वर के पास एक दूसरा टाइमर है। यह हर अनुरोध पर चलता है, सर्वर के पहले response byte तक। यह 60 सेकंड का होता है, जब तक MCP_TOOL_TIMEOUT, सर्वर का timeout या MCP_TIMEOUT उससे ऊँचा सेट न हो। लोकल stdio सर्वरों पर हर अनुरोध का टाइमर नहीं होता।
किसी एक सर्वर के लिए यह सेट करने के लिए, .mcp.json में उसकी प्रविष्टि में "timeout": 600000 जोड़ें। यह दस मिनट है।
धीमी कॉल हमेशा विफल कॉल नहीं होती। वर्शन 2.1.212 से, Claude Code आपकी मुख्य बातचीत की MCP कॉल को दो मिनट बाद बैकग्राउंड टास्क में डाल देता है। कॉल खत्म होने पर वह नतीजा पहुँचाता है।
Cursor के MCP डॉक्यूमेंटेशन में कोई टाइमआउट सेटिंग नहीं बताई गई है। MCP specification कोई संख्या नहीं देती। वह कहती है कि SDK को हर अनुरोध के लिए टाइमआउट सेट करने दे, और क्लाइंट को हमेशा एक अधिकतम सीमा रखनी चाहिए।
जिस काम में मिनट लगते हैं, उसके लिए सर्वर MCP Tasks इस्तेमाल कर सकता है। वह तुरंत एक हैंडल लौटाता है, और क्लाइंट दोबारा जुड़ने के बाद भी नतीजे के लिए बार-बार पूछता है। दोनों तरफ़ इसका सपोर्ट होना चाहिए, और क्लाइंट का सपोर्ट अलग-अलग है।
जब जवाब खो जाए, तो Delta MCP क्या करता है?
Delta MCP आपके कंप्यूटर पर एक मुफ़्त ऐप है, जो आपके AI और उसके टूल के बीच बैठता है। जब कोई बदलाव बिना जवाब के रहे, तो वह अंदाज़ा नहीं लगाता और सिर्फ़ दोबारा भी नहीं भेजता। वह टूल को पढ़ता है।
बदलाव बाहर जाने से पहले, Delta MCP एक ऐसी पढ़ाई चुनता है जो दिखा सके कि बदलाव हुआ या नहीं। यह वही आइटम दोबारा पढ़ना होता है, या सूची दोबारा पढ़ना। जब जवाब न आए, तो वह यह पढ़ाई तुरंत चलाता है। जो पढ़ाई दिखाती है, वही फ़ैसला करती है:
| पढ़ाई में क्या दिखता है | Delta MCP क्या करता है |
|---|---|
| बदलाव हो चुका है। | काम आगे चलता है, और जवाब बताता है कि उसकी जाँच हो गई। |
| बदलाव नहीं हुआ है। | वही arguments के साथ बदलाव एक बार और भेजता है। संदेश या किसी और भेजने वाले काम के लिए वह यह अपने आप कभी नहीं करता। उनके लिए जवाब बताता है कि वह नहीं दिखा, हो सकता है वह अब भी दिखे, और काम रुक जाता है। |
| अस्पष्ट है, या बताने के लिए कुछ भी पढ़ा नहीं जा सकता। | जवाब बताता है कि नतीजा अज्ञात है, और क्यों। काम रुक जाता है। बदलाव दोबारा करने से पहले टूल को देखें। |
जो कॉल हो चुकी, उसे Delta MCP पलटकर वापस नहीं कर सकता। अगर पहले की कोई कॉल सफल हुई, तो वह बनी रहती है, और जवाब उसे सूची में डालता है ताकि आपका AI उसे दोहराए नहीं। हर काम जो कुछ बदलता है, Activity में हर बदलाव के पहले और बाद के साथ रखा जाता है।
काम कैसे जाँचा और लागू किया जाता है
सवाल
टाइमआउट के बाद MCP टूल कॉल दोबारा करना सुरक्षित है?
पढ़ना सुरक्षित है। बदलाव तब तक नहीं, जब तक आप जाँच न लें। टाइमआउट सिर्फ़ इतना बताता है कि कोई जवाब नहीं आया: टूल फिर भी बदलाव कर चुका हो सकता है। टूल में उसे देखें, और दोबारा तभी करें जब वह न मिले। भेजने वाली कार्रवाई अपने आप कभी दोबारा न करें।
अनुरोध का टाइमआउट हुआ, तो क्या MCP से किया गया बदलाव हो गया?
टाइमआउट से यह पता नहीं चलता। हो सकता है अनुरोध कभी पहुँचा ही न हो, टूल अब भी काम कर रहा हो, या वह काम पूरा कर चुका हो और जवाब खो गया हो। टूल खोलें और बदलाव देखें।
Claude Code में MCP टूल का टाइमआउट कैसे बढ़ाएँ?
MCP_TOOL_TIMEOUT को मिलीसेकंड में सेट करें, या .mcp.json में सर्वर की प्रविष्टि में timeout फ़ील्ड जोड़ें। रिमोट सर्वर के लिए इसे 60000 से ऊपर रखें, ताकि 60 सेकंड वाला हर-अनुरोध का टाइमर हट जाए। MCP_TIMEOUT शुरू होने के इंतज़ार की सीमा है, टूल कॉल की सीमा नहीं।
Cursor में MCP का टाइमआउट कैसे बदलें?
Cursor के MCP डॉक्यूमेंटेशन में कोई टाइमआउट सेटिंग नहीं बताई गई है। वह कहता है कि विफल कॉल चैट में विफल दिखती है, और आप दोबारा कोशिश कर सकते हैं या लॉग देख सकते हैं। पहले देखें कि टूल में अभी क्या है।
क्या MCP में idempotency key होती है?
नहीं। टूल कॉल में एक टूल का नाम और arguments होते हैं, और specification की schema उसके लिए कोई idempotency key तय नहीं करती। टूल अपनी key को एक argument के रूप में ले सकता है। वह idempotentHint भी सेट कर सकता है, जो सिर्फ़ एक संकेत है।
जब टूल कॉल का कोई जवाब न आए, तो Delta MCP क्या करता है?
वह तुरंत टूल को पढ़ता है, यह देखने के लिए कि बदलाव हुआ या नहीं। हुआ: काम आगे चलता है। नहीं हुआ: बदलाव एक बार और भेजता है। संदेश या कोई और भेजने वाला काम अपने आप कभी दोबारा नहीं भेजा जाता। अस्पष्ट: जवाब बताता है कि नतीजा अज्ञात है, और काम रुक जाता है।
स्रोत
- Model Context Protocol, Cancellation क्लाइंट को टाइमआउट सेट करने, रद्द करने और इंतज़ार छोड़ने चाहिए; रद्द करना काम पूरा होने के बाद पहुँच सकता है (संशोधन 2026-07-28)।
- Model Context Protocol, Schema Reference टूल कॉल में नाम और arguments होते हैं, idempotency key नहीं; idempotentHint एनोटेशन, और एनोटेशन सिर्फ़ संकेत हैं (संशोधन 2026-07-28)।
- Model Context Protocol, Tasks लंबे काम के लिए टिकाऊ हैंडल, जिसे दोबारा जुड़ने के बाद बार-बार पूछकर लिया जाता है; दोनों तरफ़ इसे चालू करना होता है।
- Claude Code, Connect Claude Code to tools via MCP हर सर्वर का टाइमआउट, रिमोट सर्वरों का 60 सेकंड वाला हर-अनुरोध टाइमर, निष्क्रियता की अवधि, दो मिनट बाद बैकग्राउंड में जाना।
- Claude Code, Environment variables MCP_TOOL_TIMEOUT, MCP_TIMEOUT, CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT और CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS, उनके डिफ़ॉल्ट के साथ।
- Cursor, Model Context Protocol (MCP) विफल MCP कॉल चैट में विफल दिखती है; दोबारा कोशिश या लॉग देखें; कोई टाइमआउट सेटिंग बताई नहीं गई।
- Stripe, Idempotent requests idempotency key कैसे काम करती है: पहला नतीजा सहेजा और दोबारा लौटाया जाता है; key कम से कम 24 घंटे रहती है; दूसरे पैरामीटर ठुकराए जाते हैं।
- Stripe, Advanced error handling कनेक्शन टूटने के बाद पता न हो कि अनुरोध चला या नहीं; सर्वर की गड़बड़ी अज्ञात नतीजा है; नतीजा पता चलने से पहले नई key नहीं।
- IETF, RFC 9110: HTTP Semantics Idempotent तरीके (सुरक्षित तरीके, PUT और DELETE), और गैर-idempotent अनुरोध को तब तक दोबारा न भेजना, जब तक यह न पता हो कि पहला लागू ही नहीं हुआ।
- Delta MCP, Writing a task बदलाव को जवाब न मिले तो Delta MCP क्या करता है: हुआ, नहीं हुआ या नतीजा अज्ञात; भेजने वाला काम अपने आप दोबारा नहीं भेजा जाता।
- Delta MCP, Activity and Undo हर काम जो कुछ बदलता है, Activity में हर बदलाव के पहले और बाद के साथ रहता है।
आगे पढ़ें
- AI एजेंट के बदलाव वापस कैसे लें: Notion, GitHub और फ़ाइलेंAI एजेंट ने कुछ बदला या हटा दिया? देखें क्या बदला, उसे Notion, GitHub या अपनी फ़ाइलों में वापस कैसे लें, और क्या कभी वापस नहीं लिया जा सकता।
- AI एजेंट के लिए MCP vs CLI: टोकन का बिल कहाँ से आता हैआपके AI एजेंट के लिए MCP या CLI? टोकन में किसका कितना खर्च होता है, माप क्या दिखाते हैं, कब CLI जीतता है, कब MCP, और कहाँ कोड दोनों से आगे निकलता है।
