[Bug]: `hermes mcp add` silently launches chat instead of registering MCP server

[discodirector]

Bug Description

hermes mcp add <name> --url <url> does not register an MCP server. It silently falls through into an interactive Hermes chat session, with no error and no indication that the subcommand was not dispatched. The --help for the subcommand works correctly, which makes the bug look like a runtime/network problem rather than a dispatch problem.

Steps to Reproduce

hermes mcp add example --url 'https://example.com/mcp'

Expected Behavior

The MCP server example is added to the configuration; hermes mcp list shows it.

Actual Behavior

The command opens an interactive Hermes chat prompt. hermes mcp list shows no new entry. The bug is independent of the URL, of MCP, and of any network state — any invocation of hermes mcp add exhibits it (including the stdio form, since the trigger is the absence of --command, not the chosen transport).

Affected Component

• CLI (interactive chat) / MCP subcommand dispatch

Operating System

Reproduces on Linux, macOS, and Windows. Does not depend on platform.

Python Version

3.11+ (the bug is in argparse construction; behavior is identical on every supported Python).

Hermes Version

Reproduces on current main at commit cfd86dc (also reported against v0.12.0).

Debug Report

Not applicable — this is a static argparse construction bug. It can be reproduced in three lines without invoking Hermes' runtime, network, config, or MCP layers; hermes debug share would not surface useful state. Minimal repro:

import argparse
parser = argparse.ArgumentParser()
sub = parser.add_subparsers(dest='command')
mcp = sub.add_parser('mcp'); mcp_sub = mcp.add_subparsers(dest='mcp_action')
add = mcp_sub.add_parser('add'); add.add_argument('name'); add.add_argument('--url'); add.add_argument('--command')
args = parser.parse_args(['mcp', 'add', 'foo', '--url', 'https://example.com/mcp'])
print(args.command)   # → None  (should be 'mcp')

Root Cause

There is an argparse dest collision between the top-level subparser and the mcp add subparser:

1. hermes_cli/_parser.py registers the top-level subparsers with dest="command" so the dispatcher in hermes_cli/main.py can route on args.command.
2. hermes_cli/main.py:9610 registers mcp_add_p.add_argument("--command", ...) for the stdio command. Without an explicit dest=, argparse derives dest="command" from the flag name.
3. When the user runs hermes mcp add ... --url ... (no --command), argparse still writes args.command = None for that subparser flag, overwriting the top-level value of "mcp".
4. The dispatcher at hermes_cli/main.py:10455 then sees args.command is None and falls through to cmd_chat. cmd_mcp_add is never reached.

Proposed Fix

Give the mcp add --command flag an explicit, non-colliding dest:

- mcp_add_p.add_argument("--command", help="Stdio command (e.g. npx)")
+ mcp_add_p.add_argument("--command", dest="mcp_command", help="Stdio command (e.g. npx)")

…and update cmd_mcp_add in hermes_cli/mcp_config.py to read from the new dest:

- command = getattr(args, "command", None)
+ command = getattr(args, "mcp_command", None)

The user-facing CLI flag --command is unchanged; only the in-memory namespace attribute moves.

PR with the fix and a parser regression test attached.

PR Ready

I'd like to fix this myself and submit a PR.

[alt-glitch]

Related: PR #19787 fixes this. Also see prior attempt #17294 (same root cause: argparse dest collision on --command).

[alt-glitch]

Related: PR #19787 fixes this. Also see prior attempt #17294 (same root cause: argparse dest collision on --command).

[teknium1]

Fixed on main in commit 4f364c4 via @discodirector's PR #19787 (salvaged as #21204). hermes mcp add <name> --url ... now works end-to-end. Ships on next hermes update.