MCP server

Use MUON from a session you started yourself

You don't have to drive MUON through the app. Register MUON's MCP server with your own agent CLI once, and every session you open in that terminal gets the same shared brain: the human-confirmed memory graph and the code graph over the repository you're standing in.

muon mcp install claude      # or: codex | cursor | opencode
# restart the CLI, then inside it:
#   memory_preedit  → blast radius + prior decisions recorded about a symbol
#   code_query      → find code by concept instead of grepping

install writes into that vendor's own MCP config — through the vendor's own writer where one exists (claude mcp add, codex mcp add). It's idempotent: run it again and if nothing changed, nothing is written. --dry-run prints exactly what would be written without writing it. muon mcp uninstall <vendor> removes exactly the entry MUON added and leaves every other server and key in that file untouched.

What it deliberately does not write

• No MUON token. The local brain re-mints its credentials on every boot, so a token baked into a config file would go stale by the next restart. The session discovers a read/agent-tier credential from the brain's own 0600 lockfile instead.
• No API base. Setting one would switch off that lockfile discovery, and the session would fail every call. If you already export MUON_API_BASE in your shell for something else, muon mcp status will tell you it's the reason something looks wrong.
• No mode or privilege flag, by default. An installed session holds agent tier, never operator tier. It cannot approve, confirm a memory note, or answer a gate. Memory it adds is an unconfirmed proposal until you confirm it on a MUON surface.

What the read tier exposes

Every governed session — including one you attached by hand — gets the same 25-tool base: 20 context tools plus 5 coordination tools. Nothing here can approve, dispatch, or widen anything.

Context (20 tools)

memory_search, memory_recall, memory_neighbors, memory_explain, memory_delete, memory_clone, memory_add, memory_preedit, impact_memory, preflight_edit, task_context, handoff_read, code_query, code_context, code_impact, repo_map, review_diff, data_boundaries, flow_scope, capability_preflight.

The hero is memory_preedit/preflight_edit: code-graph blast radius fused with governed memory, prior decisions, live sibling activity, and coverage evidence, at the edit boundary, in one read. Memory reads are workspace-partitioned and trust-gated — only human-confirmed memory reaches the strict gate view. memory_delete is governed by handle-scoped identity and ledger authorization; it is not a free delete.

Coordination (5 tools)

peer_message, peer_inbox, claim_files, release_files, crew_roles. Mission-bounded, horizontal, and deliberately authority-free: a peer message is untrusted data to its reader, a file claim is advisory, and crew_roles is the read side of role assignment only.

Observer and coordinator modes

Cursor and OpenCode can be installed at base/observer, but neither can hold the coordinator seat — muon mcp status prints both booleans (installable vs. can-coordinate) per vendor so they're never conflated.

One honest boundary

Check the status of an attach

muon mcp status re-verifies everything on every run: whether a brain is running, which resolver branch supplies the bearer token, whether an exported MUON_API_BASE is silently suppressing lockfile discovery, whether the recorded muon-mcp binary path still resolves (catching an app update that moved it, instead of failing silently inside your CLI), and per vendor whether the entry exists, where, and whether that CLI is even installed. muon doctor is the separate check for whether each vendor CLI is installed and logged in — MUON never logs you in and never stores a vendor token.