mcpField
J
Jcodemunch Mcp

Jcodemunch Mcp

ローカル
jcodemunch.com開発ツール2.8k今日更新

Jcodemunch Mcp について

jCodeMunch MCPは、コーディングエージェント向けのMCPサーバーです。tree-sitter ASTでリポジトリをインデックス化し、ファイル全体ではなくシンボル単位で実装や構造情報を取得します。

主な機能

  1. 01tree-sitter ASTによるインデックス化
  2. 02シンボル単位のソース取得
  3. 03リポジトリのアウトラインとツリー
  4. 04インポートを含むコンテキストバンドル
  5. 05コード構造のクエリ

活用シーン

  1. 01関数の実装を探す
  2. 02関連シンボルからモジュールを把握
  3. 03リポジトリ構造を調べる
  4. 04コード変更の影響を評価

MCP 対応

MCPクライアントに、リポジトリのインデックス化、シンボル検索とソース取得、アウトライン、コンテキストバンドル、構造クエリを提供します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"jcodemunch": {
"command": "uvx",
"args": [
"jcodemunch-mcp"
]
}
}
}
起動コマンドuvx jcodemunch-mcp

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
pypijcodemunch-mcp1.108.401

ツール

6

掲載時のツール一覧 · 3 週間前に更新

パラメーター型必須説明
tierenumはいcore | standard | full

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

jCodeMunch MCP

tree-sitter AST 解析による、正確なソースコード取得に最もトークン効率の高い MCP サーバーです。 コードの調査にかかる AI トークンコストを 86~99%削減し(平均 96%。grep して読み込むエージェントと比べて、ベンチマークではトークン数が 29.2 分の 1)、ファイル全体を読んでコンテキストウィンドウを無駄にするのを防ぎます。

本番環境でのリアルタイムな実績 838B+ トークンを削減 · 136,000+ 件のインストールから報告 · AI 支出を $4.2M+ 削減 · 100,000+ kg の CO₂ 排出を防止 カウンターの数値は 2026-08-17 時点のものです。Claude Opus の 入力 料金 $5/MTok で換算しています。いずれも増え続けているため、これらは最低値です。リアルタイムの数値は jcodemunch.com でご覧いただけます。

Claude Code、Cursor、VS Code、Codex CLI、Windsurf、Continue、およびあらゆる MCP 互換クライアントで動作します。

今すぐインストール · クイックスタート · 実績を見る · 料金

PyPI version PyPI - Python Version License MCP Local-first Issues closed DOI

個人利用は無料です。 これを使って収益を得るなら、Uncle J. も少し分け前をいただきます。いかがでしょうか?商用ライセンスはこちら。 保証:jCodeMunch の費用を回収できなければ、jCodeMunch の料金はいただきません。


jCodeMunch を選ぶ理由

多くの AI エージェントは、リポジトリをコストのかかる方法で調査します。ファイル全体を開き、無関係な何千行もの内容に目を通し、それを繰り返します。これは「少し非効率」どころではありません。トークン焼却炉です。

jCodeMunch はコードベースを一度だけインデックス化し、エージェントが必要とするコードだけを正確に取得できるようにします。関数、クラス、メソッド、定数、アウトライン、対象を絞ったコンテキストのバンドルを、バイト単位の精度で取得します。tree-sitter でソースを解析し、構造化されたシンボルのメタデータ(シグネチャ、種類、修飾名、概要、バイトオフセット)とファイルの生の内容をローカルインデックスに保存します。ファイルを何度も読み直す代わりに、必要に応じて正確な実装を取得します。

タスク従来の方法jCodeMunch を使う場合
関数を探す大きなファイルを開いて読み進めるシンボルを検索し、正確な実装を取得する
モジュールを理解するファイルの広い範囲を読む関連するシンボルとインポートだけを取得する
リポジトリの構造を調べるファイルを一つずつたどるアウトライン、ツリー、対象を絞ったバンドルを照会する
「X を変更したら何が壊れる?」不可能get_blast_radius

一度インデックス化すれば、低コストで照会できます。作業を続けましょう。力任せのコンテキストより、精度の高いコンテキストが勝ります。


