Skip to main content
Glama
lbailey94

whitemagic

WhiteMagic

Local-first memory and session continuity for coding agents.

WhiteMagic gives an AI coding 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", "curated"]
    }
  }
}

Status

WhiteMagic v9. General release for AI coding agents.

  • Supported platforms: Linux x86-64, macOS, Windows.

  • The Linux x86-64 artifact is fully static — no glibc or distribution requirements.

  • Trusted, local-first, single-user operation with Landlock containment and firebreak guards.

Related MCP server: Memento

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;

  • a complete backup, verification, and restore path;

  • no telemetry 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:

sha256sum -c wm-linux-x86_64.sha256
chmod +x wm
mkdir -p ~/.local/bin && mv wm ~/.local/bin/

If ~/.local/bin is not on your PATH:

export PATH="$HOME/.local/bin:$PATH"

Or use the install script (resolves the latest release and verifies the checksum automatically):

curl -fsSL https://raw.githubusercontent.com/lbailey94/whitemagic/main/scripts/install.sh | sh

Verify the installation:

wm --version   # wm 9.0.0
wm doctor      # environment health check

Connect an MCP client

Point any MCP client at:

wm serve --profile curated

The server communicates over stdio and exposes a single wm meta-tool. Explicit routing is the dependable contract:

  • wm(route="memory.create", args={...})

  • wm(route="session.start", args={...})

  • wm(route="tools.list", args={})

--profile curated selects the supported memory/session surface and is the default when no profile is specified. Pass --profile full for the research archive surface (see below).

Privacy and data

  • Your store lives locally at ~/.local/share/whitemagic. Nothing is sent to WhiteMagic-operated services; there is no telemetry.

  • 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

Back up the whole store root (LMDB database, search indexes, and all session/state files — not just the lmdb/ subdirectory):

# Stop the server first, then:
wm backup                                  # writes ~/whitemagic-backups/<timestamp>/
wm backup --out /path/to/external/disk     # keep copies OFF the live machine

Each backup contains the full store plus a SHA256SUMS manifest. Restore after a failure (this replaces the target store):

wm restore --backup ~/whitemagic-backups/whitemagic-backup-<timestamp> --force
wm doctor                                  # confirm health after restore

Restore verifies every file against the manifest before touching anything, and refuses tampered or incomplete backups. Notes:

  • wm seal / wm verify detect integrity drift; they do not recover data. Only a backup recovers data.

  • Transaction rollback (transaction.rollback) is an in-store, short-lived undo — not a substitute for backups.

  • Keep at least one backup on a different disk or machine.

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 a 237-tool archive reachable via wm serve without a profile restriction. 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-targets

Documentation

Migrating from v26 (legacy Python)

If you ran the retired Python version:

wm migrate --v2-dir ~/.whitemagic/users/local/galaxies --dry-run   # preview
wm migrate --v2-dir ~/.whitemagic/users/local/galaxies              # migrate

License

MIT © Lucas Bailey and WhiteMagic Contributors

Support and security

Available Tools

1 tool
wmA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoArguments to pass through to the target tool.
routeNoExplicit tool name for direct dispatch (e.g. 'memory.create', 'tools.list').
thoughtNoNatural language input describing what to do. Auto-routes to the best-matching tool via TF-IDF NLU classification.

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev9.1.0
    • First observedwm

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency1/5

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.

Tool Count1/5

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.

Completeness1/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Hierarchical markdown-based memory system for AI agents. Enables efficient context management by loading only relevant rooms (directories) instead of full memory.
    5
    MIT
  • A
    license
    C
    quality
    A
    maintenance
    Memento 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.
    15
    1
    AGPL 3.0