Track: parallel MCP tool call deadlock — no server-side fix possible

[ichoosetoaccept]

Context

Issue #65 documents the MCP server becoming unresponsive after rapid parallel tool calls. Our middleware logs conclusively proved the bug is in the stdio transport layer (mcp-go / MCP client integration), not in our server — calls 50-54 of a 7-call batch never even reached our process.

Why we can't fix this server-side

The deadlock occurs before requests reach our server. The mcp-go stdio transport freezes while writing requests to our stdin or reading responses from our stdout. No amount of server-side serialization, queuing, or rate-limiting can help because we never see the requests that get stuck.

The MCP spec (built on JSON-RPC 2.0) has no server capability for signaling max concurrency. There's no standard way for a server to tell the client "please send one request at a time."

Upstream fixes needed

1. mcp-go — fix concurrent stdin/stdout handling. Our mark3labs/mcp-go#714 fixes the related server-death hang, but the concurrent-request deadlock is a separate code path.
2. MCP clients — could serialize tool calls on their side when using stdio transport as a workaround.
3. MCP spec — could add a server capability like concurrency: 1 to let servers request sequential calls.

What to do when this is fixed

Once the upstream fix lands (either in mcp-go or the MCP client), verify that parallel tool calls work reliably, then close this issue and #65.

Current workaround

When using codereviewbuddy tools that trigger many calls (e.g. replying to multiple review threads), the AI agent should call them one at a time rather than in parallel. This is fragile — it depends on the LLM's behavior and isn't enforceable.