実績

再現可能なトークン効率ベンチマーク

上流コミットに固定した3つの公開リポジトリを対象に、2026-10-15にv1.108.364で実行し、tiktoken cl100k_baseで測定しました。ワークフロー:クエリごとにsearch_symbols(上位5件)+get_symbol_source × 3。2種類のベースラインを、同じ実行、同じコーパス、同じファイルリーダーで測定しました。

  • Grep-top-3:クエリ語をrg -lで検索し、一致数でファイルをランク付けして、上位3件を全体を開きます。これはツールを使わない有能なエージェントが実際に行う方法であり、引用すべき数値です。
  • Read-all:インデックスされたすべてのソースファイルを連結します。誰も負担しない上限値ですが、以前公開した数値との一貫性を保つために掲載しています。
リポジトリファイル数シンボル数Grep-top-3 ベースラインjCodeMunchgrep 比read-all 比
expressjs/express18698915,724 avg967 avg16.3x159.8x
fastapi/fastapi1,18613,69985,296 avg2,097 avg40.7x393.6x
gin-gonic/gin981,82231,975 avg1,484 avg21.5x102.3x
総計(15タスク実行)664,97522,74129.2x248.8x

grepと読み込みを使うエージェントと比べて、96.6%削減、トークン数は29.2分の1です。 すべてのクエリに当てはまる単一の倍率はありません。ばらつきについては、上記のリポジトリ別の行を参照してください。read-allとの比較では99.6%ですが、誰もその上限値を負担することはありません。コンパクトなMUNCHワイヤーエンコーディングを使うと、レスポンスのバイト数をさらに中央値で45.5%削減できます。

測定方法、固定したコミット、ハーネス、既知の注意事項については、benchmarks/METHODOLOGY.md · 自分で再現する · TOKEN_SAVINGS.mdをご覧ください。

本番コードベースでの独立したA/Bテスト

実際のVue 3 + Firebase本番コードベースで、jCodeMunchとネイティブツール(Grep/Glob/Read)を比較する50回の反復A/Bテストを実施しました。Claude Sonnet 4.6を使用し、反復ごとに新しいセッションを開始しました。成功率は80%対72%、タイムアウト率は32%対40%、平均キャッシュ作成時間は10.5%短縮しました。固定オーバーヘッドを除いたツール層の削減率は15-25%です。jCodeMunchのバリエーションでのみ確認できた発見カテゴリが1つありました。ネイティブツールではスクリプトを使わないと回答できない構造的なクエリである、find_importersによる孤立ファイルの検出です。完全なレポート:benchmarks/ab-test-naming-audit-2026-03-18.md

紹介記事

評価・紹介の全一覧 →


インストール

ワンクリックでインストール

VS Code にインストール VS Code Insiders にインストール Cursor にインストール

おすすめ:コマンド1つでインストール
uv tool install jcodemunch-mcp
jcodemunch-mcp init

管理する仮想環境は不要で、システムの Python に書き込むこともありません。また、pip install の実行が拒否される PEP 668 対応ディストリビューション(Ubuntu 24.04 以降、Debian 12 以降)でも、そのまま動作します。まだ uv をお使いでない方はこちら

init は MCP クライアント(Claude Code、Claude Desktop、Cursor、Windsurf、Continue)を自動検出して設定項目を書き込み、エージェントが実際に jCodeMunch を使うよう CLAUDE.md プロンプトポリシーをインストールします。また、任意で強制適用フックをインストールし、プロジェクトにインデックスを作成し、エージェントの設定ファイルを監査してトークンの無駄を確認します。

その他のインストール方法
コマンド使用する場合
uvx jcodemunch-mcpインストール不要。 一時的な環境から実行され、ディスクに恒久的に何も残りません。init が書き込むクライアント設定項目は、すでにこの方法でサーバーを実行するため、ほとんどの環境ではこれだけで済みます。⚠ 強制適用フックは例外です。最小限の PATH を持つサブシェルから起動され、名前で実行ファイルを検索するため、動作には uv tool install(または pipx/pip)が必要です。
pipx install jcodemunch-mcpすでに pipx を標準として使っている場合
pip install jcodemunch-mcp自分で管理する仮想環境内で使う場合

