fix(dashboard): start background MCP discovery for dashboard-hosted chat sessions

[jacobcwright]

Problem

Chat sessions hosted by hermes dashboard (the web UI / desktop-app remote backend) never see configured MCP servers' tools.

The dashboard's chat PTY attaches to the web server process's in-memory tui_gateway via HERMES_TUI_GATEWAY_URL instead of spawning its own gateway, so tui_gateway/entry.py's startup MCP discovery never runs in that process. The other two entrypoints both run discovery at startup:

• messaging gateway: gateway/run.py → discover_mcp_tools()
• standalone CLI TUI: tui_gateway/entry.py:main() → backgrounded discover_mcp_tools()

The dashboard path never did. The failure is silent and confusing: _get_platform_tools(cfg, "cli", include_default_mcp_servers=True) correctly resolves the MCP server names into the enabled-toolset list, but the tool registry has no MCP tools to hand out, so the agent is built without them — no warning anywhere. A manual /reload-mcp fixes the live session (and is how we confirmed the cause), but it's needed again after every restart.

Repro

1. hermes mcp add <any stdio server> ...
2. hermes dashboard, open a chat (web or desktop app)
3. Ask the agent to list tools → zero mcp_* tools; /reload-mcp makes them appear

Confirmed on a Fly.io deployment running the gateway and dashboard side by side: the gateway process had all 7 configured MCP stdio servers as children; the dashboard process had none.

Fix

• hermes_cli/web_server.py: the lifespan now starts the existing shared background-discovery helper (hermes_cli.mcp_startup.start_background_mcp_discovery). It's config-gated (no MCP servers configured → no MCP-SDK import, no thread) and backgrounded (a slow/dead server can't block dashboard startup), same as the CLI path.
• tui_gateway/server.py:_make_agent: in addition to the existing tui_gateway.entry wait, briefly join the shared mcp_startup thread (bounded) so the first agent build in a dashboard process picks up fast-connecting servers. Each wait is a no-op when its thread was never started.

Tests

Two regression tests in tests/hermes_cli/test_mcp_startup.py: lifespan starts discovery when servers are configured; skips entirely when none are. Ran tests/hermes_cli/test_mcp_startup.py (6 passed), tests/hermes_cli/test_web_server.py (211 passed), tests/tui_gateway/test_wait_for_mcp_discovery.py + test_make_agent_provider.py (11 passed).

[sanchomuzax]

I applied the change from this PR locally on a Hermes Desktop/Dashboard installation, and it appears to fix the issue in practice.

What was applied locally:

• hermes_cli/web_server.py: start background MCP discovery from the dashboard/web-server lifespan using start_background_mcp_discovery(...) with the dashboard-mcp-discovery thread.
• tui_gateway/server.py: wait for the shared hermes_cli.mcp_startup.wait_for_mcp_discovery() path before the agent snapshots its tools.
• Added the matching regression tests from this PR around dashboard lifespan MCP discovery.

Observed result after restarting the Desktop/Dashboard session:

• The Hermes Agent Desktop session is now able to list the configured MCP tools.
• Before applying the patch, the gateway process had MCP child processes, but the desktop/web backend path did not expose MCP tools to the desktop session.

Environment tested:

• Hermes Agent: v0.16.0 (2026.6.5), upstream 484f484
• OS: Linux rpi5 6.18.33+rpt-rpi-2712, Debian/Raspberry Pi kernel, aarch64
• Runtime: local Desktop/Dashboard session on the same machine
• Node.js: v20.19.6
• npm: 11.13.0
• MCP servers configured included Context7, Grafana, n8n, NotebookLM, mcpvault, Smart Connections, and Playwright.

Local verification:

• tests/hermes_cli/test_mcp_startup.py: 6 passed
• tests/tui_gateway/test_wait_for_mcp_discovery.py: 4 passed
• git diff --check: clean for the touched files
• py_compile: clean for the touched files

On behalf of Sancho, a Hermes Agent

[alt-glitch]

This was generated by AI during triage.

Duplicate of #42703 — same fix: start background MCP tool discovery for dashboard/Desktop-hosted chat sessions so they aren't built with an empty MCP tool list (the web_server.py lifespan never ran discovery). #42703 is the earliest open PR for this and takes the same approach (discovery in the dashboard lifespan + tui_gateway join). Cross-ref #42704 (also dup of #42703). Maintainer can pick the cleanest of the three.

[teknium1]

Superseded by PR #44512 — fix(desktop): discover MCP tools for dashboard /api/ws backends (commit 73969771a, merged June 11), which is now on main and resolves issue #42694.

#44512 implements the same fix this PR proposes: cmd_dashboard() spawns a background MCP discovery thread via hermes_cli.mcp_startup.start_background_mcp_discovery() before start_server(), and tui_gateway.server._make_agent() waits on that thread before snapshotting tools. Verified on current main.

Thanks for the fix — closing as redundant. Credit to you and the other contributors who independently caught this (#42703, #43189, #40407 all targeted the same gap).