MCP servers with many tools silently fail to connect on startup

Description

MCP servers configured in ~/.claude.json that register a large number of tools intermittently fail to connect at Claude Code startup. When they fail, they are silently dropped for the entire session with no error message or notification.

Environment

• Claude Code: latest (VS Code extension, March 2026)
• OS: Ubuntu (WSL2) on Windows
• MCP servers: stdio transport, Python and Node

Reproduction

Configure multiple MCP servers in ~/.claude.json, including at least one with 100+ tools. Restart Claude Code multiple times.

Servers that reliably connect (few tools)

• pricelabs (10 tools) - always connects
• mcp-sapling (1 tool) - always connects
• mcp-namecheap (~30 tools) - always connects
• propertydata (~50 tools) - always connects

Servers that intermittently fail (many tools)

• mcp-hostfully (169 tools) - frequently missing
• mcp-ghl (380 tools) - sometimes missing
• mcp-gsc - intermittent
• mcp-inoreader - intermittent
• mcp-notebooklm - intermittent

Observed behaviour

1. Start a new Claude Code session
2. Attempt to use a tool from a heavy MCP server (e.g. Hostfully)
3. Tool is not found in the deferred tools list
4. ToolSearch returns "No matching deferred tools found"
5. No error message was shown at startup indicating the server failed to connect
6. The server imports and runs correctly when tested manually (python server.py)

Expected behaviour

• MCP servers should reliably connect regardless of tool count
• If a server fails to connect, Claude Code should display a warning (e.g. "mcp-hostfully failed to connect: timeout")
• Ideally, a retry mechanism or configurable timeout for the stdio handshake

Workaround

Restart Claude Code and hope the server connects. There is no way to force a reconnect mid-session or to diagnose which servers are connected without asking the model to check the tools list.

Impact

This is a significant workflow disruption. Users configure MCP servers expecting them to be available, then discover mid-task that a critical server isn't connected. The silent failure means time is wasted attempting tool calls before realising the server is missing. For servers with many tools (which tend to be the most important ones, covering full API surfaces), the failure rate appears higher.

Suggested improvements

1. Configurable timeout per server in ~/.claude.json (e.g. "timeout": 30000)
2. Startup report showing which servers connected and which failed
3. Retry mechanism with exponential backoff for failed connections
4. Mid-session reconnect command (e.g. /reconnect mcp-hostfully)
5. Lazy connection option: connect to a server on first tool use rather than at startup