whitemagic
Use the wm meta-tool to access WhiteMagic's local-first memory, session, galaxy, and mesh capabilities through explicit or NLU routing.
Exposes one writable MCP meta-tool,
wm, covering 59 curated tools.Record, search, retrieve, and inspect memories (
memory_remember,memory_recall,memory_get,memory_stats).Manage sessions for checkpointing, recording, listing, and cross-session continuity.
Manage galaxies (
galaxy_list,galaxy_fork) and sync mesh state (mesh_sync).Dispatch explicitly with
route=(e.g.memory.create,session.start,galaxy.list).Route natural-language requests with
thought=(e.g. remember that X is Y, search for Z).Pass target-tool arguments with
args=and discover tools by saying "list tools".Operate on a writable local store at
/root/.local/share/whitemagic/lmdb; no required hosted service.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@whitemagicSave this important decision to memory: use TypeScript for the new API."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
WhiteMagic
A local-first memory layer for MCP agents.
WhiteMagic gives an AI agent durable project memory over MCP: record important context, find it after restart, and carry useful decisions into the next session — without sending your memory store to any hosted service.
You are an agent reading this repo? Start with skill.md (five-minute operational onboarding) and llms.txt (machine-readable index).
{
"mcpServers": {
"whitemagic": {
"command": "wm",
"args": ["serve", "--profile", "cyberbrain"]
}
}
}Hosted services (separate from the local package)
Remote MCP —
https://mcp.whitemagic.dev/mcp(streamable-http): read-only recall over a curated public corpus; keyless discovery; evaluation keys with a published 50 recalls/day allowance; OAuth 2.1; x402 session lease options published as $0.01 for 5 minutes or $0.50 for 24 hours, with a published 10,000 RPM limit; andmemory.search_batchfor up to 10 queries in one MCP call. These limits and options are described by the live server card; the batch tool is also present in the livetools/listresponse. Your local store is not uploaded to this read-only recall lane.Receipt verification and agent trust API —
https://api.whitemagic.dev: statelessPOST /verifyfor continuity-receipt bundles (/healthand/infokeyless), plus a published/erc8004/validateadapter targeting Base. See the API's live service metadata and endpoint documentation for the advertised contract.Memory Crystal client and API —
scripts/crystal_client.pyseals and opens crystal envelopes locally with AES-256-GCM or ChaCha20-Poly1305 (install the optional dependency withpython3 -m pip install cryptography). The API documentation lists crystal store, fetch, and lineage endpoints; successful hosted persistence and retrieval are not implied by local encryption support.The helper is distributed as source in this repository; it is not bundled into the
wmbinary or platform installers. Use the helper from the source revision matching the server/API you intend to use. Generate a client key into a protected file withpython3 scripts/crystal_client.py genkey --out crystal.key, then pass that file tosealandunsealwith--key.sealobtains the owner locator from the authenticated/crystals/owner-locatorendpoint. This requires an owner credential and an existing registry mapping; a payment or session pass does not establish ownership. If an existing crystal is unmapped, use the contact page to request a manual ownership review.Supply the bearer credential through the
WM_CRYSTAL_TOKENenvironment variable or--token-file /path/to/credential. Token files must be regular, non-symlink files with mode0600or stricter. Do not put credentials in command-line arguments or send plaintext or encryption keys to support.seal,push,pull, andlineagerequire authenticated owner access;seal,pull, andlineageno longer accept--tenant; keyless pulls and lineage queries are no longer supported. The former tenant-hash CLI flow is a breaking change.
Related MCP server: Memento
Status
WhiteMagic Gen3 (the wm 10.5.0 line). Release channel: open
alpha — public alpha for MCP agents. The version number is a compatibility
signal; the channel is an evidence claim (beta and stable each require their
own exit conditions, not a version milestone).
Install path: Linux x86-64, Linux arm64, and macOS arm64 (v10 open-alpha matrix) — install-gated (Windows x86_64 and Intel macOS x86_64 remain on the stable Gen 2
v9.3.4release line while v10 ONNX Runtime packaging is Linux glibc 2.39+ and macOS arm64). Releases also publish gzipped distributables (~58% smaller) that the installer prefers on slow links. macOS installs through the same checksum-verified installer (hardware smoke evidence in issue #2); Windows installs the stable line throughscripts/install.ps1. Every gated installer path in the active matrix is certified against the published release in CI.Support window: the current minor and the previous minor on the install-gated lines receive fixes; older minors are archival — see
SECURITY.md.Trusted, local-first, single-user operation with Landlock containment and firebreak guards.
What it does
The supported alpha contract:
trusted, local, single-user operation;
explicit MCP routes for dependable behavior;
durable memory creation and lexical search without an external model;
session record, replay, and cross-session continuity;
an end-to-end install invariant (
wm selftest) with host-health diagnostics;no telemetry by default and no required WhiteMagic cloud service;
truthful degradation when optional models or embeddings are unavailable.
Install
Download the binary and its checksum from the
latest release, then
(substituting your platform's artifact name — for example
wm-linux-x86_64, wm-linux-aarch64, or wm-macos-aarch64; the
.gz variants decompress with gunzip -c <file>.gz > <file>):
sha256sum -c wm-linux-x86_64.sha256
chmod +x wm-linux-x86_64
mkdir -p ~/.local/bin && mv wm-linux-x86_64 ~/.local/bin/wmIf ~/.local/bin is not on your PATH:
export PATH="$HOME/.local/bin:$PATH"Or use the install script (resolves the latest release, picks the right artifact for your platform, and verifies the checksum automatically):
curl -fsSL https://www.whitemagic.dev/install.sh?ref=readme | shOther channels
npx whitemagic-mcp serve # npm (no global install)
cargo install whitemagic # crates.io
docker run -i lbailey94/whitemagic:9 serve # Docker HubAdoption snapshot (2026-10-16): 5,680 npm downloads · 6,173 Docker Hub pulls · 322 crates.io downloads. Package installs are independent of the installer and grew without any website CTA — the memory layer chooses its own doors.
Verify the installation and see the product work end to end:
wm --version # wm 10.5.0
wm status # display substrate status, epoch, record counts, and store healthwm grimoire proves the environment and previews client wiring; add --write
to write detected MCP client configurations (--json for a machine-readable
report). wm selftest runs the full invariant check (a throwaway store plus
host health); see docs/SELFTEST_AND_HOST_HEALTH.md.
Everyday commands
wm status # store, epoch, record counts, store health
wm selftest # install invariant + host health (--json, --strict)
wm remember "decision text" # record a memory (--galaxy, --source, --kind)
wm recall "query" # search memories (--limit, --historical, --scope)
wm session list # sessions: checkpoint | record | continuity | list
wm serve # MCP stdio server (--profile cyberbrain is the default)The v9-only commands (doctor, connect, setup, quickstart, backup,
restore, update, seal, verify, trust, anchor) belong to the wm9
binary line, not the Gen3 wm documented here.
Connect an MCP client
Point any MCP client at:
wm serve # cyberbrain profile (default)
wm serve --profile full # full curated catalogThe server communicates over stdio. Two profiles exist:
cyberbrain(default) — 12 lean MCP tools:memory_recall,memory_remember,memory_get,memory_stats, thewmmeta-tool (explicitroute=dispatch to the catalog),session_checkpoint,session_continuity,session_record,session_list,galaxy_list,galaxy_fork,mesh_sync.full— 40 curated routes covering memory CRUD, search, sessions, receipts, galaxies, mandala, gnosis, sangha, and mesh; optional features add gated routes (decision.shortlist,decision.deliberate,decision.outcome,systemone.decide) when compiled in. A default build reports 43 routes viawm contract --json(the route count is whatever the running binary registered — that manifest is the authority).
Explicit routing is the dependable contract:
wm(route="memory.create", args={...})wm(route="session.start", args={...})wm(route="galaxy.list", args={})
Privacy and data
Your store lives locally at
~/.local/share/whitemagic/gen3(override with--store <path>orWM_STORE). Nothing is sent to WhiteMagic-operated services; there is no telemetry by default (any future sharing is opt-in, previewable, and schema-bound).Privacy flags exclude memories from responses and reasoning. They are access controls, not encryption — anyone who can read the store files can read the contents. Do not store credentials in memories.
Conversation capture happens through explicit tool calls, not automatically.
Backup and restore
The Gen3 wm has no backup/restore subcommands (wm backup, wm restore,
wm doctor, wm seal, and wm verify are part of the v9 wm9 line). Back up
the whole store directory while no server is running:
# Stop any `wm serve` first, then copy the store root:
cp -a ~/.local/share/whitemagic/gen3 /path/to/external/disk/gen3-$(date +%F)Keep at least one copy on a different disk or machine.
After restoring a copy, verify it with
wm selftestand inspect it withwm status.Transaction rollback (
mandala/session internals) is a short-lived undo, not a substitute for backups.
Research surface (not part of the alpha contract)
The codebase contains a larger research system beyond the product boundary:
autonomous cycles, dream consolidation, bicameral reasoning, an imagination
engine, self-play training loops, polyglot sidecars (Julia/Haskell/Zig/Koka),
a signed multi-agent mesh, holographic memory coordinates, and the rest of the
route catalog reachable via wm serve --profile full plus the optional
feature-gated routes. wm contract --json is the authority for the compiled
route set. These are research surfaces without product acceptance evidence;
they may change or be removed. Only surfaces documented in this README are part
of the product contract.
Building from source
Requires Rust 1.85+:
cargo build --release
cargo test # full test suite
cargo clippy --all-targetsAuthored Memory-Task Evaluation (32 Scenarios)
benchmarks/pinned_task_eval.py runs 32 authored scenarios, eight each for continuity, conflict, record-addressed repair, and cue-guided deterministic migration. The final frozen run is tied to public source commit 766edb2, a local source-derived candidate whose exact version and binary hash are recorded in the task report. It is not the separately signed release binary; this run does not qualify the current public-main release. The final task report and machine-readable results are archived with the evaluation. The historical 19169fa result JSON remains available separately.
Continuity: WhiteMagic scored 8/8 on decision recall, open-arc precision, cross-session crystal surfacing, and new-session track routing. The structured-metadata file baseline also scored 8/8 on decisions and arcs under the same salience rules.
agent_context.textstayed within a 1,120 UTF-8-byte cap (largest 1,091; mean of per-context ceil(bytes/4) estimates 266.625). This is a byte-based estimate, not a tokenizer guarantee; transport/debug metadata is excluded.Conflict: governed current truth and verifiable revision lineage scored 7/7. All-case current truth was 7/8 because M8 is an intentional unlinked-contradiction negative control; unlinked contradictory text is not a supersession operation. Structured files matched on governed conflict.
Repair: WhiteMagic scored 8/8 for rank-one repaired identity, poison-free top-three recall, audit-trail verification, and legitimate-neighbor preservation. Equal-information record-addressed files scored 4/8 at rank one and 5/8 for joint repair-and-preserve in the top three.
Cue-guided migration: 8/8 end-to-end success, target precision/recall, and converging-DAG verification; all 24 legitimate neighbors were preserved. These cases supply exact stale clues, query, and authoritative replacement.
These are scripted authored cases, not an open-ended model study: there is no connected model, unseen holdout, or autonomous-agent evaluation. Structured files tie WhiteMagic on continuity, governed conflict, and discovery; baseline wire overheads differ. Salience and discovery use bounded text patterns that can misread quoted, negated, stale, speculative, or unfamiliar phrasing; they do not independently prove authority or truth. Latency includes fresh process startup and unequal tool batches, so the run establishes no latency or cost advantage.
Reproduce with the reviewed candidate binary and the archived harness:
WM_BINARY=/absolute/path/to/reviewed/wm python3 benchmarks/pinned_task_eval.py
python3 -m unittest discover -s benchmarks -p test_pinned_task_eval.pyDocumentation
docs/INDEX.md— map of the documentation treedocs/SELFTEST_AND_HOST_HEALTH.md—wm selftestchecks, thresholds, and--strict/--jsoncontractsbenchmarks/pinned_task_eval.py— 24-scenario continuity, conflict resolution, and surgical repair evaluation harnessINSTALL.md— source build, store setup, optional model layerskill.md— five-minute agent onboardingllms.txt— machine-readable indexdocs/CHARTER.md— binding constitutional coredocs/NUCLEUS.md— frozen nucleus snapshotcontinuity-receipt— signed, offline-verifiable records of governed tasks (separate spec repo, Apache-2.0)CHANGELOG.md— release notesSECURITY.md— reporting vulnerabilities
Migrating from v26 / Gen2 (LMDB stores)
If you ran the retired Python version (v26) or an earlier Gen2 line, audit and
migrate its LMDB store (the directory containing data.mdb) into Gen3:
wm census ~/.whitemagic/users/local/galaxies/lmdb # zero-dependency audit
wm migrate --source ~/.whitemagic/lmdb --dry-run # preview
wm migrate --source ~/.whitemagic/lmdb # migrate into the Gen3 store
wm migrate-all --source-root <projects-root> --target-root ~/.local/share/whitemagic/gen3-projectswm quarantine <file> reviews the migration quarantine log; a WM_STORE/--store
override selects the destination.
The stack
Local memory → governed execution → verifiable continuity
whitemagic— local-first memory and session continuity for AI agentscontinuity-receipt— portable, offline-verifiable evidence for governed tasks (Apache-2.0)mandalaos-gate-lite— bounded agent execution that emits receipts (review snapshot)whitemagic-plugins— client integrations and adapters
Each repository stands on its own: WhiteMagic does not require MandalaOS, and
Continuity Receipt does not require WhiteMagic. Three entrances — use it →
whitemagic; review a protocol → continuity-receipt; attack the
security architecture → mandalaos-gate-lite.
License
MIT © Lucas Bailey and WhiteMagic Contributors
Support and security
Support: open an issue at https://github.com/lbailey94/whitemagic/issues
Support the lab (voluntary, not a service payment): Base USDC tip jar
0x213b6bB4fB073E86167c58DA6Cb6E9477557DaA8· XRPL tip jarraakfKn96zVmXqKwRTDTH5K3j5eTBp1hPy— see https://www.whitemagic.dev/support. Services are paid via x402 or evaluation keys; the tip jar unlocks nothing.Contributing:
CONTRIBUTING.mdSecurity: email lbailey94@protonmail.com (please do not open public issues for security reports)
Available Tools
1 toolwmA
WhiteMagic meta-tool — curated tool surface (59 tools). Mode: writable. Scope: store /root/.local/share/whitemagic/lmdb. Use thought= for NLU routing (e.g. 'remember that X is Y', 'search for Z', 'list tools'), route= for explicit dispatch (e.g. 'memory.create'), and args= for passthrough arguments. Say 'list tools' to discover available tools.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments to pass through to the target tool. | |
| route | No | Explicit tool name for direct dispatch (e.g. 'memory.create', 'tools.list'). | |
| thought | No | Natural language input describing what to do. Auto-routes to the best-matching tool via TF-IDF NLU classification. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It states the tool is writable and scoped to /root/.local/share/whitemagic/lmdb, which conveys mutability and persistence. However, it does not disclose what happens on invalid routing, how write operations are applied, or what the observable side effects beyond scope are, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and dense, with each sentence adding a distinct element: identity, mode/scope, parameter usage, and discovery command. It could be better structured with separation of routing versus dispatch, but no sentence is wasted and the key operational details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a meta-tool with 59 sub-tools and no output schema, the description covers the essential calling convention and discovery mechanism. It does not explain the output shape since that depends on the routed tool, nor does it mention edge cases such as ambiguous routing or invalid route names. These are notable gaps for an agent that must know what the call will return and how to recover from failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage, but the description adds meaning beyond the field names by explaining the intended role of each parameter: thought performs TF-IDF NLU auto-routing, route forces a direct tool dispatch, and args passes through arguments. It clarifies the routing model and the relationship between thought and route, which the bare schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a meta-tool exposing a curated surface of 59 tools, with a writable mode and a concrete storage scope. The phrase 'Use thought= for NLU routing... route= for explicit dispatch' makes its dispatcher role clear even though the name 'wm' and missing title are opaque. It lacks sibling differentiation because no siblings are provided, but the resource and behavior are stated specifically enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions for all three parameters: thought for NLU routing, route for explicit dispatch, and args as passthrough. It also gives concrete command examples and points to 'list tools' for discovery. There is no explicit when-not-to-use because no alternatives are listed, but the guidance is otherwise complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v9.1.0- First observed
wm
TDQS
Scored across 1 tool
Only one tool exists, so there is no ambiguity between tools. The tool description is clear about its purpose as a meta-tool and how to use it.
The single tool name 'wm' is extremely generic and provides no indication of its function. It does not follow a verb_noun pattern, but with only one tool, naming consistency is not a practical concern; however, the name itself is vague.
The server exposes only one meta-tool, which internally manages 59 tools. This is an extreme mismatch between the exposed surface and the actual scope, making it nearly impossible for agents to discover and use the underlying tools without explicit prior knowledge.
The single meta-tool hides the entire tool surface behind a routing mechanism, making the surface severely incomplete from an agent's perspective. Direct CRUD or lifecycle operations are not exposed, and the need to use thought= for NLU routing introduces fragility and dead ends.
Maintenance
Related MCP Connectors
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Cross-tool persistent memory and context for AI assistants over MCP.
Related MCP Servers
- AlicenseAqualityBmaintenanceHierarchical markdown-based memory system for AI agents. Enables efficient context management by loading only relevant rooms (directories) instead of full memory.552 PyPIMIT
- AlicenseCqualityCmaintenanceMemento is a local-first, open-source MCP middleware that gives AI agents persistent memory, proactive goal enforcement, and autonomous intelligence using a SQLite temporal graph with Reciprocal Rank Fusion retrieval.151AGPL 3.0
- AlicenseNot gradedqualityCmaintenanceLocal persistent memory for AI coding tools. Stores project context and conversation recall locally via MCP.7 npm15MIT
- AlicenseNot gradedqualityBmaintenanceProvides persistent memory for AI coding agents via MCP, allowing them to recall fragility, decisions, and bugs across sessions.198 npm3MIT