MCP SERVERTracks which lines of a legacy codebase your AI analyses have actually covered — so 'how much of this have we documented?' has a number instead of a guess.
LABSCO SUMMARY
Analysing legacy code with an assistant usually produces a pile of Markdown nobody can audit; here each file declares the line ranges it covers, so the honest questions — what fraction is documented, what is untouched, which explanations no longer match the code — are answered from hashes rather than from impressions. The habit that makes it work is reconciling immediately after writing an analysis, because coverage is recorded at that step and not before. Everything lives in the repo, so a second agent in a later session starts from what the first one already covered.
Coverage accounting for code analysis. Each analysis is a Markdown file declaring the source file and line ranges it explains; a registry hashes both sides so it knows when an analysis has gone out of date with the code it describes.
Node.js 18 or newer with npx on the PATH; it runs as npx @mtimma/knowerage. KNOWERAGE_WORKSPACE_ROOT has to point at the project root, since everything is relative to it. KNOWERAGE_AUTO_FULL_RECONCILE is optional and off unless set to a truthy value; when on, a watcher rebuilds the registry after changes under the knowerage directory, ignoring its own writes so it cannot loop. Reconciliation is not automatic otherwise — an analysis written without it is not counted. State lives in the repository as analysis Markdown plus a registry JSON file keyed by analysis path, so it is reviewable and travels with the code. It can also be built from source with Cargo.
One command — npx @mtimma/knowerage
USE CASES
Have the analysis written with its source path and covered line ranges, then reconcile it straight away so the coverage is recorded.
Read the project-wide overview for coverage percentages, missing ranges and totals, computed only from records that are still fresh.
Get its analysed and missing line ranges and which analysis files claim them, instead of guessing from whatever is open.
List the records by staleness — source changed since the analysis, or the analysis edited without reconciling — and fix those first.
Rescan every analysis file and rebuild the entries in one pass, rather than reconciling each one by hand.
Export the registry as a report, or bundle the selected analyses into a combined document with a table of contents, split into parts when large.
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
knowerage_coverage_overviewBatch coverage overview for all source files. Returns per-source coverage percentage, analyzed/missing ranges, range attribution, stale records, and project-wide file/line totals. Uses fresh records only for coverage calculation. Optional extensions filter applies to sources, stale list, and project scan.
knowerage_create_or_update_docPRIMARY tool for persisting legacy/source code analysis: create or update an analysis markdown file under knowerage/analysis/ with YAML frontmatter (source path, covered line ranges, dates). Use this whenever the user asks to analyze, document, or explain a source file and Knowerage is in the tool list—do not use generic file-write tools alone for knowerage analysis paths, or the registry will not stay consistent. Follow with knowerage_reconcile_record on the same analysis_path.
knowerage_generate_bundleExport selected analysis markdown files into chunked NotebookLM-style bundles under output_dir: writes toc.md + combined.md for part 1, toc_N.md + combined_N.md for further parts when size limits require splitting, plus manifest.json (files, errors, part metadata). Every analysis_paths entry is validated under the workspace (no traversal). Per-file and per-part size limits apply (see contracts).
knowerage_get_file_statusPer-source coverage: total lines, analyzed vs missing ranges, and which analysis paths claim them. Prefer this over guessing from open files when answering 'what is documented for this source?' while Knowerage is enabled.
knowerage_get_treeGet a tree view of analysis records grouped by directory
knowerage_list_registryReturn the full analysis coverage registry in one structured JSON response. USE THIS when you need an inventory of which source files are documented, where the analysis markdown lives, which line ranges are claimed, and freshness (fresh/stale_doc/stale_src/missing_src/dangling_doc). The records object is the same shape as the entire knowerage/registry.json file (sorted keys for stable reading). Call early when planning documentation work, finding gaps, or mapping analysis paths to sources—instead of opening registry.json by hand. Optional filters: analysis_path_prefix narrows by analysis key; statuses limits to given status values (same strings as in each record). After reconcile_record/reconcile_all, call again if you need the latest snapshot.
knowerage_list_staleList registry records filtered by staleness status
knowerage_parse_doc_metadataParse YAML frontmatter from an analysis markdown file
knowerage_reconcile_allRescan all analysis markdown files matching the glob and rebuild registry entries. Use after git pull, bulk edits, or when the registry may be empty or out of date; prefer reconcile_record when only one file changed.
knowerage_reconcile_recordMANDATORY after every create_or_update_doc (or manual edit) to one analysis file: reconciles that analysis into knowerage/registry.json (hashes, covered_ranges, freshness). Call immediately after writing analysis content so coverage is recorded; skipping this leaves the registry wrong or stale.
registry_export_reportExport the registry as a report file in json, yaml, txt, or html format
BEFORE YOU INSTALL
11 tools when we connected. knowerage_coverage_overview is available but missing from the documentation's table of 10.
Node.js 18 or newer — npx must be on your PATH
The documented client runs the server on your machine.
CONTEXT COST
Rated by the size of the 11 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
npx @mtimma/knowerage{
"mcpServers": {
"knowerage": {
"command": "npx",
"args": [
"@mtimma/knowerage"
],
"env": {
"KNOWERAGE_WORKSPACE_ROOT": "${workspaceFolder}",
"KNOWERAGE_AUTO_FULL_RECONCILE": "true"
}
}
}
}${workspaceFolder} is your project root; a client that does not expand that variable needs the path written out.
MCP servers
elara-labs
3D-Tech-Solutions
srclight
kraklabs