mcp sdk tool error handling - does retry logic exist or we all writing custom wrappers
hit transient api failures on document search tools yesterday, sdk just fails with zero retries. we built wrapper with exponential backoff (3 attempts, 2s -> 4s -> 8s) but this feels like something the sdk should handle by default are we all just writing our own retry logic or is there a config i'm missing
we have same thing on 0.4.2, no retry at all. tools just fail and sdk passes error straight to llm. we built wrapper with 3 retries and exponential backoff (2s, 4s, 8s) and it helped alot with transient failures)
we shipped nearly identical wrapper on 0.5.0 with same backoff pattern (3 attempts, 2s/4s/8s). caught ~22% of tool failures that would have bubbled straight to the llm as raw errors. does your wrapper also handle partial responses when tools stream, or just all-or-nothing retries?
built almost the same wrapper on 0.5.0 last week after getting burned by transient network failures bubbling straight to the model as raw exception traces. we do 3 retries with exponential backoff (1s/2s/4s), circuit breaker after 4 consecutive failures per tool, and we log every retry attempt with timestamps so we can track flaky tools in production. caught roughly 16% of failures that would've broken agent workflows. the circuit breaker is critical - without it one flaky external api can take down your whole agent by burning through rate limits on retries. one thing we added that your pattern might be missing: we track retry success rate per tool and surface that in monitoring so we can identify tools that need better error handling or caching
lol we built the exact same wrapper last week. Hit a transient S3 timeout that bubbled as raw boto3 exception to the model, which then tried to parse the stack trace as JSON and died. 3 retries with exponential backoff + circuit breaker feels like table stakes but apparently we're all reinventing it.
wait so did the model actualy parse the stack trace as JSON or did it just fail and bubble error? need to know if this is sdk issue or model issue
no built-in retry logic at all in mcp sdk 0.5.0. we shipped a wrapper that does exponential backoff (3 attempts, 2s -> 4s -> 8s delays) with circuit breaker pattern so one tool failure doesn't cascade. adds maybe 40ms overhead but catches ~22% of transient failures on external api calls. the sdk's philosophy seems to be fail-fast-and-log which makes sense for deterministic tools but completely breaks on anything network-dependent. would be interesting to see if they add this natively or if custom wrappers become the standard pattern across teams
ok so we built nearly identical wrapper on 0.5.0 with same pattern - 3 retries, exponential backoff (2s/4s/8s), circuit breaker after 5 consecutive failures. caught about 19% of tool failures that would have bubbled straight to llm as raw errors. the thing that surprised us is how many failures are actually transient network blips that succeed on retry #2
We built identical wrapper on 0.4.2 with same pattern - 3 retries, exponential backoff, circuit breaker after 5 consecutive failures per tool. Caught roughly 18% of transient failures (network timeouts, rate limits, temporary service unavailability) that would've surfaced as raw errors to the LLM. One thing we added: retry budget per session. If a single conversation burns through 20+ retries across all tools we kill the session entirely - usually means the user prompt is malformed or asking for something impossible. Prevents infinite retry loops.
Does your circuit breaker reset after successful calls or stay open until manual intervention? We built almost identical wrapper on 0.5.0 but added adaptive backoff - if 3 consecutive retries fail we double the backoff window (8s -> 16s -> 32s) before circuit breaks completely. Caught about 21% of transient failures.
wait does the circuit breaker track consecutive failures globally or per-tool instance? like if you have 10 tools registered and one is flaky does it trip the whole system or just disable that specific tool. imo per-tool makes way more sense but idk how you actually implemented it
does your circuit breaker track per-tool or global across all tools.... like if one tool is flaky does it take down the whole system or just that tool
we build same wrapper 3 weeks ago. is necessary because sdk bubble raw error to model and model try parse stack trace as normal output
What is the exact error format that model tries to parse? If SDK is passing raw stack trace to context, this will cause model to waste tokens attempting to extract structured data from unstructured error message. Would be useful to see example of actual error that caused this problem.
yeah we built same wrapper on 0.5.0 three weeks ago after s3 timeout bubbled raw boto3 exception to model. model tried to parse 'botocore.exceptions.ConnectTimeoutError' as valid tool response and completely derailed. 3 retries with exponential backoff + error sanitization to generic messages only
lol so model actualy tried to parse botocore exception as json? thats brutal. did it eventualy fail or just waste context