slimdex — an MCP server that reduces token usage and has several useful tools

[Siddhukaushik]

I kept watching agents burn context on the same thing: to change one function, read the whole file. Then pay for that file again on every later turn, because the conversation is re-sent each time.

slimdex is a local MCP server — 30 tools — that tries to make the narrow path the easy one. Instead of a file-reading tool, it exposes retrieval shaped like the questions agents actually ask.

Finding things without opening files

find_definition, find_references, search_symbols (fuzzy, ranked exact→prefix→substring→subsequence), and search_code all answer in path:line:col rather than file contents. search_intent handles the case where you know what the code does but not what it's called — BM25 ranking over symbols, no embeddings, no external service.

context_pack bundles a whole topic — ranked symbols, how they connect, and the top bodies under a token budget — into one call, instead of ten calls that each get re-costed on every subsequent turn.

Reading narrowly, and actually following through

get_file_skeleton returns signatures with bodies elided and nesting preserved, then get_symbol_context names:[...] pulls only the bodies that turned out to matter — several in a single call. On a 6,200-line, 313 KB file this was ~34,000 chars across 8 calls versus 3–4 forced full reads (~78–85k tokens). The bug's diagnosis was visible in the skeleton's signatures before a single body was opened.

A repeat read_lines/outline_file on an unchanged file answers with a pointer to the earlier call instead of the body — the same file doesn't get bought twice.

Knowing what a change breaks, before making it

This is the part I use most and mentioned least. Before touching a symbol:

• dep_graph — imports / dependents, BFS to a given depth, or a Mermaid diagram of the neighbourhood
• get_context — opt-in definition / signature / callers / imports / dependents, budgeted
• find_tests — which references live in test files, so you run only the covering tests, or see that none cover it and treat that as risk
• changed_files — which symbols a dirty tree's hunks actually land in

Editing without re-sending the code

replace_symbol rewrites a function or method addressed by name, so the old body is never re-sent purely so a tool can locate the edit. Output tokens cost roughly 4–5× input, so this is where the money is — and the leak is otherwise invisible, because the expensive path still produces a correct edit. stats reports read follow-through and write discipline explicitly:

write discipline:
  replace_symbol: 0 call(s), 0 symbol(s) rewritten by name
  changed outside slimdex: 12 file(s)
  pre-edit checks (find_tests/dep_graph/get_context/changed_files): 0

External edits are inferred from content hashes moving between index_repo runs, so that number is honest about its limits: it sees that bytes changed, never which tool changed them.

Across sessions, not just within one

brief opens a session with a repo summary, journal-derived focus, and saved conclusions checked against the live index (✓ live / ⚠ maybe stale). recap reconstructs what prior sessions did from the tool-call journal even if nothing was explicitly saved. memory_save/search/list/delete persist conclusions; digest_save/digest_get store an architecture cheat-sheet with a per-file freshness verdict. A long session compounds roughly quadratically, so the real fix is ending it and starting informed — that only works if the next session can pick up what the last one learned.

The uncomfortable part: advice loses to reflex

The retrieval guidance ships in the server's MCP instructions rather than a README nobody injects. It still wasn't enough. Three audit sessions read "use replace_symbol" on every turn and reached for the built-in Edit anyway — the built-ins are shorter, always present, and heavily represented in training.

Nothing inside slimdex can fix that, because MCP is additive: a server exposes tools, it cannot wrap or replace a client's built-in Read/Edit/Write, and there's no capability negotiation where a server registers as the implementation of editing. So there's an optional PreToolUse hook (install_hook) that sits where the deciding signals actually exist at call time — how much old code you're about to re-send, and whether a definition covers it. Claude Code only; other clients have no equivalent, so it's one client's integration, not a universal fix.

Numbers, with the caveats attached

Self-measured on my own repos: ~55–60% on navigation-heavy work, ~45% on output-heavy work, ~50% averaged. The single-giant-file case above hit 85–90% on exploration specifically. The scaling law seems to be that the saving tracks how much irrelevant code the naive path would have dragged in — one huge file is the best case, a repo of tiny files roughly breaks even.

These are single sessions, self-measured, no repetitions or variance, and stats counts characters rather than tokens (÷3.5–4). Not a benchmark. Parsing is regex-based rather than tree-sitter, which is a real limitation and the README says where it breaks down. There's also a lean profile that advertises 15 tools instead of 30, because the tool schemas themselves are re-sent every turn.

claude mcp add slimdex -- npx -y slimdex-mcp

Registry: io.github.Siddhukaushik/slimdex-mcp · npm: slimdex-mcp · MIT

I'd be curious whether the narrow-retrieval framing holds up on codebases larger than the ones I've tested against, and where it falls over.

[bobleer]

That built-in-tool gravity is probably the most useful result here. I would separate “bytes avoided before the first correct edit” from total session savings; otherwise retrieval quality and the model’s willingness to obey MCP instructions get mixed together. Did the 15-tool lean profile change tool selection at all, or only schema overhead?

[Siddhukaushik]

Agreed — that's the right cut. The ~50% number conflates retrieval quality with whether the model actually reached for the tools, and those fail for different reasons; "bytes avoided before the first correct edit" is a sharper boundary than anything I've been measuring.

On lean: honestly unmeasured. It was built purely as a schema-overhead lever (~22,300 chars of tool schema per turn at 30 tools vs ~12,600 at 15, with the rest still reachable through batch), and I can't answer it retroactively either — the tool-call journal doesn't record which profile was active, so past sessions can't be split. Fixing that first, then comparing selection distributions across matched tasks.

I'm working on a proper solution to the built-in-tool gravity problem rather than just measuring it — more updates on the way. Will come back with numbers instead of a story about what I expect to find.