Fixing Roo Code MCP Server Connection Timeouts and Silent Tool Failures

The Problem

A Roo Code task that uses an MCP (Model Context Protocol) server — a database connector, a Slack integration, a custom internal tool — works fine most of the time, but occasionally a tool call from that server either hangs indefinitely, fails with a vague error, or the whole MCP connection silently drops mid-task and later calls to it fail as if the server never existed. Restarting Roo Code or reloading the window "fixes" it, which is a strong sign the issue is connection lifecycle, not the MCP server's own logic.

Why It Happens

Local MCP servers run as child processes with their own startup time

Many MCP servers (especially ones spawned via npx or a local script) take a moment to initialize — install dependencies on first run, open a database connection, authenticate against an API. If a tool call arrives before that startup finishes, or if the process crashes on a transient error (a brief network blip, an expired token) and isn't automatically respawned, subsequent calls fail until something restarts it manually.

Corporate proxies and firewalls interrupt long-lived connections

MCP servers that connect over HTTP/SSE or WebSocket to a remote service can have their connection silently killed by a corporate proxy or firewall's idle-connection timeout, especially on networks that weren't configured with long-running developer tooling in mind. The client often doesn't get a clean disconnect signal, so it keeps trying to use a connection that's already dead.

No visibility into which specific server or call is failing

When several MCP servers are configured at once, a generic "tool call failed" message doesn't say which server, so it's easy to burn time assuming the wrong one is misbehaving.

The Fix

1. Check each MCP server's logs before assuming it's Roo Code

Most MCP servers write their own stderr/log output, separate from Roo Code's own output panel. Checking that log first (rather than only Roo Code's side of the conversation) usually shows the real error — an expired credential, a rate limit, a dependency install failure — immediately.

2. Add explicit health checks or shorter reconnect intervals for remote MCP servers

For MCP servers connecting to a remote endpoint, configure a shorter keep-alive/ping interval than the network's idle timeout, so the connection is proactively refreshed before a proxy kills it silently, rather than discovering it's dead only when the next tool call is attempted.

3. Isolate which server is failing with a minimal, single-server config

Temporarily disable every configured MCP server except the one being debugged. If the same task succeeds with only that server enabled, the issue is likely resource contention or a startup-order dependency between servers, not the server itself.

4. For local/stdio servers, verify the process actually stays alive

ps aux | grep <mcp-server-process-name>

If the process has exited but Roo Code still thinks the connection is open, that's a crash-without-clean-disconnect situation — check the server's own crash handling (does it exit on an unhandled promise rejection? on a single failed API call?) rather than treating every failure as something to work around on the client side.

Why This Works

None of these steps change what the MCP server itself does — they close the gap between "the connection is actually dead" and "the client still thinks it's alive." Checking server-side logs directly, instead of only the client's generic error, finds the real cause faster; isolating servers rules out cross-server interference; and verifying the process is genuinely running distinguishes a real crash from a network-level silent drop.

Conclusion

MCP connection timeouts and silent tool failures are rarely a problem with the specific tool being called — they're almost always a connection lifecycle issue: a slow startup racing an early call, a proxy silently killing an idle connection, or a crashed process the client hasn't noticed yet. Check the server's own logs, isolate it from other configured servers, and confirm the process is actually alive before assuming the tool itself is broken.