সংক্ষিপ্ত উত্তর
MCP টুল কল টাইমআউট হলে বোঝা যায় না বদলটি হয়েছে কি না। হয়তো আপনার এআই উত্তরটি হারিয়েছে, কাজটি নয়। retry‑এর আগে যাচাই করুন: টুলের ভেতরে খুঁজুন, সে কী তৈরি করতে চেয়েছিল। না পেলেই শুধু retry করুন। পাঠানোর কাজ নিজে থেকে কখনো retry করবেন না।
এই গাইডে যা আছে
কেন টাইমআউট বলে না, বদলটি হয়েছে কি না?
আপনার এআই একটি টুলকে একটি বদল করতে বলল, তারপর অপেক্ষা করল। কোনো উত্তর এলো না, তাই আপনার এআই অ্যাপ অপেক্ষা থামিয়ে একটি ব্যর্থতা জানাল। ওই লেবেল অপেক্ষাটির বিবরণ দেয়, বদলটির নয়। যে বদল আগেই হয়ে গেছে, তা আবার retry করলে দুটি টিকিট, দুটি পেজ বা দুটি বার্তা হয়ে যায়।
ডেভেলপাররা এমন বদলকে write বলেন। তিনটি ঘটনার যেকোনোটি ঘটে থাকতে পারে।
| কী ঘটেছে | বদলটি কি টুলে আছে? | retry করলে |
|---|---|---|
| রিকোয়েস্টটি কখনো পৌঁছায়নি। | না। | ঠিক সিদ্ধান্ত: বদলটি একবার হয়। |
| টুল এখনো কাজ করছে। | এখনো নয়। আপনার এআই হাল ছেড়ে দেওয়ার পরে সেটি দেখা যায়। | বদলটি দুইবার হয়ে যায়, যদি না দুইবার করা ক্ষতিহীন হয়। |
| টুল কাজ শেষ করেছে, কিন্তু উত্তরটি হারিয়ে গেছে। | হ্যাঁ। | বদলটি দুইবার হয়ে যায়, যদি না দুইবার করা ক্ষতিহীন হয়। |
এটি MCP স্পেসিফিকেশনে আগে থেকেই ধরা আছে। ক্লায়েন্টের উচিত প্রতিটি রিকোয়েস্টে একটি টাইমআউট সেট করা, আর সময় পেরোলে রিকোয়েস্ট বাতিল করে অপেক্ষা থামানো। বাতিল করার মানে কিন্তু নিশ্চয়তা নয়। কাজ শেষ হয়ে গেলে বা থামানো না গেলে সার্ভার তা উপেক্ষা করতে পারে। উত্তর পাঠানোর পরেও এটি পৌঁছাতে পারে।
Stripe‑এর API গাইডও একই কথা বলে: সংযোগ ব্যর্থ হলে রিকোয়েস্টটি চলেছিল কি না, তা না-ও জানা যেতে পারে। সেখানে বলা আছে, সার্ভার এররকেও একটি অজানা ফলাফল ধরতে হবে।
টাইমআউটের পর ধাপে ধাপে কী করবেন?
এগুলো ক্রমে করুন। প্রথম দুটিতে এক মিনিট লাগে।
- retry থামানএখনই
আপনার এআইকে বলুন কলটি আর না করতে: “Don’t retry. First check whether it was made.” শুধু একটি retry‑ই বদলটিকে দুইবার ঘটানোর পথ।
- চ্যাটে নয়, টুলের ভেতরে দেখুন1 মিনিট
টুলটি নিজে খুলুন: Notion‑এর পেজ, GitHub‑এর Issues, ফোল্ডার। আপনি যে শিরোনাম বা আইডি চেয়েছিলেন, তা খুঁজুন। চ্যাট শুধু জানে যে কলটি ব্যর্থ হয়েছে।
- যা পেলেন তা পড়ুন2 মিনিট
পেলেন, আর সম্পূর্ণ: বদলটি হয়েছে। এগিয়ে যান, আর সেটি আর করবেন না।
পেলেন, অর্ধেক: যেটুকু বাকি, তা একটি আপডেট দিয়ে শেষ করুন, নতুন করে তৈরি করে নয়।
পেলেন না: সেটি কখনো পৌঁছায়নি, নয়তো এখনো চলছে। এক মিনিট অপেক্ষা করে আবার দেখুন। - একবার retry করুন, আর শুধু নিরাপদ কলতারপর
এখনো না পাওয়া গেলে একবার retry করুন। নিচের টেবিলে বলা আছে, কোন কলগুলো আবার করা নিরাপদ। পাঠানোর আগে দেখুন, তা কোথায় গিয়ে পৌঁছায়।
- বারবার টাইমআউট হলে, কারণটি ঠিক করুনপরে
যে কল সবসময় টাইমআউট হয়, তার সময়সীমা খুব ছোট, নয়তো কাজটি খুব বড়। ওই সার্ভারের সময়সীমা বাড়ান, অথবা প্রতি কলে কম কাজ চান।
কোন কলগুলো retry করা নিরাপদ?
কোনো কল retry করা নিরাপদ, যখন দুবার করলে ফলাফল একবার করার মতোই থাকে। পড়ার কাজ এর যোগ্য। অনেক বদল যোগ্য নয়। HTTP স্ট্যান্ডার্ড PUT (একটি মান সেট করা) আর DELETE‑কে আবার করা নিরাপদ ধরে, আর নিচের সারিগুলো তা-ই অনুসরণ করে। কোনো টুলের নিজের idempotentHint বা বিবরণ এগুলোর চেয়ে বেশি গুরুত্ব পায়।
| কল | যেমন আছে তেমন retry? | আগে যাচাই করুন |
|---|---|---|
| পড়া: search, list, open | হ্যাঁ। এতে কিছুই বদলায় না। | যাচাইয়ের কিছু নেই। |
| মান সেট করা: একটি স্ট্যাটাস, একটি শিরোনাম, একটি লেবেল | সাধারণত হ্যাঁ। একই মান দুবার সেট করলে ফলাফল একই থাকে, HTTP PUT‑এর মতো। | ফিল্ডটি পড়ে দেখা। এরপর কেউ বদলে থাকলে, retry তার সম্পাদনা ওপরে লিখে দেবে। |
| কিছুতে যোগ করা: একটি মন্তব্য, একটি সারি, একটি লাইন | না। দুইবার করলে দুইবার যোগ হয়। | আইটেমটি খুলে আপনার যোগ করা জিনিসটি খোঁজা। |
| তৈরি করা: একটি পেজ, একটি issue, একটি ফাইল | না। retry করলে আরেকটি তৈরি হয়। | যে শিরোনাম বা আইডি দিয়েছিলেন, তা দিয়ে খোঁজা। কিছু না মিললেই শুধু retry। |
| মোছা | সাধারণত হ্যাঁ, যখন কলটি একটি নির্দিষ্ট আইটেমের নাম দেয়, HTTP DELETE‑এর মতো। “সর্বশেষটি” নয়: দ্বিতীয় কলটি অন্য একটি আইটেমে গিয়ে পড়বে। | আইটেমটি খোঁজা। না থাকলে কাজ হয়ে গেছে। |
| পাঠানো: একটি বার্তা, একটি ইমেইল, একটি বিজ্ঞপ্তি | নিজে থেকে কখনো নয়। পাঠানো বার্তা ফিরিয়ে নেওয়া যায় না। | এটি কোথায় পৌঁছায় তা দেখা: পাঠানোর তালিকা, চ্যানেল, অপর পক্ষ। বুঝতে না পারলে আবার পাঠানোর আগে জিজ্ঞেস করুন। |
idempotency key কি ডুপ্লিকেট আটকাতে পারে?
কখনো কখনো। idempotency key একটি অনন্য লেবেল, যা রিকোয়েস্টের সঙ্গে পাঠানো হয়। একই লেবেল দুবার এলে সার্ভিস কাজটি একবার করে, আর তার প্রথম উত্তরটি আবার ফেরত দেয়। এটি তৈরি হয়েছে এমন রিকোয়েস্টের জন্য, যার কোনো উত্তর আসেনি।
- Stripe‑এ একটি key কীভাবে কাজ করে। এর v1 API
POSTরিকোয়েস্টে একটি key নেয়। প্রথম ফলাফলটি সে সংরক্ষণ করে, এমনকি সেটি এরর হলেও, আর একই key দিয়ে retry করলে সেটি আবার ফেরত দেয়। সে কমপক্ষে 24 ঘণ্টা key রাখে। অন্য প্যারামিটার সহ একই key প্রত্যাখ্যান করা হয়। - retry‑তে কী করতে হবে। একই key ও একই প্যারামিটার পাঠান। Stripe বলে, প্রথম ফলাফলটি না জানা পর্যন্ত নতুন key দিয়ে retry করবেন না। প্রতিটি চেষ্টায় নতুন key দিলে কোনো সুরক্ষা থাকে না।
- MCP আপনাকে কী দেয়। একটি
tools/callরিকোয়েস্ট বহন করে একটি টুলের নাম আর তার আর্গুমেন্ট। স্পেসিফিকেশনের স্কিমা এর জন্য কোনো idempotency key সংজ্ঞায়িত করে না। তবু একটি টুল নিজের আর্গুমেন্ট হিসেবে একটি key নিতে পারে, তাই তার আর্গুমেন্ট পড়ুন। - একটি টুল কী ঘোষণা করতে পারে।
idempotentHintবলে যে একই আর্গুমেন্ট দিয়ে টুলটি আবার ডাকলে আর কোনো অতিরিক্ত প্রভাব পড়ে না। এটি শুধু একটি ইঙ্গিত। স্পেসিফিকেশন বলে, যে সার্ভারকে ক্লায়েন্ট বিশ্বাস করে না, তার ইঙ্গিতের ওপর কখনোই সিদ্ধান্ত নেওয়া উচিত নয়।
তাই key একটি বাড়তি সুবিধা, মূল পরিকল্পনা নয়। টুল কোনো key না দিলে, ওপরের যাচাইটিই আপনাকে রক্ষা করে।
MCP টাইমআউট কীভাবে বদলাবেন?
সময়সীমা খুব ছোট হলে বৈধ কাজও কেটে যায়। খুব লম্বা হলে আপনাকে অপেক্ষা করতে হয়। এটি কোথায় সেট করবেন, তা আপনার এআই অ্যাপের ওপর নির্ভর করে। এখানে Claude Code‑এর সেটিংসগুলো দেওয়া হলো।
| সেটিং | কী সীমিত করে | ডিফল্ট |
|---|---|---|
MCP_TOOL_TIMEOUT | একটি টুল কল কতক্ষণ চলতে পারে, মিলিসেকেন্ডে। | 10,00,00,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 বা তার পরে। | 1,20,000 ms, 2 মিনিট |
রিমোট সার্ভারের জন্য 60 সেকেন্ডের ডিফল্ট। HTTP, SSE বা claude.ai কানেক্টর হিসেবে পৌঁছানো একটি সার্ভারের একটি দ্বিতীয় টাইমার আছে। এটি প্রতিটি রিকোয়েস্টে চলে, সার্ভারের প্রথম রেসপন্সের বাইট আসা পর্যন্ত। MCP_TOOL_TIMEOUT, সার্ভারের timeout বা MCP_TIMEOUT বেশি করে সেট না করলে এটি 60 সেকেন্ড থাকে। স্থানীয় stdio সার্ভারে কোনো প্রতি-রিকোয়েস্ট টাইমার নেই।
একটি সার্ভারের জন্য এটি সেট করতে, .mcp.json ফাইলে ওই সার্ভারের এন্ট্রিতে "timeout": 600000 যোগ করুন। এটি দশ মিনিট।
ধীর কল মানেই ব্যর্থ কল নয়। সংস্করণ 2.1.212 থেকে Claude Code আপনার মূল কথোপকথনের একটি MCP কলকে দুই মিনিট পরে একটি ব্যাকগ্রাউন্ড কাজে সরিয়ে দেয়। কল শেষ হলে সেটি ফলাফল পৌঁছে দেয়।
Cursor‑এর MCP ডকুমেন্টেশনে কোনো টাইমআউট সেটিংয়ের কথা নেই। MCP স্পেসিফিকেশনে কোনো সংখ্যা নির্দিষ্ট করা নেই। সেখানে বলা আছে, SDK‑তে প্রতি রিকোয়েস্টে টাইমআউট কনফিগার করা যাওয়া উচিত, আর ক্লায়েন্টের সবসময় একটি সর্বোচ্চ সীমা রাখা উচিত।
কয়েক মিনিট লাগে এমন কাজের জন্য একটি সার্ভার MCP Tasks ব্যবহার করতে পারে। সে তৎক্ষণাৎ একটি হ্যান্ডেল ফেরত দেয়, আর ক্লায়েন্ট পুনরায় সংযোগের পরেও ফলাফলের জন্য poll করে। দুই পক্ষকেই এটি সমর্থন করতে হয়, আর ক্লায়েন্টের সমর্থন ভিন্ন ভিন্ন।
উত্তর হারিয়ে গেলে Delta MCP কী করে?
Delta MCP আপনার কম্পিউটারে একটি ফ্রি অ্যাপ, যা আপনার এআই আর তার টুলের মাঝখানে থাকে। কোনো বদলের উত্তর না এলে, সে আন্দাজ করে না, আর শুধু retry‑ও করে না। সে টুলটি পড়ে দেখে।
কোনো বদল পাঠানোর আগে, Delta MCP এমন একটি পড়া বেছে নেয়, যা দেখাতে পারে সেটি হয়েছে কি না। সেই পড়াটি হলো একই অবজেক্ট আবার পড়া, বা একই তালিকা আবার পড়া। উত্তর না এলে, সে ওই পড়াটি তৎক্ষণাৎ চালায়। পড়াটি যা দেখায়, তা-ই সিদ্ধান্ত নেয়:
| পড়াটি যা দেখায় | Delta MCP |
|---|---|
| বদলটি হয়েছে। | কাজটি এগিয়ে চলে, আর উত্তরে লেখা থাকে যে এটি যাচাই হয়েছে। |
| বদলটি হয়নি। | সে একই আর্গুমেন্ট দিয়ে বদলটি আরেকবার পাঠায়। বার্তা বা অন্য কোনো পাঠানোর ক্ষেত্রে সে নিজে থেকে কখনো এটি করে না। সেগুলোর জন্য উত্তরে লেখা হয় যে এটি দেখা যায়নি, এটি এখনো দেখা দিতে পারে, আর কাজটি থেমে যায়। |
| অস্পষ্ট, বা বলার মতো কিছু পড়া যায় না। | উত্তরে লেখা হয় ফলাফল অজানা, আর কেন। কাজটি থেমে যায়। বদলটি আবার করার আগে টুলটি দেখুন। |
যে টুল যেমন ডাকা হয়েছে, Delta MCP তা আগের অবস্থায় ফেরাতে পারে না। আগের কোনো কল সফল হলে, সেটি হয়েই থাকে, আর উত্তরে তা তালিকাভুক্ত করা হয়, যাতে আপনার এআই সেটি আবার না করে। যেকোনো বদল ঘটায় এমন প্রতিটি কাজ Activity‑তে থাকে, প্রতিটি বদল আগে ও পরে সহ।
কাজ কীভাবে যাচাই ও প্রয়োগ হয়
প্রশ্নোত্তর
টাইমআউটের পর MCP টুল কল retry করা কি নিরাপদ?
পড়ার কল নিরাপদ। বদল নিরাপদ নয়, যতক্ষণ না যাচাই করেছেন। টাইমআউট শুধু বলে যে কোনো উত্তর আসেনি: টুল তবু বদলটি করে থাকতে পারে। টুলের ভেতরে তা খুঁজুন, আর না থাকলেই শুধু retry করুন। পাঠানোর কাজ নিজে থেকে কখনো retry করবেন না।
রিকোয়েস্ট টাইমআউট হলে আমার MCP write কি হয়ে গেছে?
টাইমআউট দেখে তা বোঝার উপায় নেই। রিকোয়েস্টটি হয়তো কখনো পৌঁছায়নি, টুল হয়তো এখনো কাজ করছে, বা সে কাজ শেষ করেছে কিন্তু উত্তরটি হারিয়ে গেছে। টুল খুলে বদলটি খুঁজুন।
Claude Code‑এ MCP টুলের টাইমআউট কীভাবে বাড়াব?
MCP_TOOL_TIMEOUT মিলিসেকেন্ডে সেট করুন, অথবা .mcp.json ফাইলে সার্ভারের এন্ট্রিতে একটি timeout ফিল্ড যোগ করুন। রিমোট সার্ভারের ক্ষেত্রে, 60 সেকেন্ডের প্রতি-রিকোয়েস্ট টাইমার তুলে নিতে এটি 60,000‑এর বেশি সেট করুন। MCP_TIMEOUT হলো শুরু হওয়ার অপেক্ষা, টুল কলের সীমা নয়।
Cursor‑এ MCP টাইমআউট কীভাবে বদলাব?
Cursor‑এর MCP ডকুমেন্টেশনে কোনো টাইমআউট সেটিংয়ের বর্ণনা নেই। সেখানে বলা আছে, ব্যর্থ কল চ্যাটে ব্যর্থ হিসেবে চিহ্নিত হয়, আর আপনি retry করতে পারেন বা লগ দেখতে পারেন। আগে টুলে কী আছে, তা দেখুন।
MCP‑তে কি idempotency key আছে?
না। একটি টুল কল বহন করে একটি টুলের নাম আর আর্গুমেন্ট, আর স্পেসিফিকেশনের স্কিমা এর জন্য কোনো idempotency key সংজ্ঞায়িত করে না। একটি টুল নিজের একটি key আর্গুমেন্ট হিসেবে নিতে পারে। সে idempotentHint-ও সেট করতে পারে, যা শুধু একটি ইঙ্গিত।
টুল কলের উত্তর না এলে Delta MCP কী করে?
বদলটি হয়েছে কি না, তা দেখতে সে তৎক্ষণাৎ টুলটি পড়ে। হয়েছে: কাজটি এগিয়ে চলে। হয়নি: সে বদলটি আরেকবার পাঠায়। বার্তা বা অন্য কোনো পাঠানো নিজে থেকে কখনো আবার পাঠানো হয় না। অস্পষ্ট: উত্তরে লেখা হয় ফলাফল অজানা, আর কাজটি থেমে যায়।
সূত্র
- Model Context Protocol, Cancellation ক্লায়েন্টের টাইমআউট সেট করা, বাতিল করা ও অপেক্ষা থামানো উচিত; কাজ শেষ হওয়ার পরেও বাতিল পৌঁছাতে পারে (সংশোধন 2026-07-28)।
- Model Context Protocol, Schema Reference একটি টুল কল বহন করে একটি নাম ও আর্গুমেন্ট, কোনো idempotency key ছাড়া; idempotentHint annotation, আর annotation শুধু ইঙ্গিত (সংশোধন 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 কল চ্যাটে ব্যর্থ হিসেবে চিহ্নিত হয়; retry বা লগ দেখা; কোনো টাইমআউট সেটিংয়ের বর্ণনা নেই।
- Stripe, Idempotent requests idempotency key কীভাবে কাজ করে: প্রথম ফলাফল সংরক্ষিত হয় ও আবার ফেরত দেওয়া হয়; key কমপক্ষে 24 ঘণ্টা থাকে; অন্য প্যারামিটার প্রত্যাখ্যান করা হয়।
- Stripe, Advanced error handling সংযোগ ব্যর্থ হলে রিকোয়েস্টটি চলেছিল কি না তা না-ও জানা যেতে পারে; সার্ভার এরর একটি অজানা ফলাফল; ফলাফল জানার আগে নতুন key নয়।
- IETF, RFC 9110: HTTP Semantics Idempotent পদ্ধতি (নিরাপদ পদ্ধতি, PUT ও DELETE), আর non-idempotent রিকোয়েস্ট retry না করা, যদি না বোঝা যায় যে প্রথমটি কখনো প্রয়োগ হয়নি।
- Delta MCP, Writing a task কোনো বদলের উত্তর না এলে Delta MCP কী করে: হয়েছে, হয়নি, নয়তো ফলাফল অজানা; পাঠানো নিজে থেকে আবার পাঠানো হয় না।
- Delta MCP, Activity and Undo যেকোনো বদল ঘটানো প্রতিটি কাজ Activity‑তে থাকে, প্রতিটি বদল আগে ও পরে সহ।
আরও পড়ুন
- এআই এজেন্টের পরিবর্তন কীভাবে আগের অবস্থায় ফেরাবেনএআই এজেন্ট কিছু বদলালে বা মুছলে কী করবেন? দেখুন কী বদলেছে, Notion, GitHub বা ফাইলে তা আগের অবস্থায় ফেরান, আর কোনটি কখনোই ফেরানো যায় না।
- MCP নাকি CLI: এআই এজেন্টের টোকেন খরচ আসে কোথা থেকেআপনার এআই এজেন্টের জন্য MCP নাকি CLI? কোনটিতে কত টোকেন খরচ, মাপে কী দেখা যায়, কখন CLI এগিয়ে থাকে, কখন MCP, আর কোথায় কোড দুটিকেই ছাড়িয়ে যায়।
