Skip to main content
Glama

Mason — построитель контекста для LLM 👷

npm version CI npm downloads license issues

Mason предоставляет LLM постоянную карту вашей кодовой базы, чтобы они перестали исследовать её с нуля в каждой сессии.

Проблема: Каждый раз, когда LLM начинает новый разговор о вашем коде, она использует grep, читает файлы и собирает архитектуру по частям — тратя токены на контекст, который она уже поняла вчера. В проекте из 164 файлов ответ на вопрос «какие функции есть в этом приложении?» требует чтения 8+ файлов с помощью нескольких вызовов инструментов.

Решение Mason: Концептуальная карта, которая сохраняется между сессиями. Один вызов инструмента возвращает таблицу поиска «функция-файл» — LLM точно знает, где искать, без необходимости исследования.

Измеренный результат (deepeval, Claude Sonnet, проект KMP из 164 файлов):

Вопрос

С Mason

Без Mason

Экономия токенов

Перечислить все функции

10 258 ток.

31 346 ток.

67%

Отследить поток данных

12 010 ток.

15 258 ток.

21%

Сравнить платформы

10 897 ток.

19 353 ток.

44%

Поток онбординга

10 271 ток.

11 432 ток.

10%

Среднее

36%

Качество ответов одинаковое (0.9/1.0 во всех тестах для обоих путей). Воспроизведение: bench/.

Быстрый старт

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

Перезапустите Claude Code, затем спросите: "use mason to analyze this project and create a snapshot."

Это всё — Mason проанализирует вашу кодовую базу и создаст концептуальную карту. В следующей сессии он загрузит карту вместо того, чтобы переисследовать всё заново.

Related MCP server: ontomics

Как это работает

Концептуальная карта

Основная функция Mason. Она сохраняет карту «функция-файл» в .mason/snapshot.json, которая сохраняется между разговорами. Когда LLM нужно понять ваш проект, она читает эту карту вместо того, чтобы использовать grep по всей кодовой базе:

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

Карта генерируется самой LLM — Mason предоставляет инструменты анализа, а LLM интерпретирует ваш код, чтобы определить, что представляют собой функции и потоки. Это означает, что карта отражает архитектурное понимание, а не просто список файлов.

Создайте её, попросив своего ИИ-ассистента "create a mason snapshot", или через CLI:

mason set-llm gemini          # configure a provider (no API key needed)
mason snapshot ~/my-project   # generate concept map
mason snapshot --install-hook # auto-update on every commit

Анализ влияния изменений

Перед редактированием файла Mason может подсказать, что еще может быть затронуто. Он объединяет три сигнала, для получения каждого из которых вручную потребовалось бы несколько вызовов инструментов:

  • История совместных изменений — файлы, которые исторически меняются вместе в коммитах git

  • Ссылки — файлы, которые импортируют или упоминают цель по имени

  • Связанные тесты — тестовые файлы, сопоставленные с целью по соглашению об именовании

mason impact WeatherRepository.kt -d ~/my-project

Также доступно как инструмент MCP get_impact — спросите своего ассистента "what would be affected if I changed WeatherRepository?"

Анализ истории Git

Mason агрегирует сотни коммитов в полезную статистику: какие файлы меняются чаще всего (горячие файлы, с которыми нужно быть осторожными), какие директории не трогали месяцами (потенциально устаревший код) и какие соглашения о коммитах приняты в команде. Это тот тип анализа, для вычисления которого вручную потребовались бы десятки вызовов git log.

mason analyze ~/my-project

Инструменты MCP

Mason предоставляет 6 инструментов через протокол Model Context Protocol. Любой MCP-совместимый клиент (Claude Code, Cursor и т.д.) может их использовать:

Инструмент

Что он делает

get_snapshot

Загрузить концептуальную карту — сопоставляет функции/потоки с файлами

save_snapshot

Сохранить концептуальную карту для будущих сессий

get_impact

Влияние изменений: история совместных изменений, ссылки, связанные тесты

analyze_project

История Git: паттерны коммитов, горячие файлы, устаревшие директории

full_analysis

Комплексный первый визит: статистика git + структура + примеры кода + карта тестов

get_code_samples

Умные превью файлов, выбранные по архитектурной роли

Использование CLI

Mason также работает как автономный CLI для генерации файлов CLAUDE.md и запуска анализа без MCP-клиента. Настройте провайдера LLM один раз, затем используйте любую команду:

mason set-llm claude|gemini|ollama|openai  # configure provider
mason generate                # analyze codebase + LLM -> CLAUDE.md
mason analyze                 # git stats only (no LLM needed)
mason impact File.kt          # change impact analysis
mason snapshot                # create/update concept map