動作を確認します:

jcodemunch-mcp --version
Claude Code の手動セットアップ
claude mcp add -s user jcodemunch -- uvx jcodemunch-mcp

インストール手順はありません。uvx が必要に応じてサーバーを取得して実行します。PATH 上で使えるようにしたい場合(強制適用フックでは必須)は、uv tool install jcodemunch-mcp を実行してから、claude mcp add -s user jcodemunch jcodemunch-mcp を実行してください。

次に、ツールを優先して使うようエージェントに伝えます。これは多くの人が思う以上に重要です。インストールするとツールを利用できるようになりますが、エージェントが力任せにファイルを読む習慣は変わりません。CLAUDE.md に1行追加すれば十分です:

Call the jcodemunch_guide tool and strictly follow its instructions.

Cursor、Windsurf、Codex CLI、Antigravity、Gemini CLI、Qwen Code、Kiro、Cline、Zed、Goose、Hermes、Odysseus、または Paperclip をお使いですか?テスト済みの各クライアント設定はすべて CLIENTS.md にあります。任意の追加機能(ローカルセマンティック検索、プロバイダーごとの AI 要約)については QUICKSTART.md をご覧ください。各追加機能がシステムに取り込む内容は、SECURITY.md に記載されています。


クイックスタート

詳しい手順は QUICKSTART.md をご覧ください。init の実行後、エージェント内でできる2分版の手順:

  1. 次のように尋ねます:「jcodemunch でこのリポジトリにインデックスを作成してください。」
  2. 次のように尋ねます:「jcodemunch を使って、認証を処理する関数を探し、そのソースを表示してください。」

エージェントは search_symbols と get_symbol_source を使って回答し、ファイル全体ではなく数十行を返すはずです。get_session_stats で確認してください。セッション中に提供されたトークン数と節約量が報告されます。メーターの数値はここから算出されています。

人気のフレームワークで初回のインデックス作成を省略したい場合は、事前構築済みの スターターパック を使えます:jcodemunch-mcp install-pack --list(無料のパックにライセンスは不要です)。


できること

  • ファイルを読み込まずに、1つのシンボルを取得できます。 get_symbol_source は、700行のファイルで1つの関数に触れる編集の大半(読み取り量を約95%削減)について、関数本体をバイト単位で正確に返します。
  • 1回の呼び出しでタスク全体のコンテキストを組み立てられます。 assemble_task_context はタスクの意図を分類し、アンカーとなるシンボルを抽出して、1つのトークン予算内で適切なツールのシーケンスを実行します。plan_turn は最初の読み取り前にターンを振り分けます。
  • grep では答えられない構造上の質問ができます。 find_importers、get_blast_radius、get_call_hierarchy、find_dead_code、get_changed_symbols、get_hotspots、search_ast によるアンチパターンの一括検出などがあります。似た名前の2つのツールは、実際には異なります。check_references は名前がどこで使われているか(インポート箇所に加え、内容にその名前が含まれるすべてのファイル)に答え、find_references はインポートグラフだけを対象に、そのシンボルをインポートしているファイルを答えるため、呼び出し箇所は検出されません。
  • リスクの高い変更を事前に確認し、いつ止めるべきかが分かります。 check_edit_safe、check_delete_safe、get_pr_risk_profile、編集にすぐ使える {old_text, new_text} ブロックを含む plan_refactoring を利用できます。2つの安全性チェックが返す stop_rule.terminal が true の場合、それ以上 jcodemunch を呼び出しても判定は変わらないため、確認のために find_importers や check_references を再実行するのは無駄です。これは判定が最終であることを意味し、安全であることを意味するわけではありません。corpus_inadequate(インデックスが不在の主張を裏付けられなかった)と dynamic_import_boundary(動的インポート、または .NET のコントロールやビルド項目の場合にインデックスが保持していないパスによって、ファイルが読み込まれる可能性がある)は、決して最終判定にはならず、各ツールの説明には返されるすべての判定が記載されています。インポートグラフからシンボルのファイルに到達できなかった場合、check_rename_safe は true ではなく safe: null を返します。その場合、そのシンボルを使うファイルは確認されていません。また、影響範囲の軸を測定できなかった場合、get_pr_risk_profile は unmeasurable_axes とともに risk_score: null を返します。CI ゲートでは null を失敗として扱うべきです。型チェッカー自身の出力(jcodemunch-mcp import-trace --diagnostics <file>:mypy --output json、pyright --outputjson、tsc --pretty false、ruff --output-format json)をサーバーに渡すと、check_edit_safe、get_changed_symbols、get_pr_risk_profile、get_symbol_provenance は、チェッカーがすでに警告しているシンボルと、その判定の基準となったコミットを示します。チェッカーの実行は行いません。false の場合は、何が変われば判定が変わるのかが具体的に示されます。
  • 回答を信頼できます。 調整済みの信頼度スコア、鮮度フラグ、不在の主張に対するカバレッジ契約、SCIP インポートによるコンパイラー検証済みの参照、LLM に渡る前の自動的なシークレットの編集が備わっています。
  • インデックスを自動で最新に保てます。 監視モード、エージェントフック、VS Code 拡張機能によって、古くなるタイムラグを解消します。

