Jcodemunch MCP

一键安装：

    

快速入门-https://github.com/jgravelle/jcodemunch-mcp/blob/main/QUICKSTART.md

一堆详细信息：http://jcodemunch.com/

实时OSS代码健康观察站 --每周六轴健康状况快照 Express、FastAPI、Gin、Pydantic、Django、Flask、NestJS、Cobra和 这个repo：https://jgravelle.github.io/jcodemunch-observatory/

免费供个人使用

用它来赚钱，J叔叔就尝到了滋味。公平吗？ 详情

______________________________________________________________________

通过以下方式减少代码读取令牌的使用 95%或以上

大多数AI代理以昂贵的方式探索存储库：

打开整个文件→ 浏览数千条不相关的行→ 重复。

这并不是“有点低效” 那是一个 代币焚烧炉.

jCodeMunch对代码库索引一次，让代理只检索他们需要的确切代码：函数、类、方法、常量、大纲和范围紧密的上下文包，具有字节级精度。

在检索繁重的工作流程中，这通常会通过以下方式减少代码读取令牌的使用 95%+ 因为代理停止了仅仅为了找到一个有用的实现而暴力读取巨型文件。

索引一次。廉价查询。继续走。 精确上下文胜过暴力上下文。

______________________________________________________________________

文档

______________________________________________________________________

紧凑型输出——第二个令牌轴（MUNCH）

检索决定 什么 发送。MUNCH决定 如何打包.

每个工具响应都可以以专门构建的紧凑线格式发出 而不是冗长的JSON。路径前缀被连接到短句柄， 字典的同质列表打包成单个字符标记的CSV行，以及 每列类型被保留，因此解码是无损的。

# any tool call accepts format=
find_references(identifier="get_user", format="auto")
# auto  — emit compact if savings ≥ 15%, otherwise JSON
# compact — always compact
# json    — never compact (back-compat passthrough)

基准（v1.56.0）：中位数 45.5% 在6个代表性文件中保存的字节数 工具，峰值在 55.4% 关于图表和大纲的回应。完整规格 SPEC_MUNCH.md；编号和线束 TOKEN_SAVINGS.md.

在检索节省的基础上编码节省堆栈——每一个字节 是代理不付费读取的字节。

______________________________________________________________________

jCodeMunch MCP

严重人工智能代理的结构化代码检索

有什么新鲜事

