
fittok
io.github.likhithreddy由 GitHub 账号 likhithreddy 发布v0.11.1更新于 Oct 24, 2026
Retrieve only the relevant code for a codebase question, within a token budget.
概览
一个本地 MCP 服务器,针对代码库问题在 token 预算内只检索相关源代码,让助手无需读取整个文件即可作答。
- 可以做什么
- 针对仓库问题检索相关的源代码片段,按 token 预算裁剪,并附带代码库地图以便后续定位。将仓库解析为函数/类知识图谱,支持 Python、JS/JSX、TS/TSX、Java、Go 和 Rust,并包含调用与导入关系。通过语义嵌入、关键词与结构 BM25、PageRank 的混合方式排序,返回所选节点的真实源码。借助文件监视器只重新解析变更文件以保持图谱更新,图谱与嵌入缓存在磁盘上。也可作为 CLI 和 Python 库使用,支持原始代码查询和交互式图谱视图。
- 适用场景
- 适用于助手回答代码库问题、且希望通过一次调用返回相关代码来减少输入 token 和成本的场景。最适合指明函数、组件或路由的聚焦问题;宽泛的功能问题应拆成几个查询。
- 运行要求
- 作为本地进程运行。需要 Python 运行时(3.10 或更高)或 uv/pipx,推荐以 uvx fittok 启动。首次运行会下载约 90 MB 的嵌入模型并使用 torch。可选的 ANTHROPIC_API_KEY 或 OPENAI_API_KEY 用于 CLI 模式的 LLM 回答。可选 FITTOK_MAX_BUDGET、FITTOK_AUTOWATCH、FITTOK_CACHE_DIR 等设置用于调整行为。
安装
在 SourceWeft 中
- 打开 控制台中的 fittok,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
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
-
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.
-
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.
-
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
runSandboxQueryexecute 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.jsonfile, 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=1200in your MCP server's env: - 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.
- Cap the output for Copilot so it's delivered inline (under the ~7 KB threshold). Set
- 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 aFITTOK_MAX_BUDGETcap). - 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 orpipx, swap that forpython -m fittokorpipx run fittokrespectively.
Prerequisites — choose a runtime (one of)
A. uv — recommended (no Python needed on the machine)
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)
Launch command: python -m fittok (Windows: py -m fittok).
Managed Linux may reject
pip installwith PEP 668 ("externally-managed-environment") — use option A to avoid it.
C. pipx — isolated, no global install
Launch command: pipx run fittok.
MCP server — Claude Code
Restart Claude Code → /mcp → confirm fittok is connected, then ask
codebase questions normally.
MCP server — VS Code / GitHub Copilot Chat
Or paste into .vscode/mcp.json (workspace) or your user mcp.json:
Then in Copilot Chat: Agent mode → enable fittok's tools (Configure Tools).
MCP server — GitHub Copilot CLI
MCP server — Cursor / Windsurf / any MCP client
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"):
- Call the fittok MCP tool first, once.
- Answer directly from its
optimized_context— it is the real, authoritative source for that question.- 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
query sends the relevant code slice to an LLM and streams the answer.
Set one key in your shell and it just works:
Users of Claude Code already have ANTHROPIC_API_KEY set — no extra step needed.
If neither key is set, fittok falls back to --code and prints a setup hint.
graph requires pyvis: uv pip install "fittok[ui]".
Python library
Upgrading
uvx caches the environment, so a new fittok release isn't picked up
automatically — server restarts reuse the cached version. Upgrade with one
command (no need to re-register the MCP server):
Then restart the MCP server (reload the window in VS Code, or restart the Copilot CLI) so it boots the new version. For other runtimes:
- pip:
python -m pip install --upgrade fittok - pipx:
pipx upgrade fittok
Why tree-sitter, not LSP?
fittok uses tree-sitter (fast, syntactic AST parsing) instead of LSP (Language Server Protocol — semantic analysis with types, cross-file references, go-to-definition). This is a deliberate tradeoff:
fittok's USP is token savings. It returns the actual code in one call so the model doesn't need to read files. LSP-based tools return metadata (symbol names, reference lists) — precise, but the model still has to open the files to see the implementation. More round-trips, more tokens.
The tradeoff: tree-sitter can't resolve cross-file references as accurately as LSP (a fetch("/api/run") call in a .tsx file won't perfectly link to the route handler). fittok compensates with 4-signal retrieval (semantic + content-BM25 + structural summary-BM25 + PageRank, fused via RRF) and round-robin directory diversity — which cover the gap in practice.
Complementary, not competitive: LSP-based tools like Serena excel at symbol-level navigation ("find all callers of runSandboxQuery"). fittok excels at semantic retrieval ("how does SQL execution work?"). Install both — the model picks the right tool per task.
Token savings — honest numbers
On a real Next.js/TS repo (~5k functions), fittok returns a ~1.5–3.5k-token
slice instead of the model reading 15–20k+ tokens of files — an ~80–90%
reduction on input, deterministic and reported in the savings footer.
On Opus 4.8, a broad question cost ~84k total tokens without fittok vs ~27k with it — because fittok replaced a 58k-token Explore subagent with one tool call.
How to measure it honestly:
- Use the
🪙 saved X%footer or your API bill (total tokens). - Do not judge by Claude Code's
/contextMessages number — it excludes subagent tokens and is dominated by model reasoning, which fittok doesn't touch.
Configuration
Full reference: docs/HANDBOOK.md
Requirements
Python ≥ 3.10. First run downloads a ~90 MB embedding model. Graph visualization
(fittok graph) is included by default. Optional extras:
uv pip install "fittok[ui]"— Gradio web dashboard (launch_uitool)uv pip install "fittok[gpu]"— torch/CUDA for GPU-accelerated embeddings
License
MIT
来源:README.md,提交 11d9bec
工具
0版本历史
1- v0.11.1最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分