mcp sdk tool call order is completely nondeterministic across runs with identical state

Tested mcp sdk 0.5.0 yesterday with a workflow that registers 8 tools and makes 4 sequential calls (no parallelism, just A -> B -> C -> D where each depends on the previous). Ran the exact same workflow 50 times with identical initial state and the tool call order was different in 23 of the runs. The sdk doesn't just fire tools in parallel when it could - it also doesn't preserve registration order or any deterministic execution order even for sequential calls. Sometimes tool B executes before tool A finishes, sometimes the LLM decides to call tool D twice in a row, sometimes tool C gets skipped entirely and the workflow just hangs waiting for output that never arrives. This makes debugging absolutely brutal because you can't reproduce failures - a workflow that succeeds 8 times in a row will randomly fail on run 9 with a completely different error than the failure you saw yesterday. We ended up building a wrapper that forces strict sequential execution by blocking tool N+1 until tool N returns, adds 40ms overhead per call but at least workflows are deterministic now. The randomness seems to come from the LLM's tool selection plus the sdk having zero orchestration layer - it just accepts whatever the LLM says and fires it immediately with no validation that dependencies are met or that the requested tool call even makes sense given current workflow state.