MCP: 'broken pipe' error should indicate server is unreachable, not generic transport failure

Problem

When an MCP server goes down (process killed, daemon crashed, etc.), Claude Code surfaces this error on every MCP tool call:

MCP error -32603: transport error: failed to write request: write |1: broken pipe

This error gives no actionable information. It doesn't tell you:

• Which MCP server is unreachable
• Whether the server process is dead vs. the connection went stale
• What to do about it (restart server? reconnect?)

The /mcp reconnect command also doesn't reliably recover from this state — you often need to fully restart the Claude Code session.

Expected Behavior

When an MCP server is unreachable, the error should say something like:

MCP error: confluence server is not responding (connection refused on http://localhost:8300/confluence/mcp). 
Check that the server process is running.

Or at minimum, before attempting a tool call, Claude Code could do a lightweight connectivity check and surface a clear "server is down" message instead of trying to write to a dead pipe.

Context

• MCP server type: http (via mcp-proxy daemon on localhost)
• The mcp-proxy daemon hosts multiple MCP servers behind one port
• When the daemon dies (e.g., macOS SIGKILL from memory pressure), all MCP tools fail with the same generic broken pipe error
• Restarting the daemon doesn't help — Claude Code's internal HTTP client holds the stale connection
• Only a full Claude Code session restart recovers it

Suggestions

1. Better error message — Include the server name and URL in transport errors so the user knows which server is down and where to look
2. Auto-reconnect on transport failure — If a pipe breaks, attempt a fresh connection before surfacing the error
3. /mcp reconnect should actually reconnect — Currently it doesn't reliably recover from broken HTTP pipes; it should tear down and rebuild the connection

Environment

• Claude Code CLI (latest)
• macOS (Darwin)
• MCP servers configured as type: http via local proxy