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.

Install it

muon mcp install claude      # or: codex | cursor | opencode | kiro | grok
# restart the CLI, then inside it:
#   memory_preedit  → blast radius + prior decisions 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, grok mcp add). It's idempotent: run it again and if nothing changed, nothing is written. --dry-run prints exactly what would be written. muon mcp uninstall <vendor> removes exactly the entry MUON added. Grok Build is attach-only — it can hold MUON's tools but is never a crew lane; see the Grok Build page.

What it deliberately does not write

No MUON token. The local brain re-mints its credentials on every boot, so a baked-in token would go stale. The session discovers a read/agent-tier credential from the brain's own 0600 lockfile instead.
No API base. Setting one would switch off lockfile discovery and every call would fail. If you already export MUON_API_BASE, 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.

What the worker base exposes

The worker base contains 50 tools: 38 context tools plus 12 coordination tools. Nothing here can approve, dispatch or widen anything.

Context (38 tools)

memory_search, memory_recall, memory_neighbors, memory_clusters, memory_explain, memory_delete, memory_clone, memory_add, memory_ground, memory_preedit, impact_memory, preflight_edit, task_context, handoff_read, code_query, code_context, code_impact, repo_map, review_diff, data_boundaries, flow_scope, docs_query, docs_context, docs_impact, capability_preflight, whoami, review_queue, review_assignment, review_submit, owed_work_list, owed_work_read, owed_work_enqueue, owed_work_pickup, owed_work_renew, owed_work_release, owed_work_wait, owed_work_wake, owed_work_close

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.

Coordination (12 tools)

publish_finding, peer_message, peer_inbox, peer_wait, peer_channel, peer_ack, claim_files, release_files, question_ask, question_status, question_withdraw, 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

base

default

A plain hand-started session gets 51 tools: the 50-tool worker base plus attach_muon.

observer

--mode observer

24 read-only tools for one chat. Requires --chat <id>. This restricted inventory excludes memory writes, peer messages, claims and dispatch.

coordinator seat

muon mcp attach

81 tools. Mints a governed dispatch seat so a session you run yourself can create tasks, dispatch, steer, interrupt, ship and assign roles — under the same capped delegation manifest as any other coordinator. Every installable lane can hold it, plus Grok Build.

Every lane MUON can install into — Claude Code, Codex, Cursor, OpenCode and Kiro — can hold the coordinator seat, and so can Grok Build (attach-only). muon mcp status prints both booleans per vendor — installable, and can-coordinate — so they're never conflated.

Attach a coordinator seat

muon mcp attach claude --workspace <dir>   # or: codex | cursor | opencode | kiro | grok
# the seat is per (vendor, workspace); the capability token is never printed

muon mcp attach is operator-tier and session-scoped: it mints a governed dispatch seat for a CLI you run yourself, bound to one repository. muon mcp detach <vendor> revokes it. An already-running session in a supported crew vendor can file an owner-only live-attach request, which you approve with muon mcp attach --request <uuid> or decline with --reject — minting nothing until you do. Grok uses the terminal attach command; live attach requests do not support Grok.

One honest boundary

What MUON governs here

MUON governs what an installed or attached session may do to your crew and to memory. It does not govern what that session does to your filesystem — your own agent's permission prompts do, and you are sitting there answering them. A human at the terminal answering a vendor's own prompts live is a stronger posture than an unattended agent, not a weaker one.

Check the status of an attach

muon mcp status                 # tier, token source, binary path, per-vendor registration
muon mcp probe [vendor]         # ask the installed server what it actually serves
muon doctor                     # is each vendor CLI installed AND logged in

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, and whether the recorded muon-mcp binary path still resolves. muon mcp probe goes one step further: it asks the installed server what it actually serves and compares that to this build, so a stale or drifted registration is caught before a session relies on it. MUON never logs you in and never stores a vendor token.