Proposal: `mnemon mcp serve` — one MCP server instead of N per-harness integrations

[vsquared10]

Problem

mnemon setup supports ~17 CLI harnesses and zero MCP clients. Any agent
without a shell therefore cannot reach mnemon at all — Claude Desktop most
notably, but the same applies to any GUI or hosted client.

Those clients fall back to their own internal memory, which no other harness can
read. The result is a one-way leak: an insight captured in a shell-less client
is invisible to Claude Code, Hermes, Cursor and everything else, and is often
capped and evicted on top of that. For a tool whose value is shared memory
across agents, a whole class of agents is currently outside the loop.

There is also a maintenance cost on the project side. The current integration
model is O(n): every new harness needs its own config writer plus skill and hook
templates, and the list is already seventeen long.

For users (like myself) who use both desktop features & chat alongside CLI tooling, sharing insights across environments is super valualbe and a big reason why i'm a mnemon user in the first place.

Proposed solution

A mnemon mcp serve subcommand alongside setup, speaking JSON-RPC 2.0 over
stdio. Same binary, same install, no sidecar.

Suggested tool surface, mapping 1:1 onto existing commands so there is no new
semantics to maintain: recall, search, remember, related, link,
status.

This is O(1) rather than O(n): one server covers Claude Desktop, Cursor's MCP
mode, Windsurf, Zed, LM Studio, and clients that don't exist yet, with no
per-client code.

Two things worth designing in from the start, both learned from running a
prototype against Claude Desktop:

1. Truncate results by default. Stored insights are routinely multi-KB. An
   unbounded recall --limit 10 floods a GUI client's context — in my store one
   insight alone is ~4KB. Trimming each result (~600 chars) with a full: true
   escape hatch keeps recall usable without losing access to the full text.
2. Echo the client's protocolVersion from initialize rather than
   asserting one, so the server doesn't fight clients over protocol revisions.

Alternatives considered

• mnemon setup --target claude-desktop. The natural first thought, but it
  doesn't work: setup's model is to write config plus skill/hook templates, and
  a shell-less client can't execute hooks or invoke the CLI. Config alone gives
  it nothing to call.
• Letting GUI clients use their built-in memory. This is the status quo and it
  is the problem — that memory is invisible to every other harness, so it
  defeats the point of a shared store.
• A third-party sidecar. Works (see below), but it lives outside the repo,
  versions independently of mnemon, and users have to discover it. A subcommand
  ships with the binary and stays in sync with the CLI surface it wraps.
• Doing nothing. Reasonable if MCP clients are considered out of scope —
  CONTRIBUTING scopes integrations to "LLM CLIs", and MCP clients are adjacent
  to that rather than inside it. That scope question is really what this issue
  is asking.

Additional context

• I have a working stdlib-only Python prototype implementing the above surface,
  currently running against Claude Desktop. Happy to share it as a reference spec
  — it is not offered as the merge artifact. A Go subcommand is the right home
  in this codebase, and I'd rather the tool surface and truncation behaviour be
  settled here before anyone writes it.
• Here is an example of a working obsidian MCP that I use for Claude Desktop that works well.

Happy to take the implementation if the approach sounds right.

Precedent: #2 (Hermes Agent integration) followed a similar propose-then-build
path.