Comment by Ashutosh Bhardwaj on "What happens when an AI agent retries a tool call? I checked 489 MCP tools"

CommentWhat happens when an AI agent retries a tool call? I checked 489 MCP tools

Ashutosh Bhardwaj

Thanks Mike, you're right, and this was a real bug in the default rather than an edge case. The log had no expiry, so with ["*"] a deliberate repeat a week later was answered with the first result and nothing happened, which is worse than a duplicate because the agent thinks it worked. The README's "nothing legitimate is ever refused" hid that: it wasn't refused, it was silently replayed.

Fixed in mcp/v0.6.0: policies now have a replay_window, 10 minutes by default for ["*"] since that identity is only a guess. After the window, the same arguments are a new operation with a new key, so a server that deduplicates on the key doesn't swallow it either. An unknown outcome never expires, since that would bring back the double charge. I went with a window rather than a run id because a restart after a crash starts a new run, and that's exactly the retry that has to be recognised.

The marker idea is good. It turns "unknown, go check" into a lookup, which is the part I most want to improve. The limits I see are that it needs a free-text field and changes the caller's arguments, and that search indexing lags, so "not found" isn't proof. As an opt-in per tool, with the lookup configured alongside it, I think it works. Would you use it that way?

Mike Dabydeen

VP Engineering @ UREEQA

7h ago

Yes, opt-in per tool is how I'd use it, with the lookup set next to it. For GitHub I'd skip search for that lookup and list the repo's issues filtered by creator, sorted by created, newest first, then check each body for the marker. That avoids the search index, so a miss shortly after the attempt means more. The same endpoint also returns pull requests, so drop anything with a pull_request key.

On changing the caller's arguments: where the tool has a structured field, such as metadata on a Stripe PaymentIntent, the marker can go there and the text the agent wrote stays untouched. Free text would only be the fallback for tools that have nothing else.

That's a better lookup than search, thank you. The list endpoint filtered by creator, newest first, means a miss shortly after the attempt actually says something, and dropping anything with pull_request is a detail I'd have missed. And agreed on structured fields first: metadata on a PaymentIntent leaves the agent's text alone, with free text only as the fallback.

So the shape would be: per tool, where the marker goes (a field path, or appended text) and how to look it up. The proxy stamps every call with its operation id. When an outcome is unknown, it runs the lookup. Found means the call is recorded as done with what was found, never retried. Not found stays unknown, unless the policy says a miss after some delay is enough to retry, since only you know how fast that system's list catches up.

Are you running agents against GitHub or Stripe yourself? If you have a real setup I'd like to build this against it rather than my fakes. Happy to take it to a GitHub issue or email, whichever's easier.

Search Hashnode