以上が主な機能です。90以上のツール、MUNCH のコンパクトなワイヤーフォーマット、エビデンスレシート、オフロード可能な作業の注釈、セッションの経済性を計測する機能についての完全なガイドは CAPABILITIES.md に、内部の仕組みは UNDER_THE_HOOD.md に記載されています。

新着情報
  • v1.108.383(2026-10-19)— サマリーを更新しても、複雑度と呼び出しグラフが消去されなくなりました
  • v1.108.382(2026-10-19)— タスクカプセルのリスク項目に、PR の実際のリスクスコアが含まれるようになりました
  • v1.108.381(2026-10-19)— あるリポジトリのインデックスが、別のリポジトリのインデックスを置き換えたり代用したりできなくなりました
  • v1.108.380(2026-10-19)— セッションのコンパクト化が、大規模なインデックスのランドマーク待ちで止まらなくなりました

どのような場合に役立ちますか(また、役立たないのはどのような場合ですか)?

シナリオ標準ツールjCodeMunch削減量
1つの関数を編集する(700行のファイル)Read → 700行get_symbol_source → 30行約95%
ファイルの構造を把握するRead → 全内容get_file_outline → 名前とシグネチャ約80%
編集するファイルを見つける多数のファイルをGrepsearch_symbols → 完全一致同程度
編集にファイル全体のコンテキストが必要Read → 全内容get_file_content → 全内容約0%
「Xを変更すると、何が壊れますか?」不可能get_blast_radius独自の機能

最も効果を発揮するのは、対象を絞った編集(1つの関数、メソッド、クラス)であり、これは実際の編集作業の大半を占めます。ファイルレベルの状態の再構成や、数百行にわたるロジックの並べ替えなど、本当にファイル全体を必要とする編集では利点はありません。特に適しているのは、大規模なリポジトリ、詳しくないコードベースの調査、エージェント主導の探索、リファクタリングと影響分析、そしてエージェントの能力を落とさずにAIのトークンコストを削減したいチームです。

言語: Python、JavaScript/TypeScript、Go、Rust、Java、C/C++、C#、PHP、Ruby、Swift、Kotlinなど、tree-sitter経由で70以上に対応しています。対応状況の一覧はLANGUAGE_SUPPORT.mdをご覧ください。モノレポ: 対応しています。インクリメンタルインデックス作成、ワークスペースメンバーの検出、サブパスのスコープ指定が可能です。


ツールスキーマの遅延読み込み(Anthropicのツール検索)

ツール検索に対応したモデルで、MCP コネクター経由でjCodeMunchを利用する場合、スキーマをコンテキストのプレフィックスに一切含めず、リクエストに必要な2、3個のツールだけをClaudeに読み込ませることができます。ツールごとにdefer_loadingを設定する必要はありません。サーバー全体に一度だけ設定します。

