Hermes proposes finding local MCP configurations without copying their secrets

A September 13 Hermes proposal adds Find MCP servers and per-candidate enable switches to Desktop’s existing MCP panel. It builds on the earlier paste-based import flow but moves discovery to the selected gateway, where existing client configuration and loopback listeners can be inspected. The intended convenience is explicit reuse, not inheritance between profiles.

The source set includes Hermes profiles, Claude Code, Cursor, Claude Desktop and Codex’s user-level configuration. Discovery reads definitions without launching stdio servers or installing their packages. Local HTTP candidates must answer an MCP initialize probe rather than merely occupy a port. A later Codex addition translates commands, working directories, environment references, headers, timeouts and tool filters while preserving the source’s deny-after-allow policy.

The facts

- Discovery does not read dotenv files or token stores and does not launch configured stdio programs. - Inline credentials make a candidate unavailable; the UI receives metadata rather than the full configuration. - Connecting re-reads and fingerprints the source, refusing stale entries and destination-name collisions. - The proposal writes through the canonical profile-scoped configuration owner and uses the existing reload flow. - Candidate metadata expires after five minutes; Codex discovery covers user-level config, not project layers or token migration. - The original implementation reports 173 backend and 29 Desktop tests; the Codex follow-up reports 55 conversion tests but leaves eight backend integration cases unexecuted.

Why it matters

MCP setup is often repeated across coding clients even when a machine already has the necessary definition. A discovery screen can remove that repetition, but only if reuse does not silently turn into a credential transfer or a broader tool policy. The most important design choice here is the refusal path: unsupported credential helpers and approval policies are surfaced as unavailable instead of being discarded to make an import appear successful.

Current

Inspected on 2026-09-14. The Hermes Agent stable-channel baseline is v2026.9.11 published 2026-09-11T19:20:31Z. The primary source was open (not merged) when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.

Evidence

Primary evidence: NousResearch/hermes-agent PR #110395 (https://github.com/NousResearch/hermes-agent/pull/110395). Supporting context: NousResearch/hermes-agent PR #87572 (https://github.com/NousResearch/hermes-agent/pull/87572); Nous Research — Hermes product documentation (https://hermes-agent.nousresearch.com/docs/). Public source bodies and linked documentation were inspected. Contributor test results remain attributed reports, not independently reproduced experiments.

Operator take

Before enabling a discovered server, inspect the destination profile, required environment references and effective tool filters. Reusing a command is not proof its dependencies or credentials exist in that destination. A useful acceptance test changes the source after scanning and verifies that activation refuses; another leaves an empty allowlist and verifies it remains restrictive. Keep manual configuration available for authenticated, non-loopback or unusual namespace deployments.

Caveat

The PR was open at inspection. Discovery is not a complete inventory of the computer or network, and secrets are deliberately not migrated. The original browser exercise was an isolated component/backend harness, not packaged Electron acceptance. Its results must not be attributed to the newer Codex follow-up, whose full integration and desktop checks were not rerun.