• v1.108.11 （2026-05-15）——漂移清理+Windows CI测试强化
• v1.108.10 （2026-05-15）——模式预算清理（v1.108.0/v1.108.6漂移后）
• v1.108.9 （2026-05-14）——逃生舱 _UNDISABLEABLE_TOOLS 安全网（#299）
• v1.108.8 (2026-05-14) — jcodemunch_guide 荣誉 disabled_tools (#298)
• v1.108.7 （2026-05-12）--Windows挂钩路径：正斜杠+路径形状无关的去重

 ](https://pypi.org/project/jcodemunch-mcp/) ](https://pypi.org/project/jcodemunch-mcp/)

______________________________________________________________________

提到由

• 阿图尔 斯科罗斯基 （VirtusLab）-- *“大约减少80%的令牌，或提高5倍的效率——索引一次，查询永远便宜”* ·
• 朱利安·霍尔西 （怪玩意）-- *“3850个代币减少到700个——提高了5.5倍”* · JCodeMunch AI代币储蓄器
• 西翁·威廉姆斯 — *“为实际需要推理而不是检索的任务保留标记”* · 2026年3月AI工作流程更新
• Traci Lim （AWS·东盟人工智能负责人）-- *“本机工具无法回答的结构化查询：find_importers、get_blast_radius、get_ass_hierchy、find_dead_code”* · 5在Claude代码中保存令牌使用的Repos
• 埃里克·格里尔 — *“上下文是稀缺资源。将其减少90%，整个堆栈就会变得更便宜、更可靠”* · jCodemunch:AI代理的上下文引擎

完整识别页面→

______________________________________________________________________

## 商业许可证 jCodeMunch MCP是 免费用于非商业用途. 商业使用需要付费许可证。 jCodeMunch仅许可 - 建筑商----79美元 --1名开发人员 - 工作室----349美元 --最多5名开发人员 - 平台----1999美元 --全组织内部部署 想要同时检索代码和文档吗？ - 蒙克二重奏组合——89美元 - 蒙克二人工作室套餐——399美元 - 蒙克双平台捆绑包——2249美元

别再付钱给你的模特看整个该死的文件了。

jCodeMunch将回购探索转变为 结构化检索.

jCodeMunch让代理通过以下方式导航，而不是强迫代理打开巨大的文件、浏览导入、样板、注释、帮助程序和无关的代码 代码是什么 并检索 只有重要的事.

这意味着：

• 代码读取令牌使用率降低95%以上 在许多检索繁重的工作流程中
• 更少无关的上下文 污染提示符
• 更快的回购探索
• 更精确的代码查找
• 更少重复的文件扫描废话

它使用树形图索引您的代码库一次，将结构化符号元数据和字节偏移存储到原始源代码中，并根据需要检索精确的实现，而不是反复重新读取整个文件。

最近的版本使检索工作流程更加清晰，在实际工程工作中更有用，包括基于BM25的符号搜索、模糊匹配、语义/混合搜索（选择加入、零强制依赖）、查询驱动的令牌预算上下文组装(get_ranked_context)，死码检测(find_dead_code)，未经测试的符号检测(get_untested_symbols)，git diff到符号映射(get_changed_symbols)，建筑中心性排名(get_symbol_importance，PageRank），冷启动方向图(get_repo_map --无查询、令牌预算、仅签名的仓库概述（按PageRank排名）、合并候选检测(find_similar_symbols --融合语义嵌入、结构签名和行为被叫方Jaccard的多信号重复查找器；带有判决层和基于PageRank的规范的union-find集群），交叉回购API合约浮出水面(get_group_contracts --一组索引仓库，对共享符号契约进行排名，每个契约分为defact_api/leaky_internal/dead_contract/version_skew，具有稳定性+破坏性更改历史+运行时命中率），具体实现发现(find_implementations --跨LSP调度/类层次结构/鸭子类型/装饰器处理程序的多源解析，带置信度评分），删除预执行(check_delete_safe --来自导入者的复合判断+引用+死代码+运行时证据+入口点启发式，带有排名拦截器和推荐操作），任务感知的单调用上下文编排(assemble_task_context --自然语言任务中，源归因语境胶囊外；通过可解释的关键字匹配，自动分类为六个意图之一，自动从任务中提取锚点符号，在一个令牌预算下端到端运行意图适当的子工具序列），使用源代码片段进行爆炸半径深度评分，使用令牌预算进行上下文捆绑，AST导出的调用图和调用层次遍历，感知装饰器的搜索和过滤，热点检测（复杂性x流失），依赖循环和耦合度量，会话感知路由(plan_turn、周转预算、负面证据）、代理配置审计、基于复杂性的模型路由（代理选择器）、强制挂钩（PreToolUse/PostToolUse/PreCompact）、依赖图、类层次遍历、多符号包、基于实时观察的重新索引、自动克劳德代码工作树发现(watch-claude)，使用一个命令登录服务安装注册表范围内的自动重新索引(watch-all + watch-install / watch-uninstall / watch-status；也作为MCP工具公开 get_watch_status)，按需自动手表（当 watch: true 在配置中，服务器会自动对调用工具的任何仓库进行索引和监视——确保第一次调用的结果新鲜）、受信任的文件夹访问控制、可编辑的重构计划(plan_refactoring)用于重命名、移动、提取和签名更改操作，符号来源考古(get_symbol_provenance --完整的git谱系、语义提交分类、进化叙事）、统一的PR风险分析(get_pr_risk_profile --融合爆炸半径、复杂性、流失、测试差距和数量的复合风险评分）、自动响应秘密编辑（在到达LLM上下文窗口之前擦除AWS/GCP/Azure/JWT/GitHub令牌）和跨语言AST模式匹配(search_ast --10个预设反模式检测器+用于结构查询的自定义迷你DSL，如 call:*.unwrap, string:/password/i, nesting:5+；可跨所有70多种语言使用通用节点类型映射）。

______________________________________________________________________

真实世界的结果

可复制代币效率基准

用以下方式测量 tiktoken cl100k_base 在三个公共repos上。工作流程： search_symbols （前5名）+ get_symbol_source 每个查询3次。基线：连接所有源文件（读取所有内容的代理的最低成本）。 完整的方法和利用→

每个查询的结果范围从79.7%（密集的FastAPI路由器查询）到99.8%（Express上的稀疏上下文绑定查询）。95%的数字是总和。跑 python benchmarks/harness/run_benchmark.py 为了繁殖。

生产代码库上的A/B测试

在真实的Vue 3+Firebase生产代码库上进行独立的50次迭代A/B测试——JCodeMunch与原生工具（Grep/Glob/Read），Claude Sonnet 4.6，每次迭代都有新的会话：

与固定开销隔离的工具层节省： 15–25%. 一个发现类别仅出现在JCodeMunch变体中：通过以下方式检测孤立文件 find_importers --没有脚本，结构化查询本机工具无法回答。

完整报告： benchmarks/ab-test-naming-audit-2026-03-18.md

______________________________________________________________________

为什么代理商需要这个

大多数特工仍然像被困在机场礼品店的游客一样检查代码库：

• 打开整个文件以查找一个函数
• 重复读取相同的代码
• 使用导入、样板和无关的助手
• 在他们从一开始就不需要的材料上燃烧上下文窗口

jCodeMunch通过给他们一种结构化的方式来解决这个问题：

• 按名称、种类或语言搜索符号——使用模糊匹配和可选的语义/混合搜索
• 在提取源代码之前检查文件和仓库大纲
• 仅检索精确的符号实现
• 获取任务的令牌预算上下文包或排名上下文包
• 当仅靠结构不够时，退回到文本搜索
• 检测死代码，跟踪影响，按中心性排名，并将git差异映射到符号
• 计划下一个转弯 plan_turn --首次读取前的信心引导路由
• 跟踪会话状态，避免重新读取代理已探索的文件

代理不需要越来越大的上下文窗口。

他们需要 更好的目标.

______________________________________________________________________

你得到了什么

符号级检索

在不打开整个文件的情况下查找和获取函数、类、方法、常量等。

更快地理解回购

在询问来源之前，检查存储库结构和文件大纲。

降低代币支出

向模型发送所需的代码，而不是1500行附带损害。

结构查询本机工具无法回答

find_importers 告诉导入文件的内容。 get_blast_radius 告诉如果你改变了一个符号，会有什么中断，包括深度加权风险评分和可选的源代码片段。 get_class_hierarchy 遍历继承链。 get_call_hierarchy 使用AST导出的调用图对调用者和被调用者进行N级深度跟踪，并为接口/trait方法调用提供可选的LSP富集调度解决方案。 find_dead_code 查找从任何入口点都无法访问的符号和文件。 get_untested_symbols 查找没有测试文件可达性证据的函数——导入图分析和测试文件检测的交集。 get_changed_symbols 将git diff映射到添加、修改或删除的确切符号。 get_symbol_importance 在导入图上使用PageRank按架构中心性对代码库进行排名。 get_hotspots 通过将复杂性与git流失相结合来展示风险最高的代码。 get_dependency_cycles 检测循环导入。 get_coupling_metrics 测量模块耦合和不稳定性。 get_tectonic_map 通过融合三个耦合信号（导入、共享引用、git co-churn）来发现逻辑模块拓扑结构，无需任何配置即可揭示隐藏的模块边界、错位的文件和god模块风险。 get_signal_chains 跟踪外部信号（HTTP请求、CLI命令、计划任务、事件）如何通过调用图在代码库中传播-发现模式映射所有入口点到叶路径并报告孤立符号，查找模式告诉特定符号参与的用户面链（例如“validate_email位于POST/api/users和CLI:import-users上”）。这些不是“更快的grep”，而是grep根本无法回答的问题。

代理配置卫生

audit_agent_config 扫描CLAUDE.md、.cursorules、copilot-instructions.md和其他代理配置文件，查找令牌浪费：每个文件的令牌成本、过时的符号引用（与索引交叉引用——捕获重命名或删除的函数）、死文件路径、全局和项目配置之间的冗余、膨胀和范围泄漏。没有其他工具可以告诉你“第15行引用了三周前重命名的函数。”

符号来源和公关风险分析

get_symbol_provenance git考古：给定一个符号，它会跟踪每个接触到它的提交，将每个提交分为语义类别（创建、错误修复、重构、功能、性能、重命名、还原），提取提交意图，并生成一个人类可读的叙述，解释是谁创建了它，为什么以及它是如何演变的。 get_pr_risk_profile 为分支机构或PR生成统一的风险评估——一次调用将爆炸半径、复杂性、流失、测试差距和变更量融合为复合风险评分（0.0-1.0），并给出可操作的建议。所有响应都会自动扫描泄露的凭据（AWS密钥、JWT、GCP服务帐户等），并在到达LLM之前进行编辑。

跨语言AST模式匹配

search_ast 为每种语言jCodeMunch索引带来结构化代码分析——编写一个查询，在所有70多种语言中进行匹配。 预设防图案 无需任何配置即可检测常见问题： empty_catch （默默地吞下错误）， bare_except （捕获所有处理程序）， deeply_nested （5+控制流量水平）， nested_loops （O（n³）+性能风险）， god_function （100+行功能）， eval_exec （注射风险动态执行）， hardcoded_secret （字符串中的凭证模式）， todo_fixme （未完成的工作标记）， magic_number （未解释的数字常数），以及 reassigned_param （重写函数参数）。跑 category='all' 进行全面扫描，或聚焦 security, error_handling, complexity, performance，或 maintenance. 自定义查询 使用迷你DSL： call:*.unwrap （通过glob查找方法调用）， string:/password/i （正则表达式覆盖字符串文字）， comment:/TODO/i （注释中的正则表达式）， nesting:5+, loops:3+, lines:80+ （阈值查询）。每个匹配都归因于其包含复杂性元数据的封闭索引符号，因此您不仅可以看到 *哪里* 问题是，但是 *有多糟糕* 周围的功能已经是。

多轴约束查询

winnow_symbols 将其他工具分别公开的信号（种类、复杂性、装饰器、直接调用引用、文件glob、名称正则表达式、git流失和PageRank重要性）组合成一个and交叉查询。代理停止进行四到五次调用并手动合并结果：“调用的函数 db.Exec，圈数>10，在过去30天内频繁发生，按重要性排序“在一次往返中解决”。支持的轴显示自己的运算符集(eq, in, matches, contains，数字比较）；基于流失的过滤器的窗口是按标准设置的。结果包括每个符号的重要性、复杂性和流失分数，以便代理能够解释 *为什么* 每个幸存者都成功晋级。

更好的工程工作流程

可用于入职、调试、重构、影响分析和探索不熟悉的存储库，而无需强行读取文件。

重构计划器

plan_refactoring 生成用于重命名、移动、提取和 签名更改操作。退货 {old_text, new_text} 与任何编辑器兼容的块 查找和替换，以及导入重写、冲突检测、新文件生成和多文件协调。

校准的检索信号（v1.74.0+遥测倡议）

现在，每个检索结果都附带了三个机器可读的健康信号，因此代理可以停止猜测是否信任响应：

• _meta.confidence --结合前1名/前2名得分差距、前1名实力、身份匹配存在和新鲜度的校准0-1分。让代理人跟进 get_symbol_source 呼叫一个号码。
• _freshness ∈ {fresh, edited_uncommitted, stale_index} 在每个结果条目上，加上 _meta.freshness 总结。来源于SHA指数vs git rev-parse HEAD 以及每个文件的mtime检查。
• 每工具延迟遥测 (p50/p95/max/error_rate)暴露通过 get_session_stats.latency_per_tool 和那个 analyze_perf 工具。可选SQLite水槽(~/.code-index/telemetry.db)用于跨会话分析。

这 tune_weights 该工具读取持久排名分类账并学习每个回购的检索权重（保存到 ~/.code-index/tuning.jsonc). check_embedding_drift 固定一个16字符串的金丝雀来检测无声的提供者模型更改。 benchmarks/replay/ 提供了一个CI友好的检索质量回归门（nDCG/MRR/Recall），每个版本都会运行该门。

本地第一速度

索引存储在本地，以便快速重复访问。

______________________________________________________________________

运作原理

jCodeMunch对本地文件夹或GitHub存储库进行索引，使用树形图解析源代码，提取符号，并将结构化元数据与原始文件内容一起存储在本地索引中。每个符号都包含足够的信息，可以便宜地找到，并在以后精确检索。

这包括元数据，如：

• 签名
• 善良
• 限定名
• 单行摘要
• 原始文件中的字节偏移量

因此，当代理需要一个符号时，jCodeMunch可以直接获取确切的源代码，而不是加载和重新扫描整个文件。

______________________________________________________________________

快速开始

Ubuntu 24.04+/Debian 12+： 系统Python是外部管理的（PEP 668）。 使用 pipx install jcodemunch-mcp 或 uv tool install jcodemunch-mcp 相反 裸露的 pip install.

选项A：一个命令（推荐）

pip install jcodemunch-mcp
jcodemunch-mcp init

init 自动检测您的MCP客户端（Claude Code、Claude Desktop、Cursor、Windsurf、Continue），写入它们的配置条目，安装Claude.md提示策略，以便您的代理实际使用jCodeMunch，可选地安装强制挂钩（PreToolUse read guard+PostToolUse auto-reindex+PreCompact会话快照），可选地为您的项目建立索引，并审核您的代理配置文件是否存在令牌浪费。跑 jcodemunch-mcp init --help 所有旗帜。

更喜欢单行CLAUDE.md？ 从v1.71.0开始，服务器公开了一个 jcodemunch_guide 返回相同策略片段的工具 claude-md --generate 打印-嵌入运行版本。保持单身 CLAUDE.md/AGENT.md和指南中的行始终与安装的一致 服务器： ``markdown Call the jcodemunch_guide tool and strictly follow its instructions. ` 该工具包含力量，因此无法被隐藏 disabled_tools` 或 分层过滤。

对于非交互式CI或脚本：

jcodemunch-mcp init --yes --claude-md global --hooks --index --audit

选项B：手动设置

1.安装

pip install jcodemunch-mcp

想要语义搜索吗？ 安装本地嵌入extra for zero配置 语义搜索-没有API密钥，首次下载后没有互联网： ``bash pip install "jcodemunch-mcp[local-embed]" # bundled ONNX encoder (recommended) jcodemunch-mcp download-model # fetch model (~23 MB, one-time) ` **想要人工智能生成的摘要吗？** 为您的提供商安装额外的： `bash pip install "jcodemunch-mcp[anthropic]" # Claude pip install "jcodemunch-mcp[gemini]" # Gemini pip install "jcodemunch-mcp[openai]" # OpenAI-compatible pip install "jcodemunch-mcp[all]" # all providers + local embeddings ` 如果没有额外的，总结就会回到签名（仍然有效——你 只需获得较短的描述）。跑 jcodemunch-mcp config --check` 验证 您的提供商已安装并正常工作。

2.将其添加到您的MCP客户端

如果您使用的是Claude Code，请选择与步骤1中安装的代码匹配的代码。

Pip安装（最简单，大多数人都会做）：

claude mcp add -s user jcodemunch jcodemunch-mcp

这 -s user flag在用户范围内注册它，因此它在每个 项目。没有它，注册是项目本地的，你会看到它的 下次想念你 cd 其他地方。如果 jcodemunch-mcp 未找到 在PATH上（在Windows上很常见 pip install --user 安装到 AppData\Roaming\Python\PythonXYZ\Scripts\)，使用绝对路径：

# Windows
claude mcp add -s user jcodemunch "C:\Users\YOU\AppData\Roaming\Python\Python312\Scripts\jcodemunch-mcp.exe"
# macOS/Linux — check `which jcodemunch-mcp` first
claude mcp add -s user jcodemunch "$(which jcodemunch-mcp)"

uvx（不需要安装pip，但uv必须在PATH上）：

claude mcp add -s user jcodemunch uvx jcodemunch-mcp

如果 /mcp 报告 failed 无缘无故地跑 claude --mcp-debug 或 检查 %USERPROFILE%\AppData\Roaming\Claude\logs\mcp*.log --the /mcp 摘要隐藏了实际错误。

如果你正在使用 回形针 （多代理编排平台），添加 .mcp.json 到您的工作区根目录：

{
  "mcpServers": {
    "jcodemunch": {
      "type": "stdio",
      "command": "uvx",
      "args": ["jcodemunch-mcp"]
    },
    "jdocmunch": {
      "type": "stdio",
      "command": "uvx",
      "args": ["jdocmunch-mcp"]
    }
  }
}

Paperclip的Claude Code代理自动检测 .mcp.json 在启动时。添加两台服务器，为您的代理提供符号搜索+文档导航，而不会超出代币预算。

3.告诉你的代理人实际使用它

这比人们想象的更重要。

安装jCodeMunch使工具可用。确实如此 不 保证代理将停止其暴力读取文件的坏习惯，除非您指示它更喜欢符号搜索、大纲和有针对性的检索。变更日志特别指出了围绕这一点改进的入职流程，因为这对首次用户来说是一个真正的困惑来源。

这样一个简单的指令会有所帮助：

Use jcodemunch-mcp for code lookup whenever available. Prefer symbol search, outlines, and targeted retrieval over reading full files.

注： jcodemunch-mcp init 自动处理步骤2和3。有关通过代理挂钩和提示策略执行这些规则的全面指南，请参阅 代理商_HOOKS.md.

______________________________________________________________________

入门包

流行框架和库的预构建索引。跳过初始索引步骤——安装一个包并立即开始查询。

# List available packs
jcodemunch-mcp install-pack --list

# Install a free pack
jcodemunch-mcp install-pack fastapi

# Install a licensed pack
jcodemunch-mcp install-pack express --license YOUR-KEY

免费包不需要许可证。许可包需要 jCodeMunch许可证.使用 --force 重新下载已安装的包。

______________________________________________________________________

Groq集成

使用jCodeMunch作为远程MCP工具 Groq's 超快推理——在几秒钟内回答代码库问题，无需本地设置。

from openai import OpenAI

client = OpenAI(api_key="YOUR_GROQ_KEY", base_url="https://api.groq.com/openai/v1")

response = client.responses.create(
    model="llama-3.3-70b-versatile",
    input="What does parse_file do in jgravelle/jcodemunch-mcp?",
    tools=[{
        "type": "mcp",
        "server_label": "jcodemunch",
        "server_url": "https://YOUR_JCODEMUNCH_URL",
        "headers": {"Authorization": "Bearer YOUR_TOKEN"},
        "server_description": "Code intelligence via tree-sitter AST parsing.",
        "require_approval": "never",
    }],
)

Groq在服务器端处理MCP工具发现和执行-一个API调用，不需要编排。

使用Docker+Caddy进行自动TLS的自主机：

DOMAIN=mcp.example.com JCODEMUNCH_HTTP_TOKEN=secret docker compose up -d

看 GROQ.md 完整教程：允许的工具预设、模型推荐、部署选项和验证脚本。

speedreview——人工智能代码审查GitHub行动

在5秒内获得结构化的公关评论：

# .github/workflows/speedreview.yml
- uses: jgravelle/jcodemunch-mcp/speedreview@main
  with:
    groq_api_key: ${{ secrets.GROQ_API_KEY }}

看 speedreview/README.md 用于完整的设置和配置。

gcm——代码库问答CLI

问任何关于代码库的问题。在3秒内得到答案。

pip install jcodemunch-mcp[groq]
export GROQ_API_KEY=gsk_...

# Ask about a GitHub repo (auto-indexes on first use)
gcm "how does authentication work?" --repo pallets/flask

# Ask about the current directory
gcm "where are the API routes defined?"

# Interactive chat mode
gcm --chat --repo facebook/react

# Use the fast 8B model
gcm "what does parse_file do?" --fast

将jCodeMunch的令牌高效检索（BM25+PageRank）与Groq的280+tok/s推理相结合，以获得近乎即时的答案。看 gcm --help 对于所有选项。

gcm--语音--语音到代码库

说一个问题，听听答案。全音频循环：Whisper STT→ 检索→ LLM → 俄耳甫斯TTS。

pip install jcodemunch-mcp[groq-voice]

# Voice conversation with a codebase
gcm --voice --repo pallets/flask

# Press Enter to start recording, Enter again to stop
# Or type a question directly as text fallback

按Enter键通话。将答案限制在约100个单词以内，以实现自然口语表达。需要麦克风。

gcm解释——自动回购解释器

在单个命令中为任何代码库生成带旁白的解释器视频。

pip install jcodemunch-mcp[groq-explain]

# Generate a 60-second narrated explainer
gcm explain --repo pallets/flask -o flask-explainer.mp4

# With verbose timing
gcm explain --repo facebook/react -v

管道：回购结构→ LLM叙事脚本→ 俄耳甫斯TTS→ 枕头滑轨→ FFmpeg MP4。需要PATH上的FFmpeg。

______________________________________________________________________

配置

设置由JSONC配置文件控制(config.jsonc)使用env-var回退以实现向后兼容性。选择默认值，以便新安装无需任何配置即可工作。

快速设置

jcodemunch-mcp config --init       # create ~/.code-index/config.jsonc from template
jcodemunch-mcp config              # show effective configuration
jcodemunch-mcp config --check      # validate config + verify prerequisites

--check 验证您的配置文件格式是否正确，您的AI提供程序包是否已安装，您的索引存储路径是否可写，以及是否存在HTTP传输包。在任何故障时退出非零-对于CI/CD或首次运行脚本很有用。

配置文件位置

项目配置合并了全局配置——最接近工作的获胜。

令牌控制杆（每圈减少模式令牌）

建议用于注重上下文的设置： "tool_profile": "core", "compact_schemas": true 将模式占用空间从约11.5k个令牌减少到约4k个令牌。

查看所有可用密钥的完整模板。跑 jcodemunch-mcp config --init 生成一个。

工具分层

jcodemunchmcp公开了60多种工具。根据要求限制计划，让所有这些计划对小型模型可见会导致原始偏好偏差（许多 search → read → search → read 循环而不是一个 get_context_bundle).服务器通过缩小每个运行模型的公开工具列表来缓解这一问题。

层级（可配置）

三层带有合理的默认值，可在中完全编辑 config.jsonc:

• core （16个工具）：索引、搜索、检索。推荐给俳句/小型本地车型。
• standard （51个工具）：核心+分析/架构/质量。建议用于Sonnet/GPT-4o类。
• full （全部62个工具）：无过滤器。建议用于Opus/o1/前沿型号。

编辑 tool_tier_bundles.core / tool_tier_bundles.standard 在你的 config.jsonc 在每个层中添加或删除工具。

运行时切换（选择加入，零额外请求）

运行时层切换是 默认情况下关闭。要启用它，请在中设置 config.jsonc:

"adaptive_tiering": true

当打开时， plan_turn --已经是打开移动工具--接受可选 model 作为副作用切换会话层的参数，具有 无额外MCP请求:

plan_turn(repo="...", query="...", model="claude-haiku-4-5")

服务器通过以下方式将模型解析为一个层 model_tier_map 在config（模糊匹配：规范化id，然后精确→ glob → 子字符串→ * → full 回退）。随后的 tools/list 调用只返回缩小的集合。

当 adaptive_tiering 是假的， plan_turn(model=...) 和 announce_model(...) 接受他们的论点，但不要切换层次——静态 tool_profile 继续驱动暴露的工具。 set_tool_tier(tier=...) 无论哪种方式，它都会受到尊重，因为这是一个明确的用户调用，而不是自动行为。

disabled_tools 优先

disabled_tools 应用 之后 层过滤。一种在层捆绑包和 disabled_tools 不会被暴露。服务器记录 WARNING 关于启动和 jcodemunch-mcp config --check 打印a WARN: 如果发生这种情况，请行。

架构层实施(architecture.layers)

地点a .jcodemunch.jsonc 在项目根目录下的文件中声明架构必须尊重的层。 get_layer_violations 然后将强制导入只在声明的方向上流动。

// .jcodemunch.jsonc — example for a layered Python project
{
  "architecture": {
    "layers": [
      { "name": "api",      "paths": ["src/routes", "src/controllers"] },
      { "name": "service",  "paths": ["src/services"] },
      { "name": "repo",     "paths": ["src/repositories"] },
      { "name": "db",       "paths": ["src/models", "src/migrations"] }
    ],
    "rules": [
      { "layer": "api",     "may_not_import": ["db"] },
      { "layer": "service", "may_not_import": ["api"] },
      { "layer": "repo",    "may_not_import": ["api", "service"] }
    ]
  }
}

呼叫 get_layer_violations(rules=[...]) 直接内联传递规则——配置文件是可选的，用作回退。当不存在配置时， get_layer_violations 从顶级目录结构推断层。

弃用的环境变量（v2.0将删除）

以下环境变量仍然有效，但已被弃用。配置文件值优先：

AI提供者密钥(ANTHROPIC_API_KEY, GOOGLE_API_KEY, OPENAI_API_BASE, MINIMAX_API_KEY, ZHIPUAI_API_KEY等等）， JCODEMUNCH_SUMMARIZER_PROVIDER，以及 CODE_INDEX_PATH 是 总是 从env变量中读取——它们从不放在配置文件中。

自动检测模式下的AI提供者优先级：Anthropic→ 双子座→ OpenAI兼容(OPENAI_API_BASE) → 最小最大→ GLM-5→ 签名回退。集 JCODEMUNCH_SUMMARIZER_PROVIDER 强迫 anthropic, gemini, openai, minimax, glm，或 none. jcodemunch-mcp config 显示哪个提供程序处于活动状态。

allow_remote_summarizer 仅影响OpenAI兼容的HTTP端点。当 false，jcodemunch只接受本地主机风格的端点，如Ollama或LM Studio 127.0.0.1 并拒绝远程主机，如 api.minimax.io当远程端点被拒绝时，AI摘要会退回到文档字符串或签名，而不是将源代码发送给该提供者。集 allow_remote_summarizer: true 在 config.jsonc 如果你有意使用托管的OpenAI兼容提供商，如MiniMax或GLM-5。

______________________________________________________________________

什么时候有用？

一个常见的问题是：这只在探索过程中有帮助，还是在编辑前提示代理读取文件时也有帮助？

在编辑特定功能时，它最有帮助。 “编辑前读取”约束不需要读取整个文件，它需要读取代码。 get_symbol_source 只给你即将触摸的功能体，没有别的。你阅读这30行，而不是阅读700行来编辑一种方法。

它没有帮助的情况：真正需要理解整个文件的编辑（重构文件级状态，重新排序跨越数百行的逻辑）。对于这些， get_file_content 大致相当于 Read它最有帮助的情况是有针对性的编辑——一个函数、一个方法、一个类——这是实际编辑工作的大部分。

______________________________________________________________________

最适合

• 大型存储库
• 不熟悉的代码库
• 代理驱动的代码探索
• 重构与影响分析
• 团队试图在不让代理变笨的情况下降低AI代币成本
• 厌倦了为美化的文件滚动支付额外费用的开发人员

______________________________________________________________________

新来的？

从开始 QUICKSTART.md 以获得最快的设置路径。

然后索引一个仓库，询问您的代理它索引了什么，并让它按符号检索代码，而不是读取整个文件。这就是储蓄的开始。

适用于

jCodeMunch是一个MCP服务器，它插入 每个使用MCP的主要代理和IDE:

克劳德代码·克劳德桌面·光标·Windsurf·Codex CLI·继续·Cline·Roo Code·Zed·Goose·Hermes Agent·回形针 --以及更多。

测试配置：

Codex CLI config

推荐（预装二进制文件，无 uvx). 食品法典委员会的rmcp运输 对stdout上的第一个JSON-RPC帧要求严格。 uvx的安装 第一次跑步时的喋喋不休会毒害握手，而握手在历史上 表现为数小时的沉默。将软件包安装到 项目venv并将Codex直接指向解析的二进制文件：

python3 -m venv .venv
.venv/bin/pip install -U jcodemunch-mcp
.venv/bin/jcodemunch-mcp --help   # confirm the binary resolves

# ~/.codex/config.toml
[mcp_servers.jcodemunch]
command = "/absolute/path/to/.venv/bin/jcodemunch-mcp"
# (no args required)

如果握手仍未完成，请设置 JCODEMUNCH_HANDSHAKE_TIMEOUT=5 （默认）并查看stderr--v1.82.1+ 当客户端未调用内部的任何处理程序时，发出一行提示 窗户。

备注 codex review --background 以及其他非交互式跑步。 食品法典委员会的MCP征求/批准系统可以悄无声息地进行 *下降* 工具 在非交互模式下调用无法识别的服务器（在中可见 ~/.codex/logs_2.sqlite 作为 ResolveElicitation { decision: Decline } 服务器端没有聊天）。这是食品法典委员会方面的问题，而不是 jcodemunch的一条上游轨道 这里 每台服务器的权利 自动批准键。交互式 codex 跑步不受影响。

遗产 uvx 配置 （仅供参考；致力于培养宽容的客户， 不建议用于食品法典委员会）：

[mcp_servers.jcodemunch]
command = "uvx"
args = ["jcodemunch-mcp"]

Hermes Agent config

# ~/.hermes/config.yaml
mcp_servers:
  jcodemunch:
    command: "uvx"
    args: ["jcodemunch-mcp"]

明星历史