Большинство провайдеров работают без API-ключа — claude, gemini и ollama используют свои соответствующие CLI напрямую.

Безопасность

Что содержит снимок: Имена функций, относительные пути к файлам и описания потоков. Никакого исходного кода, секретов или бизнес-логики.

Чего он не касается: Mason соблюдает .gitignore (через git ls-files) и имеет список запрещенных файлов (deny-list), который блокирует .env, .pem, .key, учетные данные и другие конфиденциальные файлы от выборки. Защита от обхода путей (path traversal) гарантирует, что весь доступ к файлам остается внутри корня проекта.

Поток данных LLM: Генерация снимка через CLI отправляет содержимое выбранных файлов вашему настроенному провайдеру LLM — так же, как любой ИИ-ассистент читает ваш код. Используйте ollama для полностью локальной генерации. Инструменты сервера MCP (get_snapshot, get_impact и т.д.) читают только локальные файлы.

Поддержка языков

Mason полностью не зависит от языка программирования. Он использует паттерны именования файлов и историю git, а не парсинг конкретного языка, поэтому он работает с любым проектом, у которого есть исходные файлы и репозиторий git — TypeScript, Kotlin, Python, Go, Rust, Swift, Java, C#, Dart и другие.

Лицензия

MIT

Available Tools

12 tools
get_contextA

Assemble task context: matching decisions with rationale, approval, owner, sources, last review, and freshness, plus related tests, file impact, and any available map entries. Map verification is rechecked against sampled source contents; stale or unknown verification requires a fresh review, and recordedVerdict preserves the historical verdict. Proposals are suggestions; legacy records are unreviewed; accepted decisions are constraints subject to freshness. No initialization or map required. Pass task and optional files. map.status and diagnostics preserve missing or invalid knowledge. Impact covers up to three unique files, expanding directory anchors.

Inputs: dir (required), task (required), files.

get_impactA

Trace historical co-change partners, related tests, and references with evidence: resolved imports, explicit paths, or uncertain name candidates. Candidates are not proven dependencies. Deterministic and read-only; no initialization or concept map required.

Inputs: dir (required), files (required).

get_snapshotA

Return the optional feature-to-file architecture map with drift and trust evidence. Map verification is rechecked against sampled source contents; stale or unknown verification requires a fresh review, and recordedVerdict preserves the historical verdict. If no map exists, returns exists:false and points to decision context. Decision capture, get_context, and get_impact still work. No initialization required.

Inputs: dir (required).

mason_automationB

Inspect installed automation, observed host events, pending decision records and the notification baseline, or check all retained documentation findings across sessions. status is read-only; check saves local baselines and verification reports without editing source, approving advisories or consuming pending completion notices. Returns concise results with a full report path. Works without a map.

Inputs: dir (required), action (required).

mason_check_driftA

Check how far the concept map has drifted from HEAD. Deterministic (git + filesystem, no LLM). Returns which features/flows are stale and the changed files behind them, new source files not yet mapped, ghost files (mapped but deleted), renames, and a recommendation: up-to-date (nothing to do), incremental (update just the stale entries via save_snapshot), or full-rebuild (broad source review required). Call this before trusting the map in a long session, or when maintaining an existing map.

Inputs: dir (required).

mason_complete_initA

Record assistant instruction setup locally in ignored .mason/local/project.json, with feature settings in shared .mason/config.json. Other tools work without this marker. Repeated calls preserve the original setup time and existing settings.

Inputs: dir (required).

mason_initA

Inspect this project now: returns documentation audit findings, committed-diff review findings, decision/map status, and a quickstart playbook. Quickstart is read-only and deterministic. Explicit mode: setup validates shared configuration and activates locally without editing shared files; mode: init explicitly prepares MCP, instructions and lifecycle hooks for review and commit. Neither runs audits or prepares repairs; use only when requested. Optional host selects codex or claude. Optional base selects the review comparison; evidence imports CI manifests with check outcomes, commit freshness, and links to changed files and accepted decisions. Repeat calls refresh findings even after setup.

Inputs: dir (required), base, host, mode, +2 more.

review_decisionA

Prepare a decision review: returns the claim and any operative accepted revision, provenance, the latest inspection and history event (notes shortened), changed files with hunk and line counts and anchor commits since the latest valid inspection for both sets of anchors, and a reviewToken. Request the diff (optionally for specific diffFiles), source previews or full history with include; the token is unchanged. For accepted-guidance inspection use inspectionScope operative on both prepare and inspect; pending proposals remain unassessed. Default all scope covers both revisions. After source inspection, record inspect with inspector, note and token to report no contradiction found without human acceptance. For human review, prepare with all scope, then record accept, reaffirm, or retire with its token, the authorized reviewer, and a reason. Acceptance replaces the operative revision; retirement withdraws the entire record including its proposal. Acceptance requires owner, source, readable Git HEAD, and committed anchor changes. Changed records or code invalidate the token. Identities and approvals are recorded assertions for normal PR review, not authenticated proof.

