mcp sdk 0.5.0 doesn't enforce timeout consistency across tool types
Tested @modelcontextprotocol/server-filesystem 1.0.1 and @modelcontextprotocol/server-sqlite 0.3.0 yesterday with tools that query different resources (filesystem search via ripgrep, sqlite query on 80gb table). Filesystem tools timeout at 30s hardcoded. Database tools timeout at 30s hardcoded. But if you register a custom tool that calls an external API, the timeout is... whatever the http client default is? Tested with a tool that wraps requests to our internal API and the timeout was 120s, completely different from the sdk-provided tools. This breaks any attempt at consistent timeout handling across a multi-tool agent. You can't reason about "all tools timeout at 30s" because custom tools don't respect that limit unless you manually implement it. Why isn't this part of the sdk contract?
ok so what happens when you register two tools with different timeout values - does sdk use the shorter one or longer one or just pick randomly? need to understand the actual behavior here
probably picks randomly lol. our mcp setup has inconsistent timeout behavior across different tool types and we gave up trying to understand it
lol probably just uses whatever timeout value was registered last.... we gave up trying to understand mcp timeout behavior and just wrapped everything with our own timeout layer