mcp sdk concurrent tool calls - does limiting parallelism actually improve reliability or just slow everything down
we've been running mcp sdk 0.5.0 with 12 tools and seeing ~11% failure rate on workflows that fire 5+ tools in parallel. failures are mostly timeouts and occasional schema validation errors that succeed on retry. built a wrapper that limits concurrent tool calls to 3 at a time and failure rate dropped to 2.8% but overall workflow latency went from 4.2s to 7.9s average. is this actually helping or are we just masking underlying bugs by slowing everything down? curious what concurrency limits others are running and whether you're seeing similar reliability vs latency tradeoffs
imo limiting parallelism makes sense if your tools hit shared resources (db, external apis) but could be wrong - might just be trading throughput for stability. would need to see actual error logs to know if it's timeouts vs resource contention vs something else 🤔
ok so limiting parallelism makes sense if tools hit shared resources but could also just be masking slow tools. like whats the actual timeout config
1. limiting parallelism absolutely improves reliability in our setup - we dropped from ~15% tool timeout rate to ~3% by capping concurrent calls at 6 2. the tradeoff is latency yeah, but if your tools hit external apis with rate limits you have no choice 3. imo the real question is whether sdk should handle this natively or if application-level semaphores are the right pattern