Inputs: id (required), dir (required), note, action, +7 more.

save_decisionA

Capture or revise a decision proposal as soon as the lesson is supported by evidence, without waiting for implementation or merge. Keep unimplemented remedies tentative. Include rationale, anchors, optional owner, sources, and a known actor. Compare matching get_context records and pending proposals before saving. When new evidence changes the same lesson's assumptions, scope, or recommended action, pass its existing id, including for accepted records. Preserve supported rationale and sources and replace obsolete instructions. Create a new record for a genuinely distinct lesson; skip unchanged restatements. No setup or map required. Writes a local record and preserves content history. Changes create a pending proposal while the last accepted revision remains operative; unchanged content does not re-verify or refresh it. Use review_decision for authorized acceptance or reaffirmation. A proposal cannot supersede a record with an operative accepted revision; review its replacement and retire the original separately.

Inputs: dir (required), body (required), title (required), category (required), +7 more.

save_snapshotA

Save a concept-to-files map as a persistent project snapshot. Maps feature names and data flows to the files that implement them. Retained for direct maintenance of legacy maps; the managed map-build workflow has been removed. Persists across conversations — future sessions can call get_snapshot to instantly find relevant files. No API key needed — you are the LLM generating the map.

Inputs: dir (required), flows (required), features (required), removeFlows, +1 more.

save_verificationA

Record verify_snapshot verdicts using each entry’s kind and reviewToken. Missing tokens request a fresh review; changed or deleted entries return conflicts without being stamped. Entries judged ok are stamped verifiedAt; failures are flagged verificationFailed with your note and surface in get_context, get_snapshot, and mason_check_drift until corrected. Verdict notes are required for failures.

Inputs: dir (required), verdicts (required).

verify_snapshotA

Spot-check the concept map's CORRECTNESS (drift checks freshness; this checks entries were right to begin with). Returns a sample of entries — always the never-verified and least-recently-verified first — with skeletons of their claimed files, for you to judge whether the files actually implement what the entry claims. Report verdicts back via save_verification with each entry’s kind and reviewToken. Tokens bind the entry and bounded source evidence; changed evidence requires a fresh review. Run periodically, or after an automated refresh wrote entries no human reviewed.

Inputs: dir (required), sample.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.6/5.0

    Scored across 12 tools

    Disambiguation3/5

    Several clusters overlap: mason_init, mason_complete_init, and mason_automation all touch setup/inspection state, while get_snapshot, get_context, get_impact, and verify_snapshot all return map/context views that an agent could easily conflate. verify_snapshot with save_verification and check_drift form a defensible pairing, and the save/review decision tools are distinct, but the descriptions' dense terminology makes tool selection error-prone.

    Naming Consistency3/5

    Most names follow a verb_noun pattern (get_snapshot, save_decision, review_decision, check_drift), but only some carry the mason_ prefix (mason_check_drift, mason_init, mason_automation, mason_complete_init) while others do not. 'mason_complete_init' also breaks the verb_noun reading and is easily confused with mason_init.

    Tool Count4/5

    Twelve tools is within a reasonable band for a map plus decision-lifecycle server, and each cluster (drift, verification, decisions, setup) earns roughly its place. The setup triplet of mason_init, mason_complete_init, and mason_automation is the one area where consolidation would help.

    Completeness4/5

    The surface covers the full knowledge lifecycle: map save/get, drift checking, verification verdicts, decision save/review/accept/retire, context assembly, and impact analysis. Minor gaps exist — no tool to delete or clear a snapshot map, and no way to enumerate decisions beyond task-matched get_context lookups.

    Maintenance

    ActivityActive
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      A
      quality
      D
      maintenance
      A TypeScript tool that ranks files in your codebase by importance, tracks dependencies, and provides file summaries to help understand code structure through Cursor's Model Context Protocol.
      14
      302
      -
    • A
      license
      A
      quality
      D
      maintenance
      Extract domain knowledge from codebases to reduce LLM token consumption by 20x and time in agentic search by 10x — gathers and makes concepts, naming conventions, and vocabulary queryable via MCP.
      19
      43
      MIT
    • F
      license
      B
      quality
      B
      maintenance
      Turns local code repositories into a queryable dependency graph built from AST parsing and git co-edit history, then exposes it alongside an Obsidian vault as persistent memory. Enables context retrieval, impact analysis of proposed changes, and curation of durable prose knowledge through full-text search and Personalized PageRank classification—all fully offline without API keys or embeddings.
      30
      -