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., "@lean-context-mcp give me the outline of src/server.ts instead of the whole file"
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.
An MCP server that helps coding agents (Claude Code, Cursor, any MCP client) use fewer tokens.
Instead of reading whole files, dumping raw grep output, or pasting full test logs into the context, the agent asks for exactly what it needs:
a file's outline (symbols and line ranges) instead of the whole file,
one function instead of the whole file,
a compact search that still lists every matching file,
test / lint / tsc output reduced to the failures.
Measured on a real TypeScript monorepo: 84.5% fewer tokens on like-for-like tasks, 81.7% after counting the tool definitions themselves (details and honest limits below).
Needs Node ≥ 20. ripgrep (rg) is recommended for fast search; without it a slower built-in JS search is used automatically.
npx -y lean-context-mcp # starts the stdio server (your MCP client normally runs this for you)# for the current project (roots default to the directory Claude Code starts in)
claude mcp add lean-context -- npx -y lean-context-mcp
# for every project, with explicit roots
claude mcp add --scope user lean-context -e LEAN_ROOTS=/Users/you/code -- npx -y lean-context-mcp~/.cursor/mcp.json (global) or <repo>/.cursor/mcp.json (project):
{
"mcpServers": {
"lean-context": {
"command": "npx",
"args": ["-y", "lean-context-mcp"],
"env": { "LEAN_ROOTS": "/Users/you/code/myrepo" }
}
}
}Set LEAN_ROOTS for Cursor: the server's working directory is not guaranteed to be your project.
Run npx -y lean-context-mcp as a stdio server (command npx, args ["-y", "lean-context-mcp"]), with LEAN_ROOTS in its environment. You can also install it once with npm i -g lean-context-mcp and use the command lean-context-mcp.
Agents prefer their built-in tools unless told otherwise. Add one line to CLAUDE.md, AGENTS.md or .cursor/rules:
Use lean-context tools (
outline,read_symbol,search,run_compact) before reading whole files or running raw commands.
Related MCP server: token-shrink
LEAN_ROOTS is the list of folders the tools may read, search and run commands in (separated by : or ,). Anything outside, including .. and symlink tricks, is refused. If it is not set, the server's current directory is the only root. Relative paths in tool calls resolve against the first root.
LEAN_ROOTS=/Users/you/code/app:/Users/you/code/libtool | what it returns |
| A file's symbol map (kind, signature, line range) or a directory map ( |
| The source of one symbol ( |
| ripgrep (JS fallback if |
| Runs an allowlisted command with no shell and a timeout. Returns the exit code, the duration and only the failures, with dedupe and head+tail trimming. Has extractors for vitest, jest, phpunit/Pest, pytest, tsc, eslint and go test. The full log goes to a temp file (mode 600) whose path is returned. Small outputs (≤ ~1200 chars, or when squeezing would not shrink them) come back verbatim with only a |
| Per-file notes keyed by content hash in |
| Get, set or append |
The six tool definitions cost about 1,400 tokens per session (measured).
Measured on a ~10k-line TypeScript monorepo (Fastify + Prisma + workers) with @anthropic-ai/tokenizer (cl100k_base as a cross-check). "Before" is what an agent would otherwise read (whole file, raw rg -n -C2, raw command output); "after" is the tool's exact output. The run_compact rows ran on a scratch copy with injected failures.
scenario | before tok | after tok | saved | needed info kept |
outline: approvals.ts | 3977 | 239 | 94% | yes |
outline: orchestrator.ts | 4585 | 163 | 96.4% | yes |
outline: auth.ts | 4179 | 72 | 98.3% | yes |
read_symbol: decideApproval in approvals.ts | 3977 | 1174 | 70.5% | yes |
read_symbol: createWorktree in git.ts | 2933 | 209 | 92.9% | yes |
outline_dir: apps/worker/src read all files | 31314 | 127 | 99.6% | yes |
outline_dir: apps/worker/src vs bare rg --files | 207 | 127 | 38.6% | yes |
outline_dir: packages/core read all files | 20615 | 156 | 99.2% | yes |
outline_dir: packages/core vs bare rg --files | 236 | 156 | 33.9% | yes |
search: "consumeApproval" 14 matches | 2511 | 1678 | 33.2% | yes |
search: "AppError" 120 matches | 16967 | 2102 | 87.6% | yes |
search: "correlationId" 45 matches | 8158 | 1213 | 85.1% | yes |
search: "AppError" full detail maxMatches 500 | 16967 | 11170 | 34.2% | yes |
search: "correlationId" full detail maxMatches 500 | 8158 | 5298 | 35.1% | yes |
run_compact: unit tests all passing exit 0 | 494 | 52 | 89.5% | yes |
run_compact: unit tests 1 injected failure exit 1 | 939 | 249 | 73.5% | yes |
run_compact: eslint 2 injected errors exit 1 | 120 | 123 | -2.5% | yes |
run_compact: tsc injected type errors exit 2 | 66 | 70 | -6.1% | yes |
schema: 6 tool definitions per session | 0 | 1398 | cost | yes |
Fair total (default settings, only rows where all needed info was kept, folder view compared with a plain file list, duplicate full-detail rows left out): 49,349 → 7,627 tokens, 84.5% saved.
Including the tool definitions (1,398 tokens, paid once per session): 81.7% saved for one session doing each task once.
Comparing the folder view with reading every file instead gives 92.4%, but that overstates it, because the outline does not contain the code.
Honest limits:
Small command outputs (≤ ~1,200 chars) come back verbatim with an [exit N] marker, so they cost a few tokens more than raw (eslint −2.5%, tsc −6.1% above).
Compact search lists every matching file with its count, but shows only the first 3 match lines per file; the rest are named as +N more in this file (search path=…). Searching that file, or raising maxMatches, shows everything. Full-detail search saves only ~35%.
Tool definitions cost ~1.4k tokens per session, so a very short session can cost more than it saves.
Savings depend on your repo and on the agent actually choosing these tools.
@anthropic-ai/tokenizer matches older Claude models; for current models treat the numbers as close approximations. Ratios matter more than absolute counts.
Precedence is env > LEAN_CONFIG file (default ~/.lean-context/config.json) > defaults. Config inside a repo is never read, so a cloned repo cannot widen its own allowlist.
env | default | meaning |
| cwd | Allowed roots, separated by |
| built-in list | Replaces the allowlist; patterns separated by |
| — | Appends to the allowlist. |
|
| Location of |
|
| JSON config file |
| 8000 | Output cap per tool call. |
| 300 | Default |
|
| Path to the ripgrep binary. |
The default allowlist is npm test, npm run *, npx vitest, npx jest, npx tsc, npx eslint, tsc, eslint, phpunit, vendor/bin/phpunit, php artisan test, pytest, python -m pytest, python3 -m pytest and go test. A pattern matches as a token prefix, and * stands for exactly one token. For example, npm run * allows npm run lint -- --fix.
Every path is realpath-checked against LEAN_ROOTS, so .. and symlink escapes are rejected. Writes (notes) go through the same check, using the nearest existing ancestor.
run_compact never uses a shell. It rejects shell operators and metacharacters (|, &&, ;, >, backticks, $(), as well as program paths other than vendor/bin/* and node_modules/.bin/*. It also blocks arguments that would turn an allowed runner into arbitrary execution: go -exec/-toolexec, npm --script-shell/--node-options, npx -p/--package/-c/--call before the tool name, and pytest -p/--pyargs/--rootdir/-c/--confcutdir.
Note that allowing npm run * or npm test means running whatever those scripts contain in a repo you trust. Use LEAN_ALLOW to narrow the list.
On timeout, the whole process group is killed.
The server only reads files and runs allowlisted commands. It makes no network calls and sends no telemetry.
Run logs go to $TMPDIR/lean-context/ (mode 600). Notes go to ~/.lean-context/cache.json and <repo>/.lean-context/notes.md.
Loading several tree-sitter WASM grammars can crash Node's optimizing WASM compiler ("Fatal process out of memory: Zone"). The entry point therefore relaunches itself once with node --liftoff-only. You don't need to pass the flag. Set LEAN_NO_REEXEC=1 to disable it.
npm install
npm run lint && npm run typecheck && npm test # test builds first, then runs vitest
npm run measure -- /path/to/repo # token comparison on any repoGrammars: the 7 tree-sitter grammars used (TS, TSX, JS, PHP, Python, Go, Swift) are copied from tree-sitter-wasms into dist/grammars at build time, so the installed package does not need that 50 MB dependency.
Squeezer fixtures in test/fixtures/output are real captured outputs, except phpunit-* and artisan-fail, which are hand-written in PHPUnit 10/11 and Pest formats.
MIT
Symbol map of a file (signatures + line ranges) or dir (files with symbol counts). Use before reading files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | file or dir; relative to first root | |
| depth | No | nesting depth (file) / dir depth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description additively discloses the shape of what comes back (signatures and line ranges, or files with symbol counts), which is real value, but says nothing about ordering, truncation, or behavior on paths that don't exist.
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?
Two compact sentences with no filler, and the definitional clause comes before the workflow hint. It is slightly telegraphic (parenthetical fragments rather than full clauses), but nothing is wasted.
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 simple two-parameter read tool with full schema coverage and a readOnly annotation, the basics are covered and the return shape is sketched. However, with no output schema, the description could have said more about what a consumer does with the symbol map (e.g., line ranges enable targeted reads).
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?
Schema description coverage is 100% – both 'path' and 'depth' are documented in the schema itself. The description's '(file) / dir' phrasing echoes the path semantics without adding format or boundary detail beyond what the schema provides, so baseline 3 applies.
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?
States a concrete resource and operation: a symbol map, with the two output shapes parenthesized (file = signatures + line ranges, dir = files with symbol counts). That distinguishes it from read_symbol, which returns actual source, though no sibling is named explicitly.
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?
'Use before reading files' gives an explicit sequencing instruction, which is genuine when-to-use guidance that points toward read_symbol without naming it. There are no exclusions or explicit alternatives, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repo memory (/.lean-context/notes.md): conventions, decisions, commands.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | any path in the repo | |
| action | Yes | ||
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden, yet it only discloses the storage location. It says nothing about the semantics of mutating the store (whether 'set' overwrites, 'append' preserves), persistence across sessions, or concurrency/auth concerns for a write-capable tool.
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 single parenthetical phrase is compact and front-loads the concept of repo memory, but its brevity comes from under-specification rather than efficiency. Nothing is wasted, but too little is said to be useful.
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 three-parameter, mutation-capable tool with no annotations, no output schema, and low schema coverage, the definition is far too thin. An agent cannot tell how to choose between the enum actions or what the response of a get would look like.
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?
Schema description coverage is only 33% — 'action' has an enum but no prose, and 'content' has no description at all. The description mentions the notes file location, which loosely maps to 'path', but it never explains the get/set/append modes or what content should contain, so it fails to compensate for the coverage gap.
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 resource — a repo-level notes file holding conventions, decisions, and commands — and its backing path, but never states a verb or what the tool does with it (read, write, or append). An agent learns what is stored, not what operation is available, which leaves the purpose implied rather than stated.
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?
Nothing indicates when an agent should consult repo memory versus calling outline, read_symbol, search, run_compact, or summary_cache. There is no guidance on prerequisites, exclusions, or the conditions that make this the right sibling to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Source of one symbol (e.g. "fn", "Class.method") or a line range.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| symbol | No | ||
| endLine | No | ||
| startLine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the safety profile is covered, but the description adds almost nothing beyond that. It does not say what happens if the symbol is not found, whether `symbol` overrides `startLine`/`endLine`, whether line bounds are inclusive, or how large an unbounded range response might be.
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?
A single short sentence with the key mode distinction front-loaded and no filler. However, its brevity crosses into under-specification for a 4-parameter tool, so the efficiency does not fully pay off.
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?
Given the tool's simplicity (single-file read, no nested objects, no output schema, read-only), the description plus name plus schema is enough to attempt a call. Missing details about file targeting and mode precedence are gaps, but not blockers for a straightforward source-retrieval tool.
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?
Schema description coverage is 0%, so the description carries the full burden, yet it only clarifies `symbol` (with format examples like "Class.method") and hints at the line-range pair. It never explains `file`, whether both `startLine` and `endLine` are required together, or the precedence between the two selection modes.
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 conveys the resource (source of a symbol) and names two modes (symbol name or line range), but the verb is implicit and the required `file` target is never mentioned. It does not distinguish itself from siblings like `outline` or `search`, so an agent must infer that this fetches raw source rather than a structural listing.
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?
No when-to-use guidance and no exclusions. With siblings `outline`, `search`, and `summary_cache` all plausibly touching source, the description never says why to pick this one or when a symbol lookup should be preferred over a search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an allowlisted test/build/lint command (no shell). Returns exit code + failures only; full log path included.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| command | Yes | e.g. "npx vitest run", "pytest -x" | |
| maxLines | No | default 80 | |
| timeoutSec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real behavior: allowlist enforcement, no shell expansion, truncated output (exit code + failures) with a full log path for the rest. It omits side effects of running builds, timeout behavior, and what a rejection looks like — meaningful gaps for an execution tool.
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?
Two tight sentences: the first front-loads what the tool does and its hard constraint, the second covers the return shape and log pointer. No filler, nothing repeated from the schema.
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?
No output schema or annotations exist, so the description is the sole source of behavioral context, and it covers output shape (exit code + failures, log path) well. It still leaves an agent guessing about timeout defaults, cwd semantics, and whether running a build has side effects.
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?
Schema coverage is 50%: `command` and `maxLines` are documented in-schema, while `cwd` and `timeoutSec` are not. The description adds genuine meaning for `command` (allowlisted, no shell), but says nothing that clarifies cwd scope or timeout units/limits, so it only partially compensates for the coverage gap.
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?
States a specific verb (run) and resource (allowlisted test/build/lint command) plus the key constraint (no shell). It implicitly separates itself from the read-only siblings (search, read_symbol, outline) by being the only execution tool, though it never names an alternative. Very close to a 5, but sibling differentiation is inferred rather than stated.
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?
'Allowlisted test/build/lint' and 'no shell' imply when the tool applies and what it will refuse, giving the agent usable boundaries. However, it never says when to prefer this over, say, search or read_symbol, nor what happens when a command is not on the allowlist. Usage is implied, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Code search (ripgrep), grouped by file. Every matching file is listed with its count; big results are compacted. Literal unless regex=true.
| Name | Required | Description | Default |
|---|---|---|---|
| glob | No | e.g. ["*.ts","!*.test.ts"] | |
| path | No | ||
| query | Yes | ||
| regex | No | ||
| context | No | default 2 | |
| perFile | No | compact mode: match lines per file (default 3) | |
| maxMatches | No | full detail up to this many matches (default 30); above it: compact mode | |
| caseSensitive | No | default smart-case |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds genuine context beyond that: results are grouped per file with match counts, and large result sets are automatically compacted. It does not state the compaction trigger or what is lost in compact mode, which is the key behavioral detail an agent would want.
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?
Three short sentences with zero filler, and the most important fact (code search grouped by file) is 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 an 8-parameter tool with no output schema, the description usefully explains the shape of results and the existence of a compact mode, but it leaves the interaction between maxMatches and perFile, and path/glob scoping, unexplained. Adequate but with clear gaps for a moderately complex tool.
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?
Schema coverage is 63%, so several parameters (path, query, regex, glob) are undocumented in both places. The description clarifies only that matching is literal unless regex=true, and gestures at compaction without tying it to maxMatches or perFile, so it adds marginal meaning beyond the schema.
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?
States a specific verb and resource ('Code search (ripgrep), grouped by file') plus the output grouping model, which distinguishes it from siblings like outline and read_symbol. It never names those siblings explicitly, so differentiation is inferred rather than declared.
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?
There is no statement of when to reach for this tool versus outline, read_symbol, or project_notes. The description gives operational facts (literal vs regex, compaction) but leaves tool selection entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Short per-file notes, auto-invalidated when the file changes. get before reading; set after understanding a file.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | for set; ≤2000 chars | |
| files | Yes | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the key trait: auto-invalidation on file change, plus the 2000-char note cap. It stays silent on what get returns for uncached or deleted files, and what clear removes.
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?
Two compact sentences, front-loaded with what the cache is and its invalidation trait, then the call sequence. Nothing wasted.
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?
No output schema and no annotations, so the return shape for `get` (single note vs. map of file→note, behavior for misses) and the scope of `clear` remain unexplained. Adequate for the happy path, incomplete for an agent deciding how to consume results.
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?
Schema coverage is only 33%; the description explains the meaning of `note` (in 'set') and implicitly frames `files` as the per-file key, but the 'clear' enum value is never mentioned and the 1-50 batch limit is only in the schema.
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?
States a specific resource (short per-file notes) and its defining behavior (auto-invalidation on file change), which distinguishes it from siblings like project_notes. It does not explicitly name an alternative tool, so it stops just short of 5.
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?
'get before reading; set after understanding a file' gives explicit workflow timing for two of the three actions. It gives no guidance for the 'clear' action or for when to prefer project_notes/outline instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1outlineproject_notesread_symbolrun_compactsearchsummary_cacheScored across 6 tools
Tools are mostly distinct: outline (structure), read_symbol (content), search (find), run_compact (execute), and two memory tools. The only overlap is project_notes vs summary_cache, but descriptions clearly separate repo-level decisions from per-file notes.
Mixed conventions: verb_noun (read_symbol, run_compact), bare verbs (search, outline), and noun phrases (project_notes, summary_cache). Still readable and predictable enough to navigate, but no single pattern holds.
Six tools is well-scoped for a lean context server, with each tool covering a distinct stage of the read/navigate/remember workflow. No bloat or redundancy.
Covers navigation (outline, search), reading (read_symbol with line ranges), memory (project_notes, summary_cache get/set), and command execution with compact output. Minor gap: no explicit listing or invalidation control of cached notes beyond automatic file-change invalidation.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Research-backed lint + generation for agent context files (CLAUDE.md, AGENTS.md) + prompt enhancer.
Code-map tools for AI agents: see a repo's structure first, then edit only what matters.
