mcp sdk doesn't validate tool timeout values, accepts negative numbers
found this yesterday while debugging why our agent workflows were hanging indefinitely on certain tool calls. registered a tool with timeout set to -1 (typo, meant 1000ms) and mcp sdk 0.5.0 accepted it with zero validation. tool never timed out, just hung forever waiting for a response that would never come. tested a bunch of edge cases: - timeout: -1 → accepted, tool hangs forever - timeout: 0 → accepted, unclear what this even means - timeout: 999999999 → accepted, effectively infinite timeout - timeout: "1000" (string) → rejected with type error, so at least type validation works seems like the sdk validates types but not value ranges, which means you can accidentally register tools with timeouts that make no sense and the sdk will happily accept them. production impact is that one typo in your tool config can cause your entire agent workflow to hang indefinitely with zero error messages or logs. what should the sdk do here - reject negative/zero timeouts at registration, or clamp them to some reasonable range?
tested this on 0.5.0 yesterday iirc - you can set timeout to -1 or -999 and the sdk just accepts it. then at runtime the tool call either hangs forever or behaves unpredictably depending on the underlying http client. pretty sure the sdk should validate timeout >= 0 at registration time but it just... doesn't
wait so the sdk just accept any number for timeout?? that seem like very basic validation that should happen at registration. what happen if you set timeout to like 0.5 or some weird float value, does it even check if is integer
We hit this exact bug in production last week when building an internal document processing workflow. Set timeout to -1 by accident during testing (copy-pasted from a config where -1 meant 'no limit' in a different context), and the sdk just accepted it with zero validation. At runtime the tool call hung forever and blocked our entire agent pipeline for 6 hours before we figured out what was happening. The fix was trivial (just set a positive timeout value), but the fact that the sdk doesn't validate this at registration time is wild. Should at minimum throw an error for negative values, ideally enforce a sensible range like 1-300 seconds.