Cline 3.42 MCP tool calls fail after restart: 'No connection found for server'
Using Cline 3.42.0 in VS Code with an MCP server and native tool calls, tool calls fail with 'No connection found for server ...' after restarting the extension host or reconnecting, even though the servers show as connected. Tool names contain a random segment like cg9IjN0mcp0health_check that changes on every run. Why does routing break after restart, and is there a fix?
Originally asked on GitHub: https://github.com/cline/cline/issues/8087
4 answers
Still open. A source-backed check against current main (July 2026) shows the same behavior in apps/vscode/src/services/mcp/McpHub.ts, so no released fix is available yet.
The root cause, confirmed by a Cline contributor: getMcpServerKey() in McpHub.ts:123-136 builds a per-process key as "c" + nanoid(5) and stores it in a static in-memory Map that is lost when the extension host restarts. Tool IDs embed that key as 0mcp0 (for example, cg9IjN0mcp0health_check). When the model calls a tool using the old key after a restart, getMcpServerByKey() cannot find the server, which produces "No connection found for server ...".
Workaround that worked for the reporter on Cline 3.42.0: patch the installed extension bundle so getMcpServerKey returns the stable server name instead of the nanoid. They reported tool routing stayed stable across reconnects. The contributor said this stable-key approach would indeed solve the issue, with one caveat: the ephemeral key was introduced by PR #7175 to satisfy provider function-name constraints (alphanumeric, starts with a letter, for example Gemini), so a stable key derived from the server name would need sanitization for long or special-character names. The contributor did not confirm the patch or ship a fix.
A later commenter proposed a regression-test-first fix: derive a stable provider-compatible key from the configured server identity, keep it bounded and sanitized, handle duplicate server names explicitly, and add coverage for reconnect/restart where a cached tool name still routes to the same server.
General advice: since the bug is unfixed, refresh the model's tool list after any restart or reconnect instead of continuing a conversation where the old MCP tool names were already cached.
Did this work for you?What a GitHub user tried on GitHub (Worked)
In the issue body, the reporter patched the installed extension bundle of Cline 3.42.0 so getMcpServerKey returns the stable server name instead of "c" + nanoid(5), and tested locally: tool routing stayed stable across MCP reconnects.
Source: https://github.com/cline/cline/issues/8087 (opens external site)
Did this work for you?What @github-actions tried on GitHub (Outcome unclear)
A Cline contributor traced the bug to getMcpServerKey() in McpHub.ts:123-136, noted the ephemeral key came from PR #7175, and said the stable-key fix would indeed solve the issue but would need sanitization to satisfy provider function-name constraints. No patch was applied by the contributor.
Source: https://github.com/cline/cline/issues/8087#issuecomment-3679076262 (opens external site)
Did this work for you?What @HarperZ9 tried on GitHub (Outcome unclear)
A commenter checked current main and found the ephemeral-key behavior still present (nanoid import, static in-memory Map, getMcpServerKey creating "c" + nanoid(5)), then outlined a regression-test-first fix without testing it.
Source: https://github.com/cline/cline/issues/8087#issuecomment-5018362931 (opens external site)
Did this work for you?