jcodemunch-mcp レビュー: tree-sitter インデックスでコード探索のトークンを削る MCP サーバー
Cut AI token costs 95%+ on code exploration. The leading MCP server for precise, symbol-level GitHub code retrieval via tree-sitter AST. Works with Claude Code, Cursor & any MCP client. 313B+ tokens saved.
ひと目でわかる
- これは何？
- ファイル全体を読ませる代わりに、シンボル単位でソースを取得させる MCP サーバー。README が示す仕組みとベンチマークの読み方、ライセンスの二重構造、そして向かない用途を整理する。
- 誰に向いている？
- ローカルでインデックスを張り、MCP 経由でシンボル単位の取得に絞りたい個人開発者や小規模チームには向く。逆に、商用利用でライセンス条項の確認を避けたい組織、単発の小リポジトリを一度読ませるだけの用途、tree-sitter が対応しない言語が主戦場のプロジェクトには向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
どのコストを削る道具なのか
AI コーディングエージェントは、目的の関数を一つ見つけるためにファイルを丸ごと開き、無関係な行を読み飛ばす。README はこの挙動を token incinerator と呼び、削る対象は「探索のための入力トークン」だと明言している。出力トークンでも推論時間でもない。
対象読者は MCP クライアントを使っている開発者で、README は Claude Code、Cursor、VS Code、Codex CLI、Windsurf、Continue を列挙する。つまり特定の IDE に閉じたツールではなく、MCP という共通の口を介してエージェントにツールを追加する立場の人が対象になる。
ここで注意したいのは、削減率の分母が何かという点だ。README のベンチマークは二つのベースラインを並べている。一つは grep-top-3、つまりクエリ語で rg -l して一致数の多い上位 3 ファイルを丸ごと開く手順。もう一つは read-all、インデックス対象の全ソースを連結したもので、README 自身が a ceiling nobody pays と書いている。引用すべき数字は前者だと明記されている。この区別を外すと 99.6% という数字だけが独り歩きする。
インデックスに何を保存し、何を返すか
仕組みは README の記述に沿えばこうなる。ソースを tree-sitter でパースし、シグネチャ、種別、修飾名、要約、バイトオフセットといったシンボルメタデータを、生のファイル内容と並べてローカルインデックスに保存する。エージェントはファイルを再読する代わりに、このインデックスへ問い合わせて必要な実装だけをバイト精度で取り出す。
返す単位がファイルではない点が設計の核になる。README が挙げる取得系は search_symbols、get_symbol_source、アウトラインやツリーの問い合わせ、スコープを絞ったバンドル。加えて構造を問う系として get_blast_radius、find_importers、get_class_hierarchy、find_dead_code が示されている。
get_blast_radius は「X を変えたら何が壊れるか」に答えると表に書かれている。grep では原理的に答えられない問いで、import グラフをインデックス側が持っているから成立する。find_importers も同じ性質で、README の A/B テスト報告では、この構造クエリでしか出なかった発見カテゴリとして orphaned file detection が挙げられている。
レスポンス側にも圧縮がある。MUNCH というワイヤ表現で、README によれば応答バイト数を中央値 45.5% 削る。トークン削減とバイト削減は別の層の話なので、混ぜて読まないほうがよい。
導入手順と設定の実体
配布は PyPI で、パッケージ名は jcodemunch-mcp。README の VS Code 向けワンクリックリンクが展開する設定は次の形をしている。command が uvx、args が ["jcodemunch-mcp"]。つまり uvx 経由で都度起動する構成が一次の導線として提示されている。
README には MCP の登録名として io.github.jgravelle/jcodemunch-mcp という識別子も置かれている (<!-- mcp-name: ... --> の行)。クライアント側の設定ファイルに何を書くかは CLIENTS.md に分離されているので、手動設定をする場合はそちらを見る必要がある。
検証のための材料も同梱されている。benchmarks/METHODOLOGY.md に手法と既知の注意点、benchmarks/REPRODUCING.md に再現手順、TOKEN_SAVINGS.md に削減の内訳がある。README は数値を固定コミットの公開リポジトリで測ったと明記しており、追試の入口が用意されている点は評価できる。
ただし、この記事の執筆時点で当方が実際にインストールして動作を確認したわけではない。上に挙げたコマンドとパスはすべて README およびリポジトリの記述に基づく。
28.3x という数字をどう読むか
README のベンチマークは tiktoken cl100k_base で計測し、2026-09-03 に v1.108.316 で実行、三つの公開リポジトリを上流コミットに固定したと書かれている。ワークフローは search_symbols の上位 5 件と get_symbol_source を 3 回、これをクエリごとに繰り返す形。
結果は express が 15.5x、fastapi が 38.4x、gin が 20.3x、合計 15 タスク実行で 664,975 トークンが 23,467 トークンになり 28.3x。クエリ単位では 7.6x から 81.2x までばらつき、中央値は 26.1x と明記されている。「どのクエリでも 28 倍」ではない。
ばらつきの幅が大きいこと自体が、この道具の性質を示している。シンボル境界がはっきりした言語と構造、検索語がシンボル名に素直に一致するタスクでは効く。逆に、設定ファイルの散在や文字列リテラルの横断検索のようにシンボルに落ちない問いでは、grep に対する優位が縮むと考えられる。README はこの点についての言語別・タスク種別の内訳を出していない。
もう一つの数字、50 回反復の A/B テストも読み方を分ける必要がある。Vue 3 + Firebase の実運用コードベース、Claude Sonnet 4.6、各反復で新規セッション。成功率 80% 対 72%、タイムアウト率 32% 対 40%、平均キャッシュ生成量は 10.5% 減。ツール層だけを切り出した削減は 15-25% とされ、README 自身が固定オーバーヘッドと分離している。28.3x と 15-25% は同じ土俵の数字ではない。
ライセンスと保守のコスト
ライセンス表記は二重構造になっている。GitHub 側のメタデータは NOASSERTION で、README のバッジは dual-use、本文は「Free for personal use. Use it to make money, and Uncle J. gets a taste.」と書く。商用ライセンスの節が別に立てられている。
ここは当方が法的助言をする場ではないが、実務上の判断材料として一点だけ言える。リポジトリの LICENSE ファイルの実物を読まずに業務導入を決めるのは避けたほうがよい。NOASSERTION は GitHub が SPDX 識別子として認識できなかったという表示であり、条項の内容を保証するものではない。個人利用の範囲、商用の定義、収益が生じた場合の扱いは、README の一文では確定しない。
保守の面では、リリースの刻みが非常に細かい。提示された直近三件は v1.108.317、v1.108.316、v1.108.315 で、いずれも 2026-09-02 から 09-04 の三日間に収まっている。パッチ番号が三桁まで進む運用で、リリースノートの見出しも「表示設定が表示対象のデータを書き換えていた」「偽陽性の修正が偽陰性を入れることがある」といった、不具合修正単位の記述になっている。活発である一方、更新頻度に追随してバージョンを固定し続ける運用コストは利用側が負う。v1.108.317 のノートには CI が毎変更でハーネスを回し、公開は dispatched workflow だと書かれている。
向かない場面と、代わりの選択肢
第一に、単発の探索。数十ファイルのリポジトリを一度読ませるだけなら、インデックスを張る手間とローカルストレージの分だけ不利になる。インデックスを繰り返し引くから元が取れる設計だ。
第二に、tree-sitter のパーサが扱えない言語や、シンボル境界が曖昧な記法が主戦場のプロジェクト。README は対応言語の一覧を提示していないため、自分の言語が対象に入るかは導入前に確認する必要がある。ここは当方の材料では判断できない。
第三に、ライセンス条項の確認コストを払いたくない商用利用。前述のとおり README の一文では範囲が確定しない。
代わりの選択肢として README が比較対象に置いているのは、rg -l と Read を組み合わせた素の grep 運用だ。アプローチの差は明確で、grep は毎回ファイルを走査して行を返す。jcodemunch-mcp は事前にパースしたシンボル表を引き、バイト範囲で切り出す。前者はインデックスを持たないので常に最新だが、後者はインデックスの更新状態に結果が依存する。
この依存は failure mode でもある。インデックスが古いままなら、search_symbols は移動済みの関数を返し、get_blast_radius は削除済みの呼び出し元を数える。README はインデックスの再構築タイミングや陳腐化の検出方法について、提示された範囲では説明していない。エージェントに編集させる運用では、この点を自分で確かめる必要がある。
導入を決める前に確かめる三点
一点目は LICENSE ファイルの実物。dual-use という語が何を許し何を禁じるかは、README の要約ではなく条項本文で確認する。
二点目は言語対応。tree-sitter のパーサが自分の主要言語を覆っているか。覆っていなければ、この道具の中心的な利点であるシンボル単位の切り出しが成立しない。
三点目は自分のリポジトリでの再現。benchmarks/REPRODUCING.md の手順が公開されており、tiktoken cl100k_base で計測する方法も METHODOLOGY.md に書かれている。README の 28.3x は express、fastapi、gin の三件の値であって、自分のコードベースの値ではない。grep-top-3 ベースラインを自分で作り、同じクエリセットで比較する。この一手間を省くと、削減率の期待値だけが独り歩きする。
向くのは、ローカルにインデックスを置くことを許容でき、同じリポジトリを何度もエージェントに探索させる個人開発者と小規模チーム。向かないのは、単発の読解、対応言語外のプロジェクト、そしてライセンス条項の確認を後回しにしたい商用利用だ。
編集部の結論
ローカルでインデックスを張り、MCP 経由でシンボル単位の取得に絞りたい個人開発者や小規模チームには向く。逆に、商用利用でライセンス条項の確認を避けたい組織、単発の小リポジトリを一度読ませるだけの用途、tree-sitter が対応しない言語が主戦場のプロジェクトには向かない。導入前に確認すべきは三点。リポジトリの LICENSE ファイルの実物 (GitHub の表示は NOASSERTION であり、README は dual-use としか書いていない)、対象言語が tree-sitter のパーサで扱えるか、そして benchmarks/REPRODUCING.md の手順で自分のリポジトリで再現した数値が grep-top-3 ベースラインに対してどう出るか。README の 28.3x は express、fastapi、gin の三件の公開リポジトリで測った値であり、自分のコードベースの削減率を約束するものではない。
コミュニティノート