Mason

Mason – the system of record for your codebase's AI assistants 👷

Persistent, provably-fresh context your assistant can't grep for: team decisions, change history, and a feature-to-file map — assembled per task in one call.

Modern agents are good at reading code. They're terrible at knowing what your team learned the hard way, what changes together, and whether yesterday's understanding still holds. Mason owns exactly that.

claude mcp add mason --scope user -- npx -p mason-context mason-mcp

Restart Claude Code, then ask: "use mason to set up this project." The assistant calls mason_init, walks you through a quick Q&A to build the concept map, and you're done.

Next session, your assistant loads the map instead of grepping 8 files to figure out what your app does.

0.6.0 note: Mason 0.6 adds decision records (save_decision), task-scoped assembly (get_context), map verification (verify_snapshot), the self-maintaining refresh loop, and richer uninitialized responses. If you set Mason up before 0.6, re-run setup once (ask your assistant to "run mason_init again") — it refreshes the marker-delimited CLAUDE.md section that routes assistants to the new tools.

0.4.0 note: Mason is MCP-only as of v0.4.0. The previous mason <command> CLI has been removed — everything runs through MCP tools, driven by your assistant. See 0.4.0 migration below if you used the old CLI.

The pain

Agentic search keeps getting better at re-deriving what's in the code — but three kinds of context can't be re-derived, and today they evaporate:

• Decisions. "We tried retrying 401s in 2023; it locked accounts." Your assistant re-suggests it next sprint, in every teammate's session.
• History. Which files change together, which dirs are dead — knowledge that lives in thousands of commits, too expensive to mine per session.
• Freshness. Any cached understanding — a wiki, a CLAUDE.md, a map — rots silently, and a confidently wrong assistant is worse than a slow one.

The fix

Mason is an MCP server that maintains three git-committed, deterministic stores and assembles them per task:

• Concept map (.mason/snapshot.json) — features and flows → files, built by your assistant, spot-checked by verify_snapshot
• Decision records (.mason/decisions/) — team knowledge the code can't express, captured by save_decision, PR-reviewed like code
• Drift engine — LLM-free proof of what's stale, per entry, with a self-maintaining refresh loop for CI

Ask your assistant to do a task and one get_context call returns the relevant features, files, tests, blast radius (git co-change + references), matching decisions, and a freshness verdict. The map itself:

{
  "features": {
    "home screen": {
      "files": ["HomeScreen.kt", "HomeViewModel.kt", "GetWeatherDataUseCase.kt"]
    }
  },
  "flows": {
    "weather fetch": {
      "chain": ["HomeViewModel.kt", "WeatherRepositoryImpl.kt", "WeatherServiceImpl.kt"]
    }
  }
}

The assistant jumps straight to the relevant files instead of exploring.

Where the map comes from: Mason doesn't parse your code. Your assistant reads the project through Mason's analysis tools and writes the map itself — capturing architectural intent, not just symbols and call edges. Setup also adds a short section to your CLAUDE.md so every future session (any assistant, any teammate) consults the stores before exploring.

What the numbers say

Measured with real headless agent sessions in A/B arms (baseline always has a populated CLAUDE.md — beating a context-free agent is not a result). Full harness, pinned commits, and losses included: bench/harness/.

• Where Mason wins — knowledge that isn't in the code. On tasks whose correct answer hinges on a recorded engineering decision (seeded fairly: the baseline had the same facts in a discoverable doc), Mason averaged 9.0/10 vs 7.0/10. The baseline missed the constraint entirely half the time, and needed ~3× the turns when it found it; Mason surfaced it in one get_context call, every time.
• Stale-map safety. Against a deliberately stale map, the drift flag + changed-file previews led the agent to verify and answer current-code truth — the "confidently wrong from a stale cache" failure did not occur.
• Where it's a wash — and we say so. On questions agents can answer by reading code, quality is parity across hono (186 files), vuejs/core (483), and nestjs/nest (1676): 8.7–8.8 both arms, with Mason slightly behind on nest (8.5 vs 8.8). If your only questions are "how does X work", modern agents don't need a map.
• Cost of ownership, measured. Map builds scale linearly at ~$1.20 per 100 files (Sonnet): $3.22 for hono, $5.63 for vue-core, $19.52 for nest. Incremental refreshes after drift are cents.

