bug: MCP server becomes unresponsive after multiple rapid tool calls

[ichoosetoaccept]

Summary

The MCP server stops responding after a sequence of rapid tool calls (e.g. resolve_stale_comments → reply_to_comment → resolve_comment → resolve_comment → request_rereview). Once the server enters this state, the only recovery is a full client restart — reconnecting to the server alone does not help.

Reproduction

1. Run a PR review workflow that makes several tool calls in quick succession
2. After ~4-6 sequential calls, the server stops responding
3. Subsequent tool calls hang indefinitely
4. Only a full client window reload recovers the connection

See screenshot showing the sequence of calls that triggered the hang.

Investigation Notes

• This is not necessarily a bug in our MCP server code. The same behavior has been observed with a completely unrelated MCP server (a Kubernetes integration), suggesting the issue may be in the MCP client or the stdio transport layer.
• We removed wait_for_reviews (long-polling tool) in refactor: remove wait_for_reviews tool (#54) #62, which was one known source of connection corruption, but the issue persists with normal short-lived tool calls.
• The pattern suggests a possible bug in the stdio MCP transport implementation — potentially in mcp-go, which is used by several MCP clients for their stdio integration.

Proposed Investigation

1. Fork and clone mcp-go
2. Investigate stdio transport handling, particularly around:
   • Concurrent JSON-RPC message framing
   • Buffer management under rapid sequential requests
   • Cancellation handling during in-flight writes
3. If a bug is found upstream, submit a fix — this would benefit all MCP clients using mcp-go

Related

• refactor: remove wait_for_reviews tool (#54) #62 — removed wait_for_reviews (addressed one source of connection corruption, but this issue persists)