MCP servers fail silently on session start with no auto-recovery or health feedback

Problem

MCP servers configured in Claude Code frequently fail to connect at session start, with no automatic retry, no clear feedback, and no recovery mechanism. This creates a cascading failure pattern:

1. Session starts → MCP servers attempt connection
2. One or more fail (e.g., Docker not running, npx timeout, network hiccup)
3. User doesn't know until mid-task when a tool call fails
4. Only fix: manually restart session or claude mcp commands
5. Repeat every session

Environment

• Windows 11, Claude Code CLI (latest)
• MCP servers: Supabase, Chrome MCP, Stitch (all stdio/npx-based)

Current Behavior

• claude mcp list shows ✗ Failed to connect but no retry attempted
• Failed MCPs are dead for the entire session — no reconnection even if the underlying issue resolves (e.g., Docker Desktop starts later)
• No hook or event fired when an MCP fails, so custom health checks can't act on it
• One flaky MCP doesn't block the session, but it silently degrades capabilities

Expected Behavior

1. Auto-retry on failure — If an MCP fails to connect at startup, retry 2-3 times with backoff before marking as failed
2. Lazy/on-demand initialization — Don't block session start on MCP connections. Connect when first tool call needs it (see also #38365)
3. Mid-session reconnection — If an MCP disconnects, attempt reconnection on next tool call instead of permanent failure
4. Startup health summary — Surface which MCPs connected vs failed in a visible way (not just claude mcp list after the fact)
5. Hook event for MCP failure — Allow PostMCPConnect or similar hook so users can run custom recovery logic

Impact

For power users with 3+ MCP servers, this is a daily friction point. Every new session or deploy cycle requires manually verifying MCP health and restarting failures. The current behavior makes MCPs feel unreliable enough that users avoid depending on them for critical workflows.

Related

• #38365 — Lazy MCP server initialization (feature request, covers deferred connection but not recovery)
• #18127 — "1 MCP server failed" but /mcp shows all green (misleading health reporting)
• #39039 — One bad HTTP MCP entry silently kills all user-level MCPs
• #39486 — MCP servers disconnect when another session connects

🤖 Generated with Claude Code