Decision records

The store that makes Mason more than a map. When your assistant learns something the code can't express — a failed approach, a deprecation, a workaround's reason, a review-settled convention — it records it with save_decision:

• One JSON file per record in .mason/decisions/ — concurrent additions merge cleanly; conflicting edits to the same record surface to a human, which is the point
• Git-committed and PR-reviewed: nothing enters team knowledge without the normal review gate
• Anchored to files and drift-checked: when the anchor files change, the record is flagged for re-verification instead of silently going stale
• Surfaced by get_context as constraints exactly when a task touches them — for every teammate, in every session, on any assistant

MCP tools

The init / write tools refuse to run until mason_init has completed. The read-only diagnostics (analyze_project, full_analysis, get_code_samples) work without init.

Setup also offers to add a short marker-delimited section to your project's CLAUDE.md telling assistants to consult the map before exploring — assistants follow project instructions far more reliably than they discover MCP tools on their own.

How the concept map is built

To stay accurate on codebases of any size, Mason uses a Map-Reduce pattern instead of stuffing the whole codebase into one LLM call:

• Map: generate_snapshot_batch returns ~50 files at a time (skeletons of every file in the batch plus a few deeper-read bodies for grounding). Your assistant produces a partial concept map for that batch and persists it with save_partial_snapshot. Repeat until every file in the project has been visited.
• Reduce: reduce_snapshot returns all the partials plus instructions to merge them into one product-shaped catalog — combining platform variants ("home Android" + "home iOS" → "home screen"), deduplicating, and ensuring no file is dropped.
• Save: save_snapshot persists the unified map and cleans up the partials.

The result: every source file is represented exactly once in the final snapshot. A 200-file project takes ~5 batches; a 1000-file monorepo takes ~20.

Change impact

Before editing a file, Mason tells you what else might be affected. Three signals you'd normally need a dozen tool calls to gather, in one call:

• Co-change history — files that historically change together in commits
• References — files that import or mention the target by name
• Related tests — test files paired by naming convention

Ask your assistant "what would be affected if I changed WeatherRepository?" and it'll call get_impact for you.

Drift detection

A concept map that silently goes stale is worse than no map — your assistant confidently jumps to files that no longer do what the map says. mason_check_drift compares the map against HEAD (pure git + filesystem, no LLM call) and reports drift at the feature level: which features are stale and which files changed under them, new source files not yet mapped, ghost files the map still references, and renames. It ends with a recommendation — up-to-date, incremental (re-map just the stale entries), or full-rebuild (re-run the Map-Reduce playbook).

Ask your assistant "is the concept map still fresh?" — and if it isn't, the same report tells it exactly which entries to regenerate. get_snapshot includes the same drift report whenever it detects a stale map, so a stale map self-heals in the course of normal use.

Incremental refreshes are safe against partial updates: every entry a refresh touches is stamped with the commit it was verified against, so entries skipped in one refresh keep reporting as stale instead of silently riding along on the map's new hash. Features that disappear from the codebase can be deleted from the map with save_snapshot's removeFeatures/removeFlows — renames stop leaving zombie entries behind.

When a lot of files drifted at once, the assistant runs a scoped refresh instead of a full rebuild: generate_snapshot_batch accepts a files list, so the Map-Reduce loop walks only the drifted files and the reduce step merges the result into the existing map. 60 drifted files in a 1000-file monorepo means ~2 batches, not 20.

Drift checks in CI

Because the check is deterministic, it also ships as a tiny standalone binary — the one exception to "MCP-only", read-only and LLM-free:

npx -p mason-context mason-drift --dir .          # exit 0 fresh · 1 stale · 2 error
npx -

…