fix(mcp): bump default discovery wait from 0.75s to 3.0s for npx cold start

[sj-unit72]

What

Bump the default wait_for_mcp_discovery timeout from 0.75s to 3.0s in both implementations (hermes_cli/mcp_startup.py and tui_gateway/entry.py). Add regression tests in both test files.

Why

The agent snapshots its tool list once at build time and never re-reads it. npx-driven MCP servers (npx -y @griches/apple-mail-mcp and similar) typically take 2-4s to install and spawn on first launch. The previous 0.75s default was a race: any slow-but-reachable server that finished connecting after 0.75s was silently dropped from the agent's tool list for the entire session, even though the process was alive and healthy.

Reproduction

1. Register four npx-driven Apple MCPs (mail, contacts, reminders, calendar) in config.yaml:

   mcp_servers:
     apple-mail:
       command: npx
       args: [-y, "@griches/apple-mail-mcp", --read-only]
       enabled: true
     apple-contacts:
       command: npx
       args: [-y, "@griches/apple-contacts-mcp"]
       enabled: true
     # ... two more

2. hermes mcp test apple-contacts → shows 11 tools. Healthy.
3. hermes chat -q "call mcp_apple_contacts_list_groups" → "that tool isn't available in my current toolset".
4. ~/.hermes/logs/mcp-stderr.log shows all four servers reporting "running on stdio". The processes are alive, but only the mail server is in the agent's tool list. The other three are invisible.

The fix: switch to local node paths in the config (works around the bug), or land this PR (fixes it for everyone).

Why 3.0s

• hermes mcp test shows 0.3-3.8s startup for npx-driven servers on a warm cache. Cold cache is 2-4s.
• A 3.0s default catches npx cold starts while still bounding the worst case: a dead/never-resolving server still gets cut off quickly, so the startup-hang protection that motivated the original 0.75s default is preserved.
• Dead-server test (test_hung_thread_is_bounded_by_timeout) still passes against the new default — the bound is the timeout, not the value of the default.

Tests

• All 107 tests/tui_gateway/ tests pass.
• All 10 tests/hermes_cli/test_mcp_startup.py + tests/tui_gateway/test_wait_for_mcp_discovery.py tests pass.
• Two new regression tests pin the default to >= 2.0s so future refactors can't silently regress this.

Diff

 hermes_cli/mcp_startup.py                        | 19 +++++++++++++++++--
 tests/hermes_cli/test_mcp_startup.py             | 16 ++++++++++++++++
 tests/tui_gateway/test_wait_for_mcp_discovery.py | 16 ++++++++++++++++
 tui_gateway/entry.py                             |  2 +-
 4 files changed, 50 insertions(+), 3 deletions(-)

[alt-glitch]

Duplicate of #41630 — identical fix bumping wait_for_mcp_discovery from 0.75s to 3.0s in hermes_cli/mcp_startup.py and tui_gateway/entry.py. #41630 (earlier, open) is the canonical fix. Related: #37013 (root issue), #37104/#37301 (prior attempts).

[teknium1]

Thanks for documenting the MCP discovery race. This is now implemented on current main through a broader, cache-safe solution.

• hermes_cli/mcp_startup.py:53-100 resolves a configurable mcp_discovery_timeout instead of retaining a fixed 0.75s wait; the default is defined at hermes_cli/config.py:1359-1372.
• tui_gateway/server.py:4370-4439 refreshes an agent's MCP tool snapshot when discovery finishes after the bounded wait, while preserving the pre-first-turn prompt-cache safety guard.
• Commit 357fa7a50dce16ef696d81d55d385907a5c6e55e shipped the broader CLI/TUI/gateway late-connection fix.
• As @alt-glitch noted, this duplicates fix(mcp): increase wait_for_mcp_discovery timeout from 0.75s to 3.0s #41630; that earlier PR has also been closed as implemented on main.

This is an automated hermes-sweeper review.