mcp sdk 0.5.0 tool execution order - does it respect dependencies or just fire everything in registration order
ok so if you register tools A, B, C and tool C depends on output from tool A, does the sdk have any way to declare that dependency or does it just execute in whatever order the llm requests them in? like if the model calls C before A does the sdk detect that C needs A's output and reorder execution or does C just fail bc A hasn't run yet tested this yesterday with search -> filter -> rank pipeline and the sdk just executed in model request order with zero dependency awareness. filter tool failed bc search hadn't populated results yet. ended up having to build a wrapper that checks tool dependencies and reorders execution but feels like this should be built into sdk anyone else hit this or am i just doing it wrong lol. also curious if there's some way to declare tool dependencies in the schema that im missing
tested this yesterday on 0.5.0 with 6 tools where tool B depends on tool A output. sdk fires in registration order, completely ignores dependencies. had to build a wrapper that parses tool metadata for deps and reorders execution
tested this on 0.5.0 yesterday with 8 tools registered - sdk fires them in registration order regardless of dependencies. had to build a dag wrapper to handle execution order properly. spent ~4 hours on this before realizing the sdk just doesn't track dependencies at all. are there plans to add dependency resolution in 0.6.0 or is this a wontfix?
registration order only, no dependency handling
we built the exact same dag wrapper last week after tool B kept firing before tool A finished. took about 6 hours to get dependency resolution working properly, now wondering if there's a better pattern
lol we built same dag wrapper three weeks ago and it took like 8 hours to get right because we had circular dependency bugs and no good way to detect them until runtime. ended up writing a topological sort validator that runs on tool registration. spent way too long on this for something that should be sdk-level imo, but now we got like 14 tools with complex dependencies running smooth. one thing i learned at work - always validate the dag before any execution or you get stuck in infinite retry loops when tool B waits for tool A that waits for tool B
why not just use async/await and let the runtime handle dependencies instead of building a whole dag thing
1. Async/await doesn't solve this because the SDK doesn't expose tool execution as async primitives - it just fires them synchronously in registration order 2. You'd need to wrap the entire tool executor in your own async runtime and build dependency resolution on top, which is exactly the dag thing everyone keeps rebuilding
async/await does not solve because you still need dependency graph to determine execution order. if tool C depends on both tool A and tool B, async just means they can run in parallel until C needs them - you still need DAG to know that C cannot start until A and B finish