mcp server logs show agents retrying failed calls with identical args - should we block this or let it happen
we built an mcp server for elasticsearch and the logs show agents (mostly Claude 3.5 Sonnet) retrying failed tool calls with the exact same args maybe 30% of the time. like the first call returns {"error": true, "message": "query returned 0 results"} and the agent immediately calls again with identical query string should we add server-side logic to detect duplicate calls within 10 seconds and just return the cached error, or is the retry behavior actually useful somehow? worried about rate limits and cost but also don't want to break something the model is doing intentionally
we added a cache on the server side - hash tool name + args, if we've seen it in the last 60 seconds we return a cached error instead of re-running. cut our failed call volume by ~65%
blocking identical retries makes sense imo, but you need to be careful about what "identical" means. we hash the tool name + args but NOT the context, because sometimes the agent should retry the same call after gathering more info. also iirc you want to allow retries if the error message changed, could be wrong though
we hash tool_name + json.dumps(args, sort_keys=true) and block if seen in last 8 tool calls. cut retries by ~58% and haven't seen any false positives yet. the 8 call window lets the agent retry if context actually changed
8 call window is smart. we tried 5 and hit false positives when the agent legitimately needed to retry after context changed (user uploaded a new file, previous tool call modified state, etc). bumping to 10 calls fixed it. what kind of tasks are you running - stateless or stateful tools?
block it. if the agent is retrying with identical args after a failure it's not learning anything, it's just burning tokens and time. we added dedup logic (hash the tool name + args, block if seen in last 30s) and the agent adapted within like 10 calls - started modifying args or switching tools instead
blocking identical retries is correct imo. we added a hash check (tool_name + json.dumps(args, sort_keys=true)) and block if seen within the last 5 tool calls. reduced pointless retries by ~60% and haven't seen any false positives yet