MCP Quickstart
MCP is Zaxy's primary framework-neutral interface. Start with the default local path in the repository where you want memory captured:
zaxy init
zaxy memory bootstrap --eventloom-path .eventloom
zaxy init chooses the embedded local runtime by default. It writes local profile and capture files, checks the repo-local graph projection posture, and prints the exact client install command or config path. For Codex, the default zaxy init --codex-mcp-install auto path writes or reuses user-level MCP config when it can do so non-destructively, and falls back to the copyable codex mcp add command when it cannot. No Neo4j, Postgres, Docker, Bolt URI, graph password, or hosted service is required for the local MCP path. The durable data source remains .eventloom/; the embedded graph is a rebuildable projection of that log. Human output is compact by default; run zaxy init --verbose to show every setup step, optional check, fallback command, resume command, and note when debugging an install.
Client Setup
Use one local route per client. These commands keep the default embedded graph runtime and .eventloom/ source log; no sidecar service is required.
| Client | Recommended local route | Why |
|---|---|---|
| Codex | zaxy init |
Uses zaxy init --codex-mcp-install auto to merge user-level Codex MCP config when safe, or prints the exact command when not. |
| Claude Code | Project-local .mcp.json install |
Keeps the server definition next to the trusted project without editing user-global Claude settings. |
| Claude Desktop | Copyable JSON config | Claude Desktop normally uses an app-level MCP config, so inspect and paste the generated JSON. |
| Cursor | Project-local .cursor/mcp.json install |
Cursor supports a repo-local MCP file with a top-level mcpServers object. |
| Generic MCP | Direct stdio server command | Any MCP-capable client can launch zaxy serve over stdio. |
Codex
For Codex, the fastest route is the default init path:
zaxy init
That expands to:
zaxy init --codex-mcp-install auto
Auto mode writes or reuses user-level Codex MCP config when that is safe. If an existing mcp_servers.zaxy entry is different, it asks you to review that config before replacing it. If no safe config target exists, it prints the copyable codex mcp add command.
To force a direct user-level config merge, run:
zaxy init --codex-mcp-install user
This writes user-level Codex MCP config and keeps the MCP server workspace-neutral while resolving the current workspace at runtime. Restart Codex after init so it reloads the server list.
If you prefer not to let init write Codex config, force command mode and copy or run the printed command. The command shape is:
zaxy init --codex-mcp-install command
codex mcp add zaxy -- zaxy serve
If you need Zaxy to print the exact command with resolved executable and environment values:
zaxy ide-config codex --install --eventloom-path .eventloom
Claude Code
For Claude Code, install the project-local MCP config:
zaxy ide-config claude-code --install --workspace . --eventloom-path .eventloom
This writes .mcp.json in the current workspace. Use this route for trusted projects where the MCP server should travel with the repo.
Claude Desktop
For Claude Desktop, print the app-level JSON fragment and paste it into the Claude Desktop MCP config:
zaxy ide-config claude-desktop --eventloom-path .eventloom
Cursor
For Cursor, install the project-local MCP config:
zaxy ide-config cursor --install --workspace . --eventloom-path .eventloom
This writes .cursor/mcp.json in the current workspace.
Generic MCP
For a generic MCP client, configure a stdio server command:
zaxy serve --transport stdio
After installing the client config, start a fresh model session and ask the client to list available MCP tools. You should see memory_bootstrap, memory_checkout, memory_feedback, and the Coordinate tools. If the client does not show them, run zaxy doctor --eventloom-path .eventloom and inspect the generated MCP config before changing memory code.
Model Call Rhythm
memory_checkout is the front door: call it first, with the current task, before substantial work. At session start, call memory_bootstrap for awareness, then checkout. After using projected context, call memory_feedback so Zaxy can reinforce useful memory. Everything else is plumbing or power use; memory_capabilities is the discovery surface for the rest of the tool set. The experimental memory_feeling_of_knowing offers a ~1 ms pre-check of whether checkout would likely return anything for a query — a cheap hint before checkout, never a memory answer.
For roadmap, release, review, implementation, resume, and high-context questions, treat checkout as required before answering. Bootstrap is awareness; checkout is the current cited prompt state. When checkout returns warnings, unsupported context, stale state, or a required action, follow that guidance instead of treating old model context as authoritative.
The server lists the core profile by default (since 2.1.0): only the front-door verbs (memory_checkout, memory_append, memory_query, context_assemble, memory_feedback, memory_invalidate, memory_capabilities, memory_feeling_of_knowing) appear in the listing; every other tool stays callable by name, and memory_capabilities reports the available-but-unlisted set. To restore the full listing, serve with zaxy serve --profile full or set MCP_TOOL_PROFILE=full.
For multi-agent missions, use the coordination_* tools rather than plain append calls when recording worker findings. coordination_report_finding captures worker-local claims and evidence. coordination_review_finding, coordination_promote, and coordination_checkout keep accepted parent state separate from pending or conflicted worker-local findings.
Related references: README.md, MCP interface, MCP install targets, and Coordinate Quickstart.