claude-code - 💡(How to fix) Fix MCP client partial reconnect: one streamable-HTTP namespace stays disconnected after server restart while sibling namespaces re-bind

Summary

When a self-hosted streamable-HTTP MCP server exposing multiple namespaces restarts (brief process exit + restart), the Claude Code MCP client reconnects some namespaces but intermittently leaves one namespace permanently disconnected for the rest of the session. The tools in the dropped namespace are enumerated as disconnected and cannot be re-discovered without restarting Claude Code. The server is healthy and serving all namespaces the entire time.

Environment

• Claude Code CLI (latest)
• MCP transport: streamable-HTTP (POST /<namespace>/mcp), self-hosted FastAPI + uvicorn, four namespaces on one port (tasks, dev-agents, sprint, ci-infra)
• Linux (systemd user service)

Steps to reproduce

1. Run a streamable-HTTP MCP server exposing ≥3 namespaces on one port; connect Claude Code to all of them.
2. Restart the server process (clean, ~5s downtime) — e.g. systemctl --user restart <svc>.
3. Observe which namespaces re-bind.

Expected: all namespaces reconnect (the server is serving all of them).

Actual: tasks and dev-agents reconnect; sprint stays disconnected — all ~22 mcp__sprint__* tools shown disconnected and not re-discoverable in-session. The choice of which namespace drops appears nondeterministic across restarts.

Server-side proof the server is healthy

The "disconnected" namespace still returns its full tool catalog over HTTP throughout:

curl -s -X POST -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  http://localhost:5076/sprint/mcp \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

This returns the full catalog wrapped in an SSE message event — so the gap is purely client-side reconnection/rediscovery, not a server fault.

Impact

Any workflow that restarts its MCP server mid-session (config reload, or a release/deploy that rotates a symlink and bounces the service) can silently lose a namespace, forcing a full Claude Code restart or an out-of-band HTTP-fallback workaround that bypasses the MCP client entirely.

Ask

1. Is post-transport-drop re-discovery expected to re-bind all configured namespaces, or is partial reconnect a known limitation?
2. Is there a client-side signal/command to force namespace re-discovery without restarting Claude Code? (ToolSearch does not recover it.)
3. If this is a reconnection-logic bug, any guidance on conditions that make one namespace's rebind fail while siblings succeed (ordering, concurrent reconnect, per-namespace EOF handling)?