hermes - 💡(How to fix) Fix MCP server initialization failure should not prevent Hermes startup [2 pull requests]

Summary

Hermes startup can fail or become blocked when a configured MCP server fails to initialize. In my case this was triggered by a RenderDoc MCP server, but the issue is broader: one unhealthy optional MCP integration should not make the whole Hermes session unavailable.

Current behavior

When an MCP server is configured under mcp_servers, Hermes attempts to connect and discover tools during startup. If that MCP server is down, slow, misconfigured, or fails during initialize / list_tools, Hermes startup can fail or hang before the normal chat session is usable.

This makes startup fragile for MCP servers that depend on external processes or platform-specific resources, e.g. RenderDoc MCP running on Windows while Hermes runs in WSL.

Expected behavior

Hermes should start successfully even if one or more configured MCP servers fail.

Suggested behavior:

• Treat MCP discovery as best-effort / soft-fail.
• Catch and isolate failures per MCP server.
• Mark failed servers as unavailable and continue startup.
• Do not register tools from failed servers, or register them as disabled/unavailable.
• Show a clear warning with the server name and error.
• Allow recovery with hermes mcp test <name> / /reload-mcp after the external server is fixed.

Why this matters

MCP servers are often optional integrations, not core dependencies. RenderDoc MCP is a good example because it may depend on:

• Windows/WSL networking
• SSE endpoint configuration
• RenderDoc Python bindings / DLL paths
• Windows firewall
• GPU/replay environment
• External server process already running

Any of those can fail independently of Hermes. A broken optional tool should degrade only that tool, not prevent normal Hermes usage.

Proposed implementation direction

Possible changes:

1. Wrap each MCP server initialization and list_tools() call in per-server exception handling.
2. Apply a bounded startup connect_timeout per server.
3. Store per-server status: connected, unavailable, last_error, last_attempt_at.
4. Continue building the normal tool registry even when some MCP servers fail.
5. Add or expose a status command showing failed MCP servers and their errors.
6. Consider lazy/on-demand MCP connection for unstable or heavyweight servers.

Example desired startup output

Warning: MCP server 'renderdoc' unavailable: connection timed out after 5s
Continuing without tools: mcp_renderdoc_*
Hermes started successfully.

Environment

• Hermes Agent with native MCP configured via mcp_servers
• WSL host
• RenderDoc MCP server running externally on Windows via SSE

Impact

This would make Hermes more robust and prevent optional MCP integrations from becoming boot-critical dependencies.