MCP tools discovered but not exposed to agent in TUI mode #41625

Bug Description

MCP server tools are successfully discovered by hermes mcp test (3 tools found), but they do not appear in the agent's available tool list during a TUI session. The agent cannot call MCP tools even though the server is connected and tools are registered.

Steps to Reproduce

1. Configure an MCP server in ~/.hermes/config.yaml with HTTP transport (url-based)
2. Start the MCP server (confirm the port is listening)
3. Run hermes mcp test <name> → succeeds, discovers tools
4. Start a TUI session (hermes)
5. The agent does not see or cannot call MCP tools

Expected Behavior

MCP tools should be available as first-class tools in the agent session after successful discovery.

Investigation

Looking at the source code, I suspect a race condition in the TUI startup path:

1. hermes_cli/main.py:_prepare_agent_startup() skips inline MCP discovery for TUI launches (_is_tui_chat_launch returns True → _run_inline_mcp_discovery = False)
2. The comment says: "The TUI launcher hands off to a dedicated startup path that already backgrounds MCP discovery with a bounded join before the first tool snapshot."
3. In hermes_cli/mcp_startup.py, wait_for_mcp_discovery() has a timeout of only 0.75 seconds
4. If the MCP server takes longer than 0.75s to connect and enumerate tools, the tool snapshot is taken before MCP tools are registered
5. hermes mcp test works because it runs synchronously with its own timeout

The 0.75s timeout in wait_for_mcp_discovery() is likely too short for HTTP-based MCP servers, especially on first connection.

Environment

• OS: Windows 10
• Hermes Agent: latest (via hermes update)
• MCP server: HTTP transport (url-based config)
• Shell: git-bash / MSYS

Possible Fix

Either increase wait_for_mcp_discovery() timeout (e.g. to 5-10s), or add a mechanism to inject MCP tools into an already-running agent session after late discovery completes (similar to what /reload-mcp does).