مختصر جواب
جب MCP ٹول کال ٹائم آؤٹ ہوتی ہے تو پتا نہیں چلتا کہ تبدیلی ہوئی یا نہیں۔ ہو سکتا ہے جواب گم ہوا ہو، کام نہیں۔ دوبارہ کوشش سے پہلے ٹول میں دیکھیں کہ کیا بنانا تھا۔ صرف نہ ملے تو دوبارہ کوشش کریں۔ کوئی بھیجنے کا عمل خود سے کبھی دوبارہ نہ کریں۔
اس گائیڈ میں
ٹائم آؤٹ یہ کیوں نہیں بتاتا کہ تبدیلی ہوئی یا نہیں؟
آپ کے اے آئی نے ایک ٹول سے تبدیلی کرنے کو کہا، پھر انتظار کیا۔ کوئی جواب نہیں آیا، تو آپ کی اے آئی ایپ نے انتظار چھوڑ دیا اور ناکامی کی اطلاع دی۔ وہ لیبل انتظار کو بیان کرتا ہے، تبدیلی کو نہیں۔ جو تبدیلی پہلے ہی ہو چکی ہو، اسے دوبارہ کرنے سے دو ٹکٹ، دو صفحے یا دو پیغام بن جاتے ہیں۔
ڈویلپرز ایسی تبدیلی کو write کہتے ہیں۔ تین باتیں ہو سکتی ہیں۔
| کیا ہوا | کیا تبدیلی ٹول میں ہے؟ | دوبارہ کوشش کریں تو |
|---|---|---|
| درخواست کبھی پہنچی ہی نہیں۔ | نہیں۔ | درست کال: تبدیلی ایک بار ہوتی ہے۔ |
| ٹول ابھی تک کام کر رہا ہے۔ | ابھی نہیں۔ آپ کے اے آئی نے انتظار چھوڑنے کے بعد ظاہر ہوتی ہے۔ | تبدیلی دو بار ہوتی ہے، جب تک دہرانا نقصان دہ نہ ہو۔ |
| ٹول کام مکمل کر چکا، اور جواب گم ہو گیا۔ | ہاں۔ | تبدیلی دو بار ہوتی ہے، جب تک دہرانا نقصان دہ نہ ہو۔ |
MCP specification یہی توقع رکھتی ہے۔ کلائنٹ کو ہر درخواست پر ٹائم آؤٹ سیٹ کرنا چاہیے، اور جب وہ گزر جائے تو درخواست منسوخ کر کے انتظار بند کرنا چاہیے۔ منسوخی کی کوئی ضمانت نہیں: سرور اسے نظرانداز کر سکتا ہے جب کام ہو چکا ہو یا روکا نہ جا سکے۔ یہ جواب بھیجے جانے کے بعد بھی پہنچ سکتی ہے۔
Stripe کی API گائیڈ بھی یہی کہتی ہے: کنکشن ناکام ہونے کے بعد ہو سکتا ہے آپ کو معلوم نہ ہو کہ درخواست چلی یا نہیں۔ وہ کہتی ہے کہ سرور کی خرابی کو بھی نامعلوم نتیجہ سمجھیں۔
ٹائم آؤٹ کے بعد کیا کریں، ترتیب سے؟
یہ ترتیب سے کریں۔ پہلے دو میں ایک منٹ لگتا ہے۔
- دوبارہ کوشش روکیںابھی
اپنے اے آئی سے کہیں کہ کال دوبارہ نہ کرے: دوبارہ کوشش نہ کریں۔ پہلے جانچیں کہ کیا یہ ہو چکا ہے۔ اکیلی دوبارہ کوشش ہی وہ راستہ ہے جس سے تبدیلی دو بار ہو جاتی ہے۔
- چیٹ میں نہیں، ٹول میں دیکھیں1 منٹ
ٹول کو خود کھولیں: Notion کا صفحہ، GitHub کے issues، فولڈر۔ وہ عنوان یا id تلاش کریں جو آپ نے مانگا تھا۔ چیٹ کو صرف اتنا معلوم ہے کہ کال ناکام ہوئی۔
- جو ملے، اسے پڑھیں2 منٹ
ملا اور مکمل ہے: تبدیلی ہو چکی ہے۔ آگے بڑھیں اور اسے دہرائیں نہیں۔
ملا، آدھا ہو چکا ہے: باقی حصہ ایک update سے مکمل کریں، نئے create سے نہیں۔
نہیں ملا: یا وہ پہنچا ہی نہیں، یا ابھی چل رہا ہے۔ ایک منٹ انتظار کریں اور دوبارہ دیکھیں۔ - صرف محفوظ کال، ایک بار دوبارہ کوششپھر
اگر پھر بھی غائب ہو تو ایک بار دوبارہ کوشش کریں۔ نیچے کا جدول بتاتا ہے کہ کون سی کالز دہرانا محفوظ ہے۔ بھیجنے سے پہلے دیکھیں کہ وہ کہاں پہنچتا ہے۔
- اگر بار بار ٹائم آؤٹ ہو تو وجہ ٹھیک کریںبعد میں
جو کال ہمیشہ ٹائم آؤٹ ہوتی ہے، اس کی حد بہت چھوٹی ہے یا کام بہت بڑا۔ اس سرور کی حد بڑھائیں، یا ہر کال پر کم کام مانگیں۔
کون سی کالز دوبارہ کرنا محفوظ ہے؟
کال کو دوبارہ کرنا محفوظ ہے جب دو بار کرنے سے وہی نتیجہ نکلے جو ایک بار کرنے سے۔ پڑھنا اس میں آتا ہے۔ بہت سی تبدیلیاں نہیں آتیں۔ HTTP معیار PUT (ایک قدر سیٹ کرنا) اور DELETE کو دہرانے کے لیے محفوظ مانتا ہے، اور نیچے کی قطاریں اسی کی پیروی کرتی ہیں۔ ٹول کا اپنا idempotentHint یا تفصیل ان پر بھاری ہے۔
| کال | جوں کا توں دوبارہ کریں؟ | پہلے کیسے جانچیں |
|---|---|---|
| پڑھنا: تلاش، فہرست، کھولنا | ہاں۔ کچھ نہیں بدلتا۔ | جانچنے کو کچھ نہیں۔ |
| قدر سیٹ کرنا: اسٹیٹس، عنوان، لیبل | عموماً۔ ایک ہی قدر دو بار سیٹ کرنے سے نتیجہ وہی رہتا ہے، جیسا HTTP PUT سے۔ | فیلڈ پڑھنا۔ اگر اس کے بعد کسی شخص نے اسے بدلا ہو تو دوبارہ کوشش اس کی تبدیلی اوور رائٹ کر دے گی۔ |
| کسی چیز میں جوڑنا: تبصرہ، قطار، لائن | نہیں۔ دو بار کرنے سے دو بار جڑے گا۔ | آئٹم کھول کر اپنا اضافہ تلاش کریں۔ |
| بنانا: صفحہ، issue، فائل | نہیں۔ دوبارہ کوشش سے دوسرا بن جاتا ہے۔ | اس عنوان یا id سے تلاش کریں جو آپ نے دیا تھا۔ صرف تب دوبارہ کوشش کریں جب کوئی میچ نہ ہو۔ |
| حذف کرنا | عموماً، جب وہ ایک خاص آئٹم کا نام لے، جیسا HTTP DELETE سے۔ سب سے تازہ آئٹم نہیں: دوسری کال کسی اور آئٹم کو لگتی ہے۔ | آئٹم تلاش کریں۔ غائب ہو تو کام ہو چکا۔ |
| بھیجنا: پیغام، ای میل، نوٹیفکیشن | خود سے کبھی نہیں۔ بھیجا ہوا واپس نہیں لیا جا سکتا۔ | دیکھیں کہ وہ کہاں پہنچا: بھیجے گئے کی فہرست، چینل، دوسری طرف۔ اگر پتا نہ چل سکے تو دوبارہ بھیجنے سے پہلے پوچھیں۔ |
کیا idempotency key ڈپلیکیٹ روک سکتی ہے؟
کبھی کبھی۔ idempotency key ایک منفرد لیبل ہے جو درخواست کے ساتھ بھیجا جاتا ہے۔ اگر وہی لیبل دو بار آئے، تو سروس کام ایک بار کرتی ہے اور پہلا جواب دوبارہ لوٹا دیتی ہے۔ یہ اس درخواست کے لیے بنائی گئی ہے جس کا جواب نہ آیا ہو۔
- Stripe میں کلید کیسے کام کرتی ہے۔ اس کی v1 API
POSTدرخواستوں پر ایک کلید لیتی ہے۔ وہ پہلا نتیجہ محفوظ کرتی ہے، خواہ وہ خرابی ہی ہو، اور اسی کلید کے ساتھ دوبارہ کوشش پر وہی لوٹاتی ہے۔ کلیدیں کم از کم 24 گھنٹے رکھتی ہے۔ دوسرے پیرامیٹرز کے ساتھ وہی کلید رد ہو جاتی ہے۔ - دوبارہ کوشش کو کیا کرنا ہوتا ہے۔ وہی کلید اور وہی پیرامیٹرز بھیجیں۔ Stripe کہتا ہے کہ پہلا نتیجہ جانے بغیر نئی کلید کے ساتھ دوبارہ کوشش نہ کریں۔ ہر کوشش پر نئی کلید دینے سے کوئی حفاظت نہیں ہوتی۔
- MCP آپ کو کیا دیتا ہے۔ ایک
tools/callدرخواست میں ٹول کا نام اور اس کے آرگومنٹس ہوتے ہیں۔ specification کی schema اس کے لیے کوئی idempotency key بیان نہیں کرتی۔ ٹول پھر بھی اسے اپنے ایک آرگومنٹ کے طور پر لے سکتا ہے، اس لیے اس کے آرگومنٹس پڑھیں۔ - ٹول کیا اعلان کر سکتا ہے۔
idempotentHintبتاتا ہے کہ انہی آرگومنٹس کے ساتھ ٹول کو دوبارہ بلانے کا کوئی اضافی اثر نہیں۔ یہ صرف ایک اشارہ ہے۔ specification کہتی ہے کہ کلائنٹس کو ایسے سرورز کے اشاروں پر کبھی فیصلہ نہیں کرنا چاہیے جن پر وہ بھروسہ نہیں کرتے۔
تو کلید ایک بونس ہے، منصوبہ نہیں۔ جب ٹول کوئی پیش نہ کرے تو اوپر کی جانچ آپ کی حفاظت کرتی ہے۔
MCP ٹائم آؤٹ کیسے بدلیں؟
چھوٹی حد ایماندار کام کو کاٹ دیتی ہے۔ لمبی حد آپ کو انتظار میں رکھتی ہے۔ اسے کہاں سیٹ کرنا ہے، یہ آپ کی اے آئی ایپ پر منحصر ہے۔ یہاں Claude Code کی ترتیبات ہیں۔
| ترتیب | کیا محدود کرتی ہے | ڈیفالٹ |
|---|---|---|
MCP_TOOL_TIMEOUT | ایک ٹول کال کتنی دیر چل سکتی ہے، ملی سیکنڈ میں۔ | 100,000,000 ms، تقریباً 28 گھنٹے |
.mcp.json میں timeout | وہی، ایک سرور کے لیے۔ یہ اس سرور کے لیے متغیر کو بدل دیتی ہے۔ سخت حد: پیش رفت کی اطلاعات اسے نہیں بڑھاتیں۔ | متغیر کی قدر |
CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT | کال کتنی دیر خاموش رہ سکتی ہے، بغیر جواب اور بغیر پیش رفت کے، اس سے پہلے کہ وہ منقطع ہو جائے۔ 0 سے یہ جانچ بند ہو جاتی ہے۔ | نیٹ ورک سرورز کے لیے 5 منٹ، stdio کے لیے 30 منٹ |
MCP_TIMEOUT | سرور شروع کرنا۔ ریموٹ سرور کے لیے یہ نیچے والے فی درخواست ٹائمر میں بھی شمار ہوتا ہے۔ | 30,000 ms، 30 سیکنڈ |
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS | جب مرکزی گفتگو میں چلتی کال پس منظر کے کام میں منتقل ہو جائے۔ 0 سے یہ بند ہو جاتا ہے۔ ورژن 2.1.212 یا اس کے بعد کا۔ | 120,000 ms، 2 منٹ |
ریموٹ سرورز کے لیے 60 سیکنڈ کا ڈیفالٹ۔ HTTP، SSE یا claude.ai کنیکٹر کے طور پر پہنچنے والے سرور کا ایک دوسرا ٹائمر ہوتا ہے۔ یہ ہر درخواست پر چلتا ہے، سرور کے جواب کا پہلا بائٹ آنے تک۔ یہ 60 سیکنڈ تک رہتا ہے، جب تک MCP_TOOL_TIMEOUT، سرور کا timeout یا MCP_TIMEOUT اس سے زیادہ مقرر نہ ہو۔ مقامی stdio سرورز کا فی درخواست ٹائمر نہیں ہوتا۔
ایک سرور کے لیے اسے سیٹ کرنے کے لیے، .mcp.json میں اس کے اندراج میں "timeout": 600000 شامل کریں۔ یہ دس منٹ ہے۔
سست کال ہمیشہ ناکام کال نہیں ہوتی۔ ورژن 2.1.212 سے، Claude Code آپ کی مرکزی گفتگو میں ایک MCP کال کو دو منٹ بعد پس منظر کے کام میں منتقل کر دیتا ہے۔ کال ختم ہونے پر یہ نتیجہ پہنچا دیتا ہے۔
Cursor کی MCP دستاویزات میں ٹائم آؤٹ کی کوئی ترتیب بیان نہیں۔ MCP specification کوئی عدد نہیں بتاتی۔ وہ کہتی ہے کہ SDKs کو ہر درخواست کے لیے ٹائم آؤٹ کنفیگر کرنے دینا چاہیے، اور کلائنٹ کو ہمیشہ ایک زیادہ سے زیادہ حد رکھنی چاہیے۔
جو کام کئی منٹ لیتا ہے، اس کے لیے سرور MCP Tasks استعمال کر سکتا ہے۔ وہ فوراً ایک ہینڈل لوٹاتا ہے، اور کلائنٹ دوبارہ کنیکٹ ہونے کے بعد بھی نتیجے کے لیے poll کرتا ہے۔ دونوں طرف اس کی سپورٹ ہونی چاہیے، اور کلائنٹ کی سپورٹ مختلف ہے۔
جب جواب گم ہو جائے تو Delta MCP کیا کرتا ہے؟
Delta MCP ایک مفت ایپ ہے جو آپ کے کمپیوٹر پر آپ کے اے آئی اور اس کے ٹولز کے درمیان رہتی ہے۔ جب کسی تبدیلی کا جواب نہ آئے، تو یہ اندازہ نہیں لگاتا اور بس دوبارہ کوشش بھی نہیں کرتا۔ یہ ٹول کو پڑھتا ہے۔
تبدیلی روانہ ہونے سے پہلے، Delta MCP ایسی read چنتا ہے جو دکھا سکے کہ تبدیلی ہوئی یا نہیں۔ یہ read یا تو آبجیکٹ کو دوبارہ پڑھنا ہے یا فہرست کو دوبارہ پڑھنا۔ جب کوئی جواب نہ آئے، تو یہ read فوراً چلاتا ہے۔ read جو دکھاتا ہے، وہی فیصلہ کرتا ہے:
| read کیا دکھاتا ہے | Delta MCP کیا کرتا ہے |
|---|---|
| تبدیلی ہو چکی ہے۔ | کام آگے بڑھتا ہے، اور جواب بتاتا ہے کہ اسے جانچا گیا۔ |
| تبدیلی نہیں ہوئی۔ | یہ تبدیلی ایک بار اور بھیجتا ہے، انہی آرگومنٹس کے ساتھ۔ کسی پیغام یا دوسرے بھیجنے والے عمل کے لیے یہ خود سے کبھی ایسا نہیں کرتا۔ ان کے لیے جواب بتاتا ہے کہ وہ دیکھی نہیں گئی، شاید اب بھی ظاہر ہو جائے، اور کام رک جاتا ہے۔ |
| غیر واضح، یا کچھ پڑھا نہیں جا سکتا جس سے پتا چلے۔ | جواب بتاتا ہے کہ نتیجہ نامعلوم ہے، اور وجہ۔ کام رک جاتا ہے۔ تبدیلی دوبارہ کرنے سے پہلے ٹول کو دیکھیں۔ |
جو ٹول کال جوں کی توں کی گئی ہو، اسے Delta MCP کالعدم نہیں کر سکتا۔ اگر پہلے کی کال کامیاب ہوئی تھی، تو وہ کی گئی ہی رہتی ہے، اور جواب اسے درج کرتا ہے تاکہ آپ کا اے آئی اسے نہ دہرائے۔ ہر وہ کام جو کچھ بدلتا ہے Activity میں محفوظ رہتا ہے، ہر تبدیلی پہلے اور بعد کی صورت کے ساتھ۔
کام کیسے جانچا اور لاگو ہوتا ہے
سوالات
کیا ٹائم آؤٹ کے بعد MCP ٹول کال کو دوبارہ کرنا محفوظ ہے؟
پڑھنا محفوظ ہے۔ تبدیلی تب تک نہیں، جب تک آپ جانچ نہ لیں۔ ٹائم آؤٹ صرف اتنا بتاتا ہے کہ جواب نہیں آیا: ہو سکتا ہے ٹول نے تبدیلی پھر بھی کر دی ہو۔ ٹول میں اسے دیکھیں، اور دوبارہ کوشش صرف تب کریں جب وہ موجود نہ ہو۔ کوئی بھیجنے کا عمل خود سے کبھی دوبارہ نہ کریں۔
اگر درخواست کا ٹائم آؤٹ ہو گیا تو کیا میری MCP تبدیلی ہو گئی؟
ٹائم آؤٹ سے یہ پتا نہیں چلتا۔ درخواست شاید کبھی پہنچی ہی نہ ہو، ٹول ابھی تک کام کر رہا ہو، یا وہ مکمل ہو گیا ہو اور جواب گم ہو گیا ہو۔ ٹول کھولیں اور تبدیلی تلاش کریں۔
Claude Code میں MCP ٹول کا ٹائم آؤٹ کیسے بڑھاؤں؟
MCP_TOOL_TIMEOUT کو ملی سیکنڈ میں سیٹ کریں، یا .mcp.json میں سرور کے اندراج میں timeout فیلڈ شامل کریں۔ ریموٹ سرور کے لیے، 60 سیکنڈ والا فی درخواست ٹائمر ہٹانے کے لیے اسے 60,000 سے اوپر رکھیں۔ MCP_TIMEOUT شروع ہونے کا انتظار ہے، ٹول کال کی حد نہیں۔
Cursor میں MCP ٹائم آؤٹ کیسے بدلوں؟
Cursor کی MCP دستاویزات میں کوئی ٹائم آؤٹ ترتیب بیان نہیں۔ وہ کہتی ہیں کہ ناکام کال چیٹ میں ناکام لکھی جاتی ہے، اور آپ دوبارہ کوشش کر سکتے ہیں یا لاگز دیکھ سکتے ہیں۔ پہلے دیکھیں کہ ٹول میں کیا ہے۔
کیا MCP میں idempotency keys ہیں؟
نہیں۔ ایک ٹول کال میں ٹول کا نام اور آرگومنٹس ہوتے ہیں، اور specification کی schema اس کے لیے کوئی idempotency key بیان نہیں کرتی۔ ٹول اپنی کلید ایک آرگومنٹ کے طور پر لے سکتا ہے۔ وہ idempotentHint بھی سیٹ کر سکتا ہے، جو صرف ایک اشارہ ہے۔
جب ٹول کال کا جواب نہ آئے تو Delta MCP کیا کرتا ہے؟
یہ فوراً ٹول کو پڑھتا ہے تاکہ دیکھے کہ تبدیلی ہوئی یا نہیں۔ ہوئی: کام آگے بڑھتا ہے۔ نہیں ہوئی: یہ تبدیلی ایک بار اور بھیجتا ہے۔ کسی پیغام یا دوسرے بھیجنے والے عمل کو خود سے کبھی دوبارہ نہیں بھیجا جاتا۔ غیر واضح: جواب بتاتا ہے کہ نتیجہ نامعلوم ہے، اور کام رک جاتا ہے۔
ذرائع
- Model Context Protocol, Cancellation کلائنٹس کو ٹائم آؤٹ سیٹ کرنا چاہیے، کال منسوخ کرنا اور انتظار روکنا چاہیے؛ منسوخی کام مکمل ہونے کے بعد پہنچ سکتی ہے (ریویژن 2026-07-28)۔
- Model Context Protocol, Schema Reference ٹول کال میں نام اور آرگومنٹس ہوتے ہیں، idempotency key کے بغیر؛ idempotentHint annotation، اور annotations صرف اشارے ہیں (ریویژن 2026-07-28)۔
- Model Context Protocol, Tasks طویل کاموں کے لیے پائیدار ہینڈل، جس کا نتیجہ دوبارہ کنیکٹ ہونے کے بعد poll اور حاصل کیا جاتا ہے؛ دونوں طرف رضامندی سے شامل ہونا ہوگا۔
- 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 کیسے کام کرتی ہے: پہلا نتیجہ محفوظ اور دوبارہ لوٹایا جاتا ہے؛ کلیدیں کم از کم 24 گھنٹے رہتی ہیں؛ دوسرے پیرامیٹرز رد ہوتے ہیں۔
- Stripe, Advanced error handling کنکشن ناکام ہونے کے بعد ہو سکتا ہے معلوم نہ ہو کہ درخواست چلی یا نہیں؛ سرور کی خرابی نامعلوم نتیجہ ہے؛ نتیجہ معلوم ہونے سے پہلے نئی کلید نہیں۔
- IETF, RFC 9110: HTTP Semantics Idempotent طریقے (safe methods، PUT اور DELETE)، اور غیر idempotent درخواست کو دوبارہ نہ کرنا، جب تک معلوم نہ ہو کہ پہلی کبھی لاگو نہیں ہوئی۔
- Delta MCP, Writing a task جب تبدیلی کا جواب نہ آئے تو Delta MCP کیا کرتا ہے: ہوئی، نہیں ہوئی یا نتیجہ نامعلوم؛ بھیجنے کا عمل خود سے دوبارہ نہیں جاتا۔
- Delta MCP, Activity and Undo ہر وہ کام جو کچھ بدلتا ہے Activity میں محفوظ رہتا ہے، ہر تبدیلی پہلے اور بعد کی صورت کے ساتھ۔
مزید پڑھیں
- اے آئی ایجنٹ کی تبدیلیاں کالعدم کیسے کریں: Notion، GitHubاے آئی ایجنٹ نے کچھ بدلا یا حذف کیا؟ دیکھیں کیا بدلا، Notion، GitHub یا اپنی فائلوں میں اسے کالعدم کیسے کریں، اور کیا کبھی واپس نہیں ہو سکتا۔
- MCP بمقابلہ CLI: اے آئی ایجنٹس کا ٹوکن بل کہاں سے آتا ہےاپنے اے آئی ایجنٹ کے لیے MCP یا CLI؟ ہر ایک کی ٹوکنز میں لاگت، پیمائشیں کیا بتاتی ہیں، کب CLI بہتر ہے، کب MCP، اور کہاں کوڈ دونوں سے آگے ہے۔
