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.

已驗證STDIO僅桌面知識與記憶開發者工具

概覽

AI 產生的概覽

一個本機 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 等設定可調整行為。
安裝前請注意
CLI 的 query 指令會把選取的程式碼片段傳送給 LLM 供應商,因此使用 ANTHROPIC_API_KEY 或 OPENAI_API_KEY 時儲存庫程式碼會離開本機。檔案監看器預設開啟,並在使用者快取目錄中快取圖譜與嵌入。GitHub Copilot Chat 會截斷較大的 MCP 輸出,若未限制輸出預算,結果可能被截斷。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 fittok,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

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

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:
      json
      { "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)

bash
curl -LsSf https://astral.sh/uv/install.sh | sh   # Linux / macOSwinget install astral-sh.uv                        # Windowsbrew 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)

bash
python -m pip install fittok      # Linux / macOSpy    -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

bash
brew install pipx                               # macOSpip install --user pipx && pipx ensurepath      # Linux / Windows

Launch command: pipx run fittok.

MCP server — Claude Code

bash
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

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

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

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

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

MCP server — Cursor / Windsurf / any MCP client

json
{ "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:

ClientInstructions file
Claude CodeCLAUDE.md (repo) or ~/.claude/CLAUDE.md (user-global)
GitHub Copilot.github/copilot-instructions.md or Copilot user instructions
Cursor.cursor/rules/*.mdc (or .cursorrules)
Windsurf.windsurfrules

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

bash
cd /path/to/your/repo
uvx fittok index                                      # optional pre-warm (~15s, cached)uvx fittok query "how does auth work"                 # LLM answers from relevant codeuvx fittok query "how does auth work" --budget 1500   # cap the slice at 1500 tokensuvx fittok query "how does auth work" --code          # raw relevant code, no LLMuvx fittok graph                                      # interactive browser graphuvx fittok graph --query "auth"                       # graph with relevant nodes highlighted

query sends the relevant code slice to an LLM and streams the answer. Set one key in your shell and it just works:

bash
export ANTHROPIC_API_KEY="sk-ant-..."   # → claude-haiku-4-5  (recommended)export OPENAI_API_KEY="sk-..."          # → gpt-4o-mini  (fallback)

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

bash
uv add fittok            # in a uv project   (or:  uv pip install fittok  in a venv)
python
from fittok import optimize
result = optimize("/path/to/repo", "how does authentication work", token_budget=1500)print(result["optimized_context"])   # the relevant code sliceprint(result["savings"])             # token reduction stats

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):

bash
uvx --refresh fittok        # re-resolve from PyPI → latest version

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:

tree-sitter (fittok)LSP (e.g. Serena MCP)
What it returnsActual source code — the model answers directlySymbol metadata (names, refs, types) — the model must still Read files
SetupZero config, works on any directoryNeeds language servers installed + project config (tsconfig, pyproject, etc.)
Languages8 out of the box (Python, JS/TS/TSX, Java, Go, Rust)Only as many as LSP servers you've installed
Startup~15s (parse + embed)Minutes (full project indexing per language)
Memory~100 MB (graph + embeddings)500 MB+ per language server
Model calls per question1–5 (one-shot retrieval)5–20+ (iterative symbol navigation)
Token cost~2,500 tokens (code delivered directly)~15,000+ tokens (metadata + file reads)

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 /context Messages number — it excludes subagent tokens and is dominated by model reasoning, which fittok doesn't touch.

Configuration

VariableDefaultDescription
ANTHROPIC_API_KEY—Enables LLM answers via claude-haiku-4-5
OPENAI_API_KEY—Fallback LLM via gpt-4o-mini
FITTOK_SHOW_SAVINGStrue🪙 saved X% footer on MCP answers; set false to disable
FITTOK_MAX_BUDGET0 (unlimited)Code-token cap. 0 = return ALL relevant code in full (default — complete results in Claude Code / CLI). Set 1200 for GitHub Copilot, which truncates MCP outputs >~7 KB (see Known limitations).
FITTOK_AUTOWATCHtrueAuto-start the file watcher so graph updates are incremental (only changed files re-parse); set false to fall back to full re-parse on edits
FITTOK_EMBED_MODELall-MiniLM-L6-v2Embedding model
FITTOK_DEVICEautoauto / cuda / mps / cpu
FITTOK_CACHE_DIR~/.cache/fittokCache location

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_ui tool)
  • uv pip install "fittok[gpu]" — torch/CUDA for GPU-accelerated embeddings

License

MIT

來源:README.md,提交 11d9bec

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

1
  1. v0.11.1最新Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分