gemini-mcp-tool keeps disconnecting from Claude Code after a few calls
gemini-mcp-tool (jamubc/gemini-mcp-tool) disconnects from Claude Code after every few successful tool calls. Environment: Node v25.9.0, macOS 26.4 (25E246), Claude Code v2.1.109. There is no error message; the MCP server just drops and you have to reconnect via /mcp. The issue is closed — is there a fix or workaround?
Originally asked on GitHub: https://github.com/jamubc/gemini-mcp-tool/issues/64
4 answers
Status: closed by the reporter without a confirmed root cause. The maintainer noted that v1.1.7 shipped a test suite and cross-platform fixes and asked whether the problem persisted; the reporter closed the issue believing it was addressed, but did not verify the latest version.
No single fix was confirmed for gemini-mcp-tool in the thread. A commenter who hit the same "disconnects every 5–10 calls" failure class with stdio MCP servers in Claude Code offered a three-hypothesis checklist:
- Missing
notifications/progressheartbeats — Claude Code times out stdio silence at around 30s on long-running calls. - Transient
TypeError: fetch failedfrom Node'sundicithat the@google/genaiSDK's internalp-retrydoes not recognize. - 429 quota/throttle cascades when parallel tool calls fail and retry as a thundering herd.
That commenter eliminated the failure class on their own from-scratch server by emitting progress heartbeats every 5s during reasoning and wrapping every
generateContentcall in an app-layer retry with 1s/3s/9s backoff, bypassing retry for non-transient errors. Note this was applied to their own server, not to gemini-mcp-tool, so it is a pattern to replicate rather than a verified patch.As general advice: update to v1.1.7 or later first; if disconnects persist, apply the heartbeat/retry pattern in a wrapper. The reporter's own workaround was switching to a personal fork of the tool; the same commenter offers an alternative server with a documented migration from this tool.
Did this work for you?- Missing
What a GitHub user tried on GitHub (Didn't work)
Reproduced the bug by asking Claude to ping Gemini through the MCP tool; the connection dropped after the call and required /mcp to reconnect, repeating each time.
Source: https://github.com/jamubc/gemini-mcp-tool/issues/64 (opens external site)
Did this work for you?What @qmt tried on GitHub (Worked)
A commenter who built their own from-scratch server fixed the same failure class on their side by emitting notifications/progress heartbeats every 5s during reasoning and wrapping every generateContent call in an app-layer retry with 1s/3s/9s backoff, skipping retry for non-transient errors.
Source: https://github.com/jamubc/gemini-mcp-tool/issues/64#issuecomment-4300028705 (opens external site)
Did this work for you?What @jacobcxdev tried on GitHub (Outcome unclear)
The reporter switched to their own unnamed fork of the tool during maintainer inactivity and closed the issue, without verifying whether the latest gemini-mcp-tool still fails.
Source: https://github.com/jamubc/gemini-mcp-tool/issues/64#issuecomment-4684467955 (opens external site)
Did this work for you?
Related questions
- How to fix gemini-mcp-tool ask-gemini timeouts on large codebases?
- How do I fix "Gemini was thinking but got cut off" with gemini-mcp-tool in Claude Code?
- gemini-mcp-tool ask-gemini fails on Windows 11: Error: spawn gemini ENOENT
- How do I set the model for gemini-mcp-tool to gemini-3-pro-preview?
- Windows: gemini-mcp-tool 'Cannot use both a positional prompt and the --prompt flag'