Summary

Fixes #15275

Problem: A single TUI session spawns two sets of hermes mcp serve child processes — one from tui_gateway.entry and one from tui_gateway.slash_worker. Both paths independently import model_tools.py, which eagerly calls discover_mcp_tools() at module level.

Approach: Lazy connection pool (architectural fix)

Inspired by Claude Code's SocketPool pattern. Instead of eagerly spawning MCP servers at import time, defer connections to first actual tool use:

• discover_mcp_tools(lazy=True): Registers tool stubs from a local cache (~/.hermes/cache/mcp_tools/) so the model sees MCP tools at session start — but no subprocesses spawn
• ensure_mcp_initialized(): Thread-safe singleton. On first tool call, connects all configured MCP servers. Subsequent calls are no-ops. Equivalent to Claude Code's ensureConnected() → refreshClients() flow
• Tool cache: After successful discovery, tool schemas are persisted to disk. Future lazy loads read from cache instead of connecting

Why this is better than the env var guard

Changes

Flow diagram

import model_tools
  └─ discover_mcp_tools(lazy=True)
       └─ _register_mcp_tool_stubs()
            └─ reads ~/.hermes/cache/mcp_tools/*.json
            └─ registers tool stubs with lazy handlers
            └─ NO subprocesses spawned ✓

model calls mcp__server__tool({"query": "..."})
  └─ _lazy_handler()
       └─ ensure_mcp_initialized()  ← first call only
            └─ register_mcp_servers()
                 └─ spawns MCP subprocesses
                 └─ caches tool schemas for next time
       └─ delegates to real server session

Alternative: Env var guard

See #15796 for a simpler tactical fix using HERMES_SKIP_MCP_DISCOVERY. Both approaches fix the same bug. The env var guard is minimal and low-risk; this PR is the strategic long-term solution.

Test results

102 passed in 16.45s (including 11 new tests in test_slash_worker_mcp.py)