fittok

Retrieve only the relevant source code for a question — instead of the model reading whole files — so an LLM answers codebase questions on a small, focused slice of context. Less input = fewer tokens, lower cost, faster answers.

Works three ways from one install: an MCP server, a CLI, and a Python library — plus a Claude Code plugin that injects context automatically.

📖 Full command reference → docs/HANDBOOK.md

mcp-name: io.github.likhithreddy/fittok

How it works

codebase ──▶ graphify ──▶ slurp ──▶ readable slice ──▶ LLM answers
             (parse)      (select)   (trim to budget)

1. graphify — parses the repo with tree-sitter into a knowledge graph of functions / classes / methods (Python, JS, JSX, TS, TSX, Java, Go, Rust). Supports multi-language call/import/reference edges.

2. slurp — scores every node against the question using a 4-signal hybrid:

   • Semantic embeddings (all-MiniLM-L6-v2) — meaning-based matching
   • Content-BM25 (with camelCase/snake_case splitting) — keyword matching
   • Summary-BM25 (node name + file + callers + callees) — structural matching
   • PageRank — graph centrality / hub detection

   Signals are fused via Reciprocal Rank Fusion (RRF) — rank-based, no score calibration issues. Nodes are selected via round-robin directory interleaving (guarantees facet coverage on multi-aspect queries — one node from each code area before any gets a second) with a per-node token cap (25% of budget, so large components don't crowd out smaller functions). A relevance cliff (semantic OR BM25 OR summary-BM25 threshold) excludes noise.

3. readable output — returns the actual source code of selected nodes, plus a codebase map (table of contents with docstrings, inspired by Karpathy's LLM Wiki / Google's OKF) so the model can route follow-up calls precisely. The model answers directly from it — no file reads needed.

As you edit, a file watcher (auto-started on first query) updates the graph incrementally — only changed files are re-parsed and merged, and only changed functions re-embed. Graphs and embeddings are cached on disk (~/.cache/fittok). Set FITTOK_AUTOWATCH=false to disable the watcher, in which case an edit triggers a full re-parse on the next query.

Getting the best results (and known limitations)

Ask focused questions

fittok ranks code against your question using a 4-signal hybrid (semantic + BM25 + structural + PageRank, fused via RRF) with round-robin directory diversity — so multi-facet questions surface code from multiple areas (UI, server, database) instead of clustering in one dominant area. It's most accurate with focused, specific questions — ideally one concern each, and naming the function/component/route when you can. Multi-facet questions are supported via decomposition (the tool description tells the model to call once per aspect) and the codebase map (a table of contents prepended to every response).

• ✅ "How does runSandboxQuery execute and isolate a SQL query?" → surfaces the exact function + its isolation code.
• ✅ "How does the querydle client submit a query and render results?" → surfaces the UI component.
• ✅ "Trace the full lifecycle: UI submission, sandbox execution, data isolation" → decomposition + round-robin diversity covers multiple facets; the codebase map routes the model to any missed files.

Rule of thumb: one concern per question (or 2–3 facets max). For "explain the whole feature," split it into a few focused questions instead of one mega-query.

Known limitations

• GitHub Copilot Chat truncates large MCP outputs (the big one). Copilot caches MCP tool results above ~7 KB to a content.json file, where the entire markdown collapses to ONE physical JSON line (newlines escaped) — and its Read tool truncates any line at ~2,000 characters. So an output over ~7 KB is effectively chopped to ~2,000 chars regardless of total size; the model can't see most of the code and falls back to reading source files directly. This is Copilot's delivery layer, not fittok — every MCP server hits this wall. By default (0.10.0+) fittok returns all relevant code uncapped, which is correct for clients that deliver inline but will be truncated by Copilot. Two workarounds:
  • Cap the output for Copilot so it's delivered inline (under the ~7 KB threshold). Set FITTOK_MAX_BUDGET=1200 in your MCP server's env:
    config.json

    Copy

    { "servers": { "fittok": { "command": "uvx", "args": ["fittok"], "env": { "FITTOK_MAX_BUDGET": "1200" } } } }
    

  • Use Claude Code or the CLI for multi-file questions. They deliver MCP output inline with no truncation — which is where fittok's complete (uncapped) results and anti-re-read design actually pay off.
• Vocabulary gap on abstract queries. When the query uses words that don't appear in the code (e.g. "isolation" → REVOKE/DENY), neither semantic nor BM25 can bridge it. The codebase map (file names + docstrings) and round-robin diversity help; naming the function/file routes the model to it.
• Incremental edge-loss: editing a file can drop call/import edges into it from unchanged files until a full re-parse. fittok auto-recovers on restart or reset_graph.
• Token counts are approximate: counts use cl100k_base, so real usage drifts ~10–20% vs Claude's tokenizer (only matters when you opt into a FITTOK_MAX_BUDGET cap).
• Very large repos: PageRank is not yet vectorized — fine through low-thousands of nodes, slower beyond that.

Installation

fittok ships as an MCP server, a CLI, and a Python library. It uses torch for embeddings, so a Python runtime must be present. Pick one runtime below, then follow the section for your client.

Every config below launches fittok as uvx fittok. If you chose Python or pipx, swap that for python -m fittok or pipx run fittok respectively.

Prerequisites — choose a runtime (one of)

A. uv — recommended (no Python needed on the machine)

curl -LsSf https://astral.sh/uv/install.sh | sh   # Linux / macOS
winget install astral-sh.uv                        # Windows
brew install uv                                    # macOS (Homebrew)

Launch command: uvx fittok — uv provisions its own Python + all deps in isolation. One static binary, so it's deployable org-wide via MDM/Intune/winget.

B. Python 3.10+ (already on the machine)

python -m pip install fittok      # Linux / macOS
py    -m pip install fittok       # Windows

Launch command: python -m fittok (Windows: py -m fittok).

Managed Linux may reject pip install with PEP 668 ("externally-managed-environment") — use option A to avoid it.

C. pipx — isolated, no global install

brew install pipx                               # macOS
pip install --user pipx && pipx ensurepath      # Linux / Windows

Launch command: pipx run fittok.

MCP server — Claude Code

claude mcp add fittok -s user -- uvx fittok

Restart Claude Code → /mcp → confirm fittok is connected, then ask codebase questions normally.

MCP server — VS Code / GitHub Copilot Chat

code --add-mcp '{"name":"fittok","command":"uvx","args":["fittok"]}'

Or paste into .vscode/mcp.json (workspace) or your user mcp.json:

{ "servers": { "fittok": { "type": "stdio", "command": "uvx", "args": ["fittok"] } } }

Then in Copilot Chat: Agent mode → enable fittok's tools (Configure Tools).

MCP server — GitHub Copilot CLI

copilot mcp add fittok -- uvx fittok
copilot mcp get fittok          # verify status + tools

MCP server — Cursor / Windsurf / any MCP client

{ "mcpServers": { "fittok": { "command": "uvx", "args": ["fittok"] } } }

Auto-trigger (optional, every MCP client)

To make fittok fire on every codebase question — without naming it — and stop your client from re-reading files fittok already returned (which would discard the savings), add this one line to your client's instructions file:

"For any codebase question, call fittok first and answer from its output — don't re-read files it already returned code from."

The first half triggers fittok; the second keeps the client from opening the same files afterward. They reinforce each other — one shapes strategy (use fittok), the other stops the double-read. For a stronger, more explicit block:

For any codebase question ("how does X work", "where is Y"):

1. Call the fittok MCP tool first, once.
2. Answer directly from its optimized_context — it is the real, authoritative source for that question.
3. Do NOT read or grep the files fittok already returned code from. That discards the token savings fittok exists to provide.

For the strongest effect, put it in your user-global instructions so it applies to every repo, not just one:

fittok also bakes this rule into every response (an "answer from this, don't re-read" line above the code), so it works even without the snippet above — the snippet just makes it the client's default across all questions.

CLI

cd /path/to/your/repo