Summary

hermes mcp serve fails immediately on a standard pip-installed venv because hermes_cli/mcp_config.py imports a top-level module mcp_serve that is not shipped in the hermes-agent wheel.

Environment

• hermes-agent 0.15.0 (pip-installed into a venv)
• Python 3.14
• Linux — not NixOS, so distinct from [Bug]: hermes mcp serve fails to start on NixOS #22110

Repro

$ hermes mcp serve
...
  File ".../hermes_cli/mcp_config.py", line 748, in mcp_command
    from mcp_serve import run_mcp_server
ModuleNotFoundError: No module named 'mcp_serve'

$ python -c "import mcp_serve"
ModuleNotFoundError: No module named 'mcp_serve'

$ ls site-packages/ | grep mcp_serve   # nothing

Root cause

hermes_cli/mcp_config.py:748:

if action == "serve":
    from mcp_serve import run_mcp_server   # <-- bare top-level import
    run_mcp_server(verbose=getattr(args, "verbose", False))
    return

mcp_serve is a top-level module name that is not packaged/installed, so the import always raises on a normal install. This looks like exactly the class of problem tracked by the packaging restructure in #14590 (top-level modules → hermes_agent/...): the module either needs to be included in the wheel or the import needs to be namespaced (e.g. from hermes_agent.mcp_serve import run_mcp_server, mirroring the lazy hermes_cli.mcp_picker imports a few lines below).

Suggested fix

Either:

1. Ship mcp_serve in the package (add to packages/py-modules), or
2. Move it under the package and namespace the import, consistent with the sibling subcommands:

   if action == "picker":
       from hermes_cli.mcp_picker import run_picker

Happy to test a patch.