Summary

A failing MCP OAuth server should not prevent Hermes from starting. In my case, the Atlassian MCP server was enough to make Hermes effectively not start, even though other MCP servers should have remained usable.

Repro context

Local config had an HTTP MCP server like:

mcp_servers:
  mem0_mcp:
    url: https://mcp.mem0.ai/mcp
    headers:
      Authorization: Bearer <redacted>
  atlassian:
    url: https://mcp.atlassian.com/v1/mcp
    auth: oauth

The Atlassian server was the problematic one.

Expected behavior

• Hermes startup should continue even if one MCP server fails.
• Failed MCP servers should be reported as disconnected/failed.
• Other MCP servers and non-MCP functionality should still load.
• If OAuth/user interaction is required and cannot complete at startup, that server should fail soft rather than block agent startup.

Actual behavior

• Hermes could not be started because of the Atlassian MCP server failure.
• Removing/disabling that server from config was required to get going again.

Notes

There may already be partial graceful-failure handling in discover_mcp_tools(), so the blocking behavior may be happening specifically in the OAuth startup/connect path, or in how startup waits on discovery.

I also noticed tools/mcp_oauth.py currently uses interactive browser/callback behavior for OAuth flows, which seems risky during startup for non-interactive or partially interactive runs.

Suggested direction

• Ensure MCP discovery failures are always non-fatal to Hermes startup.
• Treat interactive OAuth initiation during startup as opt-in or fail-soft.
• Surface a clear warning telling the user to run an explicit reconnect/reload/auth flow rather than blocking startup.

Workaround

I removed the Atlassian MCP server from local ~/.hermes/config.yaml and Hermes started normally afterward.