mcp sdk tool retry logic - does it exist or do we all just write our own
hit a case yesterday where external api timed out and mcp sdk 0.5.0 just passed the timeout error to llm context with zero retry. does the sdk have any built-in retry logic or backoff, or is everyone just wrapping tools with their own retry layer
ok so we built timeout wrapper around every single tool two weeks ago, adds like 3ms overhead but at least workflows dont freeze forever when external api hangs. default 30s, configurable per tool. wild that this isnt in the sdk
we built similar wrapper but ours has retries with exponential backoff (3 attempts, 2s -> 4s -> 8s delays). adds complexity but catches transient api failures. what's your timeout threshold and does it vary by tool type or just global
30s timeout, no retries. retries add complexity and we'd rather fail fast and log it than silently retry garbage three times
wait so your just failing fast with zero retries?? that seems overly agressive imo, alot of our tool failures are transiet network blips that succeed on retry #2. we run 3 attempts with exponetial backoff (2s, 5s, 12s) and catch ~40% of failures that woudl otherwise bail the whole workflow. adds complexity yeah but silent retries are way better than waking up to failed workflows that coulda succeeded with one more try
30s zero retries makes sense for deterministic tools but breaks on anything with external api calls
tested this exact scenario yesterday on mcp sdk 0.5.0 with external api tools (weather, stock data, document search). 30s timeout with zero retries fails on ~18% of calls due to transient network issues. bumped to 3 retries with exponential backoff (2s -> 4s -> 8s) and failure rate dropped to 3.2%. deterministic tools (math, string manipulation) can fail fast but anything touching external services needs retry logic
we see similar on 0.4.2 yeah - validation errors get passed straight to llm before tool starts. the error messages include full schema definitions which is actually useful for the llm to correct its parameters, but in multi-tenant setups you're leaking schema details into context which could be a problem. we sanitize validation errors to strip internal field names before passing to llm
we shipped similar wrapper last week - wraps every tool registration with Promise.race against a timeout. default is 45s bc some of our document processing tools are legit slow. adds overhead but way better than agent just dying silently when api is down
what's the actual error rate on timeout vs success