{
  "mcp_servers": [
    { "type": "url", "url": "https://your-host/mcp", "name": "jcodemunch" }
  ],
  "tools": [
    { "type": "tool_search_tool_bm25_20251119", "name": "tool_search_tool_bm25" },
    {
      "type": "mcp_toolset",
      "mcp_server_name": "jcodemunch",
      "default_config": { "defer_loading": true },
      "configs": {
        "resolve_repo":       { "defer_loading": false },
        "search_symbols":     { "defer_loading": false },
        "get_ranked_context": { "defer_loading": false }
      }
    }
  ]
}

ベータヘッダーmcp-client-2025-11-20を付けて送信します。両方の設定が必要です。mcp_serversのみの場合は検証エラーになり、対応するmcp_server_nameのないmcp_toolsetも同様です。

⚠ MCP コネクターではURLを指定するため、これはsseまたはstreamable-httpで提供されるjCodeMunch(jcodemunch-mcp serve --transport streamable-http)に適用されます。デフォルトのローカルstdio構成には適用されません。stdioでは、スキーマを遅延させるかどうかはクライアント次第です。下記のtool_surface: "counter"が、設定可能な方法です。

上記のconfigsブロックは、よく使う3~5個のツールを常に読み込んでおき、一般的なリクエストで検索の往復を省くという、Anthropic自身の推奨に沿っています。また、ツール単位のconfigsはdefault_configを上書きします。

遅延読み込みされる定義はシステムプロンプトのプレフィックスから除外され、Claudeが見つけたときにtool_referenceブロックとしてインラインで追加されるため、プロンプトキャッシュは維持されます。これはキャッシュを無効化するタイプの動的なツール一覧ではありません。リクエスト内の少なくとも1つのツールは遅延読み込みの対象外にする必要があります。そうでない場合、APIは400を返します。

⚠ これは当社独自のtool_surface: "counter"とは異なる仕組みであり、両方を使う必要はありません。ツール検索はホスト側で動作し、接続しているすべてのMCPサーバーに適用されます。Counterはサーバー側で動作し、ツール検索に対応していないホストでも使えます。また、初回インストール時にinitで設定されるのもこちらです。ホストが対応している方を選んでください。CounterについてはCONFIGURATION.mdを、インストール環境で実際に公開されている機能についてはjcodemunch-mcp surfaceをご覧ください。


セキュリティ、プライバシー、バックグラウンドでの動作

ローカルファーストを前提に設計されています。インデックスは ~/.code-index/ に保存され、ベースパッケージのデフォルトのネットワーク動作は、匿名の節約量カウンター(ランダム ID と集計されたトークン数のみ。コード、パス、個人を特定できる情報は含みません。share_savings: false でオプトアウト可能です)だけです。ツール呼び出しへの応答以外にサーバーが行うすべての処理(ファイル監視、オプトインのログインサービス、ライセンス検証、モデルのダウンロード、組織へのレポート)は、オプトインまたはオプトアウト可能で、可視化され、元に戻せます。また、各項目はパストラバーサル、シンボリックリンク、シークレットの編集に関する制御とともに、SECURITY.md に列挙されています。

文法パックのオーバーライド(#608)。 依存関係の tree-sitter-language-pack は <1.0.0 に固定されています。0.x のホイールにはすべての文法が含まれており、解析がローカルで完結するためです。例外は F# のみです。F# は固定された tree-sitter-fsharp ホイールで解析され、このホイールにも文法が組み込まれているため、どちらのパックでも F# の解析はローカルで完結します(#848)。インストール後に pip install -U tree-sitter-language-pack を実行すれば、これをオーバーライドできます。コード側で拒否されることはありません。2026-09-11 に 1.17.0 と比較して確認したうえで、受け入れることになる影響は次のとおりです。1.x パックには文法が含まれておらず、言語の初回解析時に、それぞれの文法をネットワーク経由でキャッシュディレクトリに取得します(Windows で確認したパスは %LOCALAPPDATA%\tree-sitter-language-pack\v<version>\libs です。jcodemunch-mcp install-status を実行すると、どのプラットフォームでもパスが表示されます)。そのため、エアギャップ環境では何も解析されず、nim の文法は上流で変更されたため、nim ファイルからシンボルが検出されません(マニフェストには autohotkey、ejs、verse もありませんが、この 3 つは jCodeMunch 独自の抽出機能で解析され、tree-sitter は使用しないため、ここでは影響ありません)。1.x パックでインストールすると、そのことが示されます。すべての index_folder の結果に grammar_pack ブロックが含まれ、バージョン、キャッシュディレクトリ、文法の取得に失敗した各言語を示す警告が表示されます。jcodemunch-mcp install-status にも同じ情報が表示されます。固定を解除するかどうかは別の判断であり、まずオフラインでの動作を確認する必要があります。


プロジェクトごとの設定

ほとんどの設定はグローバルな ~/.code-index/config.jsonc に保存されますが、リポジトリのルートに .jcodemunch.jsonc を置けば、設定をリポジトリごとにオーバーライドできます。これはオーバーレイです。ここで宣言したキーが優先され、省略したキーはグローバル設定、続いて組み込みのデフォルト値が適用されるため、異なる設定だけを記述すれば済みます。

// <your-repo>/.jcodemunch.jsonc
{
  "max_file_size": 1048576,
  "languages": ["python", "typescript", "racket"]
}
Racket の定義フォームを宣言する

Racket プロジェクトでは、define-syntax を使って独自の定義フォームを定義することがよくあります。静的パーサーには、それらが何を束縛するのか判断できません。たとえば (defstep (check-admin) ...) は関数呼び出しと区別できません。定義フォームを宣言すると、そこでの束縛を検索できるようになります。

{
  "racket_definition_forms": {
    "defstep":  "function",
    "defstudy": "constant",
    "defvar":   "constant",
    "define-schema": "class"
  }
}

各項目では、フォーム名と、それが束縛する対象(function、constant、class、type)を対応付けます。名前がどこにあるかは宣言ではなくソースから読み取られます。たとえば (defstep (check-admin) ...) ではパラメーターリストの先頭が使われ、(defstudy consent ...) では裸のシンボルが使われます。そのため、どちらの形式でも使われるフォームは、どちらの形式でも機能します。

⚠ これはアサーションであり、jCodeMunch が検証できるものではありません。誤った宣言をすると、Racket では実際には束縛されていない名前がインデックスに登録されます。また、宣言はすべての組み込みフォームの後に照合されるため、define や struct を宣言しても効果はありません。組み込みの処理が優先されます。

Racket の #lang の構文を宣言する

#lang 行は リーダー を指定し、jCodeMunch の Racket パーサーは S 式を読み取ります。ディストリビューションに含まれる言語(racket/*、typed/racket*、s-exp、info、at-exp …、およびドキュメント言語の scribble/*、pollen、punct、markdown …)は組み込みですが、プロジェクト独自の言語は認識されず、ドキュメントとして扱われます。つまり、シンボルは抽出されませんが、テキスト検索は可能です。その構文を指定するまでは、この状態です。

{
  "racket_langs": {
    "conscript": "at-exp",
    "mylang": "sexp"
  }
}

sexp はプレーンな S 式です。at-exp は Racket 上の at-exp テキスト本文です(コマンド文字として @ を使用して読み取ります。これは #lang at-exp の読み取りと同じなので、;、"、#、| を含む文章も文章として扱われます)。text は走査されないドキュメント言語です。キーはサブ言語にも適用されます(conscript は conscript/with-require にも一致します)。また、プロジェクトでは言語を昇格させるだけでなく、降格させることもできます。リーダーが別のコマンド文字を使う at-exp 言語は、オブジェクト形式で宣言します。たとえば "mylang": {"tier": "at-exp", "command_char": "◊"} のように指定します。これは、Racket の make-at-readtable で #:command-char を指定する方法と同じです。

どちらのキーを変更しても、変更されていないファイルに対してパーサーが出力する内容が変わるため、その変更はインデックスに記録され、次回のインデックス作成時に全体の再解析が 1 回実行されます(rebuild_reason: "racket_config_changed")。ファイルに手を加えたり、インデックスを消去したりする必要はありません。この記録が導入される前に作成された Racket ファイルを含むインデックスも、同じ方法で 1 回再解析されます(rebuild_reason: "racket_index_predates_gate")。


ドキュメント

ドキュメント内容
QUICKSTART.md3 ステップでゼロからインデックスを作成
CLIENTS.mdすべての MCP クライアント向けのテスト済み構成
USER_GUIDE.mdツールの完全なリファレンス、ワークフロー、ベストプラクティス
CAPABILITIES.mdハイライト以外も網羅した機能の完全なリファレンス
CONFIGURATION.md設定ファイルのリファレンス、トークン制御の設定項目、ツールの階層化、Counter
UNDER_THE_HOOD.md技術マニュアル:判定、ランキングの内部処理、来歴に関する契約
ARCHITECTURE.md内部設計、ストレージモデル、拡張ポイント
GROQ.mdGroq Remote MCP、gcm CLI、speedreview GitHub Action
HEADLESS.mdclaude -p で jCodeMunch を使用する方法
AGENT_HOOKS.mdエージェントフックとプロンプトポリシー
LANGUAGE_SUPPORT.mdサポート対象の言語と解析の詳細
SECURITY.mdセキュリティ制御、データの移動、バックグラウンドでの動作
TROUBLESHOOTING.mdよくある問題と解決方法
CHANGELOG.md · ROADMAP.mdリリース履歴と今後の予定

ライセンスと商用利用

jCodeMunch-MCP は、jCodeMunch-MCP Dual-Use License(ライセンス全文)の下でリリースされています。非商用利用は無料です。商用利用には有料ライセンスが必要で、jMunch LLC が Stripe 経由で一度限りの料金で販売しています。

jCodeMunch のみ: Builder、$79(開発者 1 名) · Studio、$349(最大 5 名) · Platform、$1,999(組織全体での内部デプロイ)

jMunch スイート全体(コード + ドキュメント + データ): Trio Builder、$99 · Trio Studio、$449 · Trio Platform、$2,499

導入する価値があるか分かりませんか?ROI 計算ツールでご自身の数値を試すか、財務チーム向けの説明を承認担当者に転送してください。保証は変わりません。jCodeMunch で元が取れなければ、jCodeMunch の料金はかかりません。

すべての利用に適用される条件:著作権表示を保持し、変更内容を明確に示して、原作者の名前をそのまま残してください(本人はかなり自分を買いかぶっています)。ソースコードを再配布する場合は、目立つ形で変更通知を記載してください。本ソフトウェアの名称変更、ブランド変更、公的なパッケージレジストリへの公開は禁止されています。また、本ソフトウェアは保証なしの「現状有姿」で提供されます。適用される条件は LICENSE をご確認ください。


FAQ

Claude / Opus のトークンをどれくらい節約できますか? 検索主体のワークフローでは、コードを読むためのトークンを通常 86〜99%削減できます。15 個のタスクと 3 つのリポジトリで grep-and-read エージェントと比較したベンチマークでは、平均削減率は 96.6%(29.2 倍)でした。クエリごとの結果は 7.6 倍から 85.7 倍の範囲です。方法論については、TOKEN_SAVINGS.md と benchmarks/ をご覧ください。

RAG や grep ベースのツールとはどう違いますか? jCodeMunch は、あいまいなチャンク(RAG)や生の行一致(grep)ではなく、バイトレベルの精度でシンボル単位(関数、クラス、インポーター、影響範囲、階層)で情報を取得します。これにより、エージェントがその後に内容を読み、推論する手間を減らせます。

個人利用は無料ですか? はい。商用利用にはライセンスが必要です。上記をご覧ください。

X の詳細な解説はどこにありますか? 機能:CAPABILITIES.md。設定:CONFIGURATION.md。クライアント:CLIENTS.md。内部構造:UNDER_THE_HOOD.md。または、すべての情報が集まる jcodemunch.com をご覧ください。


その他:OSS コード健全性オブザーバトリー(Express、FastAPI、Gin、Django などの 6 軸スナップショットを毎週公開) · Token Cost Radar(AI トークンコストの最新情報を毎日公開) · jMunch Console(ワンクリックでアップグレードできる無料の MIT GUI)

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。