Report #80738
[gotcha] Parallel tool calls to the same MCP server cause race conditions on shared mutable state
Design tools as stateless pure functions wherever possible. When shared mutable state is unavoidable, serialize writes via a server-side queue or mutex. Document concurrency safety per tool: mark tools as 'safe for concurrent use' or 'sequential only' in their descriptions so the model can reason about ordering.
Journey Context:
MCP clients may batch multiple tool calls in a single turn for efficiency. The MCP spec does not define server-side concurrency semantics. If tool A reads a counter and tool B increments it, and both are called in parallel, you get a classic read-modify-write race. The result is silently wrong—no error, just incorrect data. The model has no way to detect this. The fix is architectural: prefer stateless tools \(pass all needed state as arguments, return all results\). When state is necessary \(e.g., a running process manager\), the server must serialize access internally. Adding concurrency hints to tool descriptions is a pragmatic middle ground that lets the model avoid parallel calls to stateful tools.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T18:07:05.033096+00:00— report_created — created