jDocmunch MCP

jDocMunch MCP

jDocMunch 是一款面向编码 Agent 的 MCP 服务，可检索任务所需的精确文档章节，而无需将整个文件加载到上下文窗口中。

只需按标题层级为文档集建立一次索引，即可获取单个章节、标题子树或排序后的搜索结果——内容直接从原始文件中按字节精确提取。

安装 · 快速入门 · 基准测试 · 商业许可

个人使用免费。 商业用途需要付费许可——条款见下文。

---

为什么选择 jDocMunch？

问题。 当 Agent 被问到“如何配置身份验证？”时，它会打开一个文档文件，浏览数百段不需要的内容，再打开另一个文件，重复这一过程。更大的上下文窗口并不能解决这个问题。它只是让这种浪费变得足够便宜，暂时可以忽略，直到账单到来；同时还挤占了模型真正需要的上下文。

机制。 jDocMunch 将文档集解析为按标题层级组织的章节树，并为每个章节保存其在原始文件中的字节偏移量，然后通过 MCP 提供检索功能。只要路径、标题文本和标题级别不变，章节在重新建立索引后就会保留稳定的身份标识。

结果。 访问单位从文件变成了章节。Agent 可以检索安装章节、某个配置块或特定标题子树——除此之外不获取任何内容。

---

它有何不同

以章节为先的检索

按章节搜索和检索文档，而不仅仅是按文件路径或关键词匹配。

按字节精确提取

按需从原始文件中的精确字节偏移量提取完整内容。

稳定的章节 ID

只要路径、标题文本和标题级别保持不变，章节在重新建立索引后就会保留稳定的身份标识。

---

证据

针对公开文档语料库的四项基准测试，每项都在 benchmarks/ 中记录了语料库、日期和逐查询结果。

语料库	规模	索引耗时	结果
Kubernetes (kubernetes/website，2026-03-04)	1,569 个 .md 文件、4,355 个章节、16 MB	3,352 ms	单次节点亲和性查询节省 27,285 个 token；延迟为 100 ms
SciPy	10,402 个章节、语料库约 855,000 个 token	2,247 ms	稀疏求解器、FFT 和优化相关查询的耗时为每次 135–152 ms
LangChain（MDX）	5,973 个章节	5,204 ms	感知 MDX 的分节方式比朴素处理多找到 754% 的章节
Wiki	7,449 个 token 的语料库	—	搜索返回按排名排列的元数据，约占 190 个 token；读取整个语料库则需 7,449 个 token

**这些结果应按各个语料库分别看待，而非视为一个统一的倍数。**节省量取决于所在文件相对于所需章节的大小：只有一个标题的小文件几乎省不了什么，而 Kubernetes 语料库则能节省很多。基准测试文件也记录了效果不佳的查询，以及效果良好的查询。

另一项单独测得的结果来自 v1.121.0 的投影改进，测试对象是本仓库自身的文档，设置为 max_results=10：开启 compact=true 后，搜索结果行从 1,989 个字符降至 319 个（减少 84%）；设置 snippet_bytes=200 后则为 431 个字符（减少 78%），同时完全省去了后续的 get_section 调用。

**检索质量由门槛保障，而非想当然。**每个版本都会针对冻结的黄金集运行回放测试，低于 nDCG 0.95 就会失败。该门槛曾导致构建失败并阻止版本发布；它不是摆设。

---

安装

**要求：**Python 3.10+，以及任意兼容 MCP 的客户端。

uv tool install jdocmunch-mcp
jdocmunch-mcp init

无需管理虚拟环境，不会向系统 Python 写入任何内容，并且可在 PEP 668 发行版（Ubuntu 24.04+、Debian 12+）上直接运行；这些发行版会拒绝裸用 pip install。还没有 uv？

init 会检测你的 MCP 客户端、写入相应配置项、安装文档探索提示词策略，让你的 Agent 真正使用这些工具，并可选择安装钩子和为文档建立索引。

其他安装方式

命令	适用场景
uvx jdocmunch-mcp	**零安装。**在临时环境中运行，不会将任何内容永久写入磁盘。init 写入的客户端配置项已通过这种方式调用服务，因此大多数情况下只需运行这一命令。⚠ 钩子是个例外：它们由最小 PATH 的子 shell 启动，并通过名称解析可执行文件，因此需要通过 uv tool install（或 pipx/pip）安装才能运行。
pipx install jdocmunch-mcp	你已将 pipx 作为标准工具
pip install jdocmunch-mcp	在由你自行管理的虚拟环境中

验证：

jdocmunch-mcp --version

手动设置 Claude Code：

claude mcp add -s user jdocmunch -- uvx jdocmunch-mcp

无需安装步骤 — uvx 会按需获取并运行服务。希望将它放到 PATH 中（钩子也必须这样做）？运行 uv tool install jdocmunch-mcp，然后运行 claude mcp add -s user jdocmunch jdocmunch-mcp。

安装服务会让你能够使用这些工具，但不会改变 Agent 直接读取文件的习惯。只需在 CLAUDE.md 中添加一行：

Call the jdocmunch_guide tool and strictly follow its instructions.

---

快速开始

**前提：**已安装 jDocMunch 并在客户端中注册，且有一个文档文件夹。

为本地文档文件夹建立索引：

jdocmunch-mcp index-local --path ./docs

它会输出 JSON，显示语料库名称和发现的内容：

{
  "success": true,
  "repo": "local/docs",
  "file_count": 1,
  "section_count": 4,
  "doc_types": { ".md": 1 },
  "semantic_search": false
}

section_count 大于 file_count 正是关键所在：索引针对的是标题，而不是文件。

然后，在 Agent 中：

使用 jdocmunch 搜索文档中的“身份验证配置”，并向我展示该部分。

Agent 应调用 search_sections，然后对排名最高的结果调用 get_section——返回一个部分，而不是整个文件。get_section 响应中的 _meta.tokens_saved 是估算出的节省量：所含文档的大小减去所提供部分的大小（_meta.savings_basis: "modeled"）。search_sections 本身不计入节省量。

**下一步：**调用 get_toc_tree 查看整个语料库的结构，或调用 index_repo 直接为 GitHub 仓库中的文档建立索引。

超大型文件夹

MCP 客户端会在固定时间后停止等待工具调用。为包含数万份文件的文件夹建立索引，可能耗时超过该时限。在一台 Windows 机器上，为 10,000 个文件（271,585 个部分）建立完整索引，在未使用嵌入的情况下耗时 67 s；使用 sentence-transformers 嵌入则额外耗时约 3 分钟。

如果文件夹如此庞大，或 index_local 调用超时，请从 shell 为其建立索引：

jdocmunch-mcp index-local --path /path/to/folder

CLI 会以相同方式建立索引，且不受工具超时限制。它会写入与 MCP 服务相同的存储，因此命令完成后，服务就会使用该索引。如果在客户端的 MCP 配置中设置了 DOC_INDEX_PATH，也要在 shell 中设置该变量。

• **自定义名称。**如果文件夹使用自定义名称建立了索引，请传入相同的 --name。否则，CLI 会使用文件夹名称，并写入第二个索引。
• **文件数量上限。**文件夹最多处理 10,000 个文件，按最新文件优先。使用 --max-files N 提高上限（对应 MCP 工具中的 max_files）。达到上限时，调用发出的警告会显示包含文件夹发现数量的命令。
• **缩小文件夹范围。**使用 --extra-ignore-pattern 排除不需要的内容（可重复使用，对应 CLI 中的 extra_ignore_patterns），或使用 --paths-from FILE 仅为列出的文件建立索引（对应 CLI 中的 paths）。
• 嵌入。--no-embeddings 会先建立词法索引。之后再次运行命令并加上 --rebuild，即可添加嵌入。

扫描版 PDF

扫描版 PDF 是文字的图片，没有可供索引的文本层。可选的 [ocr] 扩展会使用已安装在你机器上的 OCR 引擎读取这些 PDF。jDocMunch 绝不会安装或下载引擎、语言包或模型。

pip install "jdocmunch-mcp[ocr]"

引擎。 jDocMunch 按以下顺序查找引擎，并使用第一个响应的引擎：

1. 你设置的 JDOCMUNCH_TESSERACT_PATH。
2. PATH 中的 tesseract。
3. Tesseract 的默认安装目录：C:\Program Files\Tesseract-OCR、%LOCALAPPDATA%\Programs 下的每用户目录、/opt/homebrew/bin、/usr/local/bin 和 /usr/bin。
4. 在 Windows 上，如果已安装英语 OCR 语言（英语版 Windows 默认已安装），则使用内置的 Windows OCR。

JDOCMUNCH_OCR_ENGINE=tesseract 或 windows 可指定引擎。JDOCMUNCH_OCR_LANG 用于传递已安装的 Tesseract 语言（默认为 eng）。

OCR 需要两个条件。 只有两者都满足时才会运行：

• 你在 MCP 客户端的 env 块中设置 JDOCMUNCH_OCR=1（使用命令行时，也可以在 shell 中设置）。
• 调用中提出请求：index_local(ocr=true)，或在命令行中使用 index-local --ocr。

因此，Agent 无法自行启用 OCR。此选项会与索引一同保存，之后的刷新和监视程序都会沿用该设置；ocr=false 或 --no-ocr 则会将其关闭。每个请求了 OCR 的响应都会包含一个 ocr 块，说明 OCR 是否在配置中启用、是否实际使用、读取了多少内容以及使用了哪个引擎。

处理结果。 每张扫描图片都会变成一个 ## Page N 小节。OCR 生成的每个小节都会标记 text_source: "ocr"，并包含 ocr_engine、ocr_pages，以及（仅限 Tesseract）ocr_confidence。文档开头会显示一条说明，指出文本来自 OCR，响应中也会对此发出提示。PDF 中任何自带文本层的部分都会保留。OCR 小节不计入 token 节省量。

识别效果。 在对 6 份真实的公有领域印刷文字扫描件（《大英百科全书》1911 年版和《美国印刷工》）进行的测试中，Tesseract 5.4 找出了 97.4% 的单词，字符错误率为 2.0%；Windows OCR 找出了 97.1%，字符错误率为 2.0%。其局限包括：

• 表格和表单的内容可能会错乱。 大部分文字都能识别，因此搜索可以找到它们，但列和字段的布局会丢失。在两份扫描表单中，Tesseract 找出的单词占比为 25% 到 80%。
• 无法识别装饰字体和黑体（哥特体）。 两种引擎都无法读取。
• 无法识别手写内容。

速度。 在此测试中，Tesseract 每张图片耗时 3.4 秒（Windows OCR 耗时 0.3 秒）：处理一份包含 20 张图片的扫描件，Tesseract 耗时 69 秒，Windows OCR 耗时 6 秒。MCP 调用为 OCR 设置了 60 秒的时间预算（ocr_budget_seconds），因此使用 Tesseract 时，包含 20 张或更多图片的扫描件可能无法在一次调用中处理完。 这些内容会被跳过，并标记为 ocr_budget_exhausted。已读取的内容会被缓存，下次调用时会继续处理。对于包含多份扫描件的文件夹，请运行没有时间预算的命令行工具：

JDOCMUNCH_OCR=1 jdocmunch-mcp index-local --path /path/to/scans --ocr

每份文档最多读取前 50 张扫描图片（ocr_max_pages、--ocr-max-pages）；其余图片会标记为 ocr_pages_capped。

隐私。 OCR 在你的机器上运行。Tesseract 是本地程序，Windows OCR 是设备端 Windows API；页面不会离开你的机器。但 OCR 会将扫描件转换为可搜索的文本。如果你对税务表格、工资单、身份证件或医疗记录进行 OCR，其内容（姓名、SSN、账号）将对任何能够查询此索引的 Agent 可见，并保存在磁盘上的索引文本缓存中。jDocMunch 的机密文件规则会匹配文件名，而不是文件内容，因此无法识别扫描版 W-2。请勿将此类文件放入索引文件夹，或使用 extra_ignore_patterns 将其排除。

---

可以做什么

• 检索单个章节，而不是整份文档。 get_section 和 get_sections 从原始文件中提取字节级精确的内容；get_section_excerpt 还能进一步缩小范围。
• 按含义搜索，而不只是按关键词搜索。 配置嵌入提供方后，search_sections 会融合 BM25 与语义余弦相似度。compact=true、fields=[...] 和 snippet_bytes=N 可进一步缩短响应。
• 浏览结构。 get_toc、get_toc_tree、get_section_path、get_section_descendants 和 section_neighbors 可遍历标题树，而无需读取内容。
• 查找缺失或过时的文档。 get_doc_coverage、get_undocumented_symbols、get_stale_pages、get_orphan_sections、get_broken_links 和 doc_health_radar。
• 处理多个 API 规范。 find_endpoint、list_endpoints_by_tag、find_operations_using_schema 和 get_schema_graph 将 OpenAPI 文档视为一等对象。
• 预检文档变更。 删除或重组前，使用 check_section_delete_safe 和 get_section_blast_radius。
• 了解答案何时已过时。 读取内容时会披露 _meta.freshness、_meta.verdict，以及提供答案的源层。

总计 64 个工具。完整参考请见 USER_GUIDE.md。

---

工作原理

所有操作都在本地运行。索引存放在你的主目录下；索引或检索均无需托管服务。

docs/ ──► parser (per format) ──► section tree ──► local index
                                                      │
                          MCP client ◄── retrieval ◄──┘

• 解析按格式分别处理，每种格式由一个模块负责：Markdown/MDX、reStructuredText、AsciiDoc、Jupyter 笔记本、HTML、纯文本、OpenAPI（YAML）、JSON/JSONC、XML/SVG/XHTML、Godot 场景，以及通过可选的 [office] 附加组件支持的 PDF、DOCX、PPTX 和 EPUB。
• 存储使用带版本号的本地索引（INDEX_VERSION = 3），首次加载时会自动迁移。1.x 版本不会强制重新索引。
• 检索默认使用词法 BM25；有可用的嵌入时则使用混合检索。
• 嵌入为可选项，且不依赖特定提供方——可以使用 Gemini、OpenAI、兼容 OpenAI 的端点，或通过 FastEmbed（ONNX）或 sentence-transformers（torch）运行本地离线模型。不配置提供方时，搜索仅使用词法检索，且完全离线。

更多详情请见：ARCHITECTURE.md 和 SPEC.md。

长时间运行的进程中的内存占用

解析后的索引占用的内存约为其文件大小的 2.5 到 3 倍（根据 5 个真实索引测得，大小为 0.5 MB 到 112 MB）。以下两项设置可限制长时间运行的进程的资源占用：

• JDOCMUNCH_INDEX_CACHE_MAX_BYTES 限制服务在调用间保留的已解析索引。默认值为 512 MiB，按每个索引文件大小的 3 倍估算。超过限制后，最近最少使用的索引会被丢弃，并在下次需要时重新读取。超过限制的单个索引仍会保留。设为 0 或更小值会关闭字节数限制；8 个索引的数量上限始终生效。
• JDOCMUNCH_WATCH_INPROCESS=1 使监视器在自身进程中重新索引，而不是每批次启动一个子进程（见下文）。

---

安全与隐私

本产品以本地优先为设计原则。你的文档会在自己的机器上解析和存储；基础软件包默认唯一的联网行为是匿名的节省量统计——仅发送随机 ID 和汇总令牌数，不包含内容、路径或个人身份信息（PII）。

完全选择退出：

JDOCMUNCH_SHARE_SAVINGS=0

只有在你启用嵌入和摘要提供方时，才会调用其配置的 API；默认情况下绝不会调用。只有在你亲自运行 watch-install 时，它才会注册登录服务。

完整披露的后台行为

本地嵌入提供方首次运行时会下载模型。 两种 离线提供方都会在首次使用时从 HuggingFace 获取模型，并将其 缓存到磁盘。只有启用嵌入后才会下载内容；仅使用词法检索的安装 不会联系模型仓库。若模型尚未缓存，则会跳过启动预热， 因此首次运行时会将下载推迟到首次搜索，而不会因此阻塞 MCP 握手 （#110）。 只有在你同意 init 后，才会安装软件包和下载模型。 jdocmunch-mcp init 会检查是否有可用的嵌入提供程序。如果没有，它会询问一次是否启用语义搜索。**默认答案是否。**如果回答是，它会先打印以下两项操作，然后再执行：

• 在 jdocmunch 运行所在的 Python 环境中执行 python -m pip install "fastembed>=0.8.0"（安装后约占用 160 MB；会安装 onnxruntime，而不是 torch）；
• 从 huggingface.co 下载一个模型文件，即 ONNX 格式的 all-MiniLM-L6-v2（87 MB，仅下载一次）。

此后，嵌入操作会在你的计算机上运行。文档中的任何文本都不会发送到其他地方。--yes 不会代你回答这个问题：它只接受配置修改，不会同意下载。脚本化安装可通过 --with-embeddings 选择启用。--dry-run 会打印命令和大小，且不会进行任何操作。如果 pip 不可用（uv tool 或 pipx 安装没有 pip），或者安装失败，init 会根据你的安装方式打印手动执行的命令，并继续使用词语匹配。MCP 服务本身绝不会在未经询问的情况下安装或下载任何内容。

init 为什么要询问：在一个包含 492 个真实用户问题、涵盖 6 个文档集的公开基准测试中，语义（混合）搜索在 47% 的问题中将直接答案排在前 5 条结果内，而仅用词语匹配时这一比例为 34%。方法、数据和与之相伴的负面结果见： jdoc-rerank-bench。在一台仅使用 CPU 的计算机上测得，嵌入处理使首次建立索引每 1,000 个分区约增加 7 秒。doc_list_repos 会报告每个索引的 has_embeddings，因此你可以查看哪些索引仍只使用词语匹配。

将 FastEmbed 用作离线提供程序。pip install jdocmunch-mcp[fastembed] 会通过 onnxruntime 而非 torch 运行同一个 all-MiniLM-L6-v2 模型，因此安装体积小得多。如果同时安装了两个离线提供程序，优先使用 FastEmbed；JDOCMUNCH_EMBEDDING_PROVIDER=sentence-transformers 可选择另一个提供程序。对于同一个模型，这两个提供程序会写入相同的向量存储，因此切换运行时不会重新嵌入语料库。使用 JDOCMUNCH_FASTEMBED_MODEL 指定其他模型时，它会改为保存自己的向量，因为不同模型生成的向量不可互换（#126）。

**FastEmbed 模型的存放位置及修复方法。**FastEmbed 默认使用 <temp dir>/fastembed_cache 文件夹，操作系统清理时可能会清空它。模型无法加载时，index_local 会在 embedding_provider_error 字段和警告中说明这一点；修复前，搜索会使用词语匹配。init 只检查本地文件中的模型，不会下载。如果模型缺失或损坏，它会提供修复选项；修复需要与安装相同的许可：在提示时回答是，或使用 --with-embeddings。修复会将模型（87 MB，仅下载一次）下载到临时目录之外的 ~/.cache/jdocmunch-mcp/fastembed。模型存放在该文件夹后，服务会从那里加载；如果安装时临时目录中的模型副本可用，则会继续使用该副本，且绝不会重新下载。JDOCMUNCH_FASTEMBED_CACHE 可指定其他文件夹；FastEmbed 自带的 FASTEMBED_CACHE_PATH 优先级仍高于这两个设置。

**只有启用 OCR 后，才会使用本地 OCR 程序。**安装 [ocr] 扩展，并在配置中设置 JDOCMUNCH_OCR=1，同时在调用时设置 ocr=true（或使用 --ocr）后，jDocMunch 会针对每个扫描页面启动一个短时运行的 Tesseract 子进程，或者调用 Windows 的设备端 OCR。两者都不会建立网络连接。文本会缓存在你的文档索引目录下（.office_cache/ocr）。没有任何内容会在后台运行，也不会安装任何东西。关于 OCR 识别文本会暴露哪些信息，请参阅扫描版 PDF。 每批监视任务使用一个子进程。 监视器（jdocmunch-mcp watch，或 jdocmunch-watch 登录服务）会在一个短生命周期子进程中重新索引每批发生变化的文件，该进程运行 python -m jdocmunch_mcp.watch_batch。重新索引会重写整个索引文件，而长期运行的进程不会将这部分占用的内存归还给系统，因此监视器的内存使用量会逐渐升高，接近上限 （#189）。子进程退出时会释放这部分内存。它：

• 每批运行一次，批次处理完成后退出；
• 不会自行打开网络连接；它只调用索引过程本就会调用的内容，例如你设置的嵌入或摘要提供方；
• 每次都会重新启动其嵌入提供方。在一台 Windows PC 上，一个文件的批次在进程内耗时 0.3 s，在子进程中耗时 0.55 s，使用 FastEmbed 的子进程耗时 1.7 s（每次都会加载模型）。未测量 sentence-transformers，其加载速度更慢；
• 在 Windows 上不会打开控制台窗口。

设置 JDOCMUNCH_WATCH_INPROCESS=1 可恢复之前的进程内重新索引方式。

使用本地嵌入时，会启动一个子进程。 启用 sentence-transformers 提供方时，jDocMunch 会在一个子进程中运行嵌入模型（python -m jdocmunch_mcp.embeddings.worker），而不是在服务进程内运行。它：

• 首次需要生成嵌入时启动——如果模型已在本地 HuggingFace 缓存中，则在启动时启动；否则在首次使用该模型进行搜索或索引时启动。仅使用词法检索的安装不会启动它；
• 不会打开网络连接，只通过专用管道与父进程通信；
• 在服务退出时退出；如果停止响应，则会被终止；
• 不是登录服务，不会在任何地方注册，也不会持久运行。

之所以采用这种方式，是因为在服务进程内导入嵌入组件可能会在 Windows 加载器中死锁 （#118），导致服务运行期间所有工具调用都陷入挂起。设置 JDOCMUNCH_EMBED_WORKER=0 可禁用此功能，并恢复之前的进程内导入方式。

只有在你安装后才会有登录服务。 jdocmunch-mcp watch-install 会注册文档监视器，使其在登录时启动（systemd 用户单元、launchd Agent，或名为 jdocmunch-watch 的任务计划程序任务）。不会有任何程序替你安装。安装后，它会：

• 在磁盘上的文档文件发生变化时，重新索引每个已在本地建立索引的文档仓库；
• 严格按你传给 watch-install 的标志运行 jdocmunch-mcp watch——使用 --no-ai-summaries 可让摘要生成器不参与其中，使用 --quiet 可抑制其逐项变更日志；
• 将日志写入文档索引目录下的 watch.log 和 watch.err；
• 通过 jdocmunch-mcp watch-uninstall 移除。

⚠ 重新运行 watch-install 会重写服务定义，因此手动编辑过的定义会被替换。现在它会打印被替换的内容；请将标志传给 watch-install 本身，以便升级时保留这些标志 （#120）。

路径遍历防护、符号链接逃逸防护、机密排除、文件大小限制、二进制文件检测和编码安全均记录在 SECURITY.md 中，其中还介绍了如何报告漏洞。

---

局限性

• 对较小文件，分节检索的帮助最小。 如果文档只有一个标题和 40 行内容，检索该节与直接读取文件所花的时间相差无几。
• 语义搜索需要嵌入提供方。 如果没有嵌入提供方，搜索就只能基于词面匹配——适合查找标识符和精确措辞，但对释义性问题的效果较弱。
• Office 格式需要可选的 [office] 扩展，且仅支持本地索引。扫描版（仅含图像）的 PDF 没有文本层，因此未启用 OCR 时不会被索引。响应会在 skipped_paths.no_extractable_text 下列出该文件，添加警告，并报告 coverage_complete: false。
• OCR 是可选的，默认关闭，效果也有限。 安装 [ocr] 扩展、机器上已有 OCR 引擎并设置好两个密钥后，系统即可读取扫描页面（参见扫描版 PDF）。印刷体正文识别效果良好。表格和表单的识别结果可能杂乱，装饰字体、黑体字和手写文字则无法识别。
• 会披露内容是否最新，但不作保证。 如果无法检查某个分节的来源，会将其报告为 unknown，而不是假定它是最新的。
• jDocMunch 不解析代码。 符号、签名和调用图属于 jcodemunch-mcp；表格数据属于 jdatamunch-mcp。

---

文档

文档	内容
USER_GUIDE.md	完整工具参考、工作流和最佳实践
ARCHITECTURE.md	存储模型、解析流程和扩展点
SPEC.md	响应契约和原因代码词汇表
SECURITY.md	安全控制和漏洞报告
TOKEN_SAVINGS.md	节省量的统计和报告方式
CONTRIBUTING.md	开发环境搭建和 CLA 要求
CHANGELOG.md · ROADMAP.md	发布历史和后续计划

---

许可与商业使用

本项目依据 jDocMunch-MCP 双用途许可发布（完整条款）。非商业用途免费。商业用途需要购买付费许可，由 jMunch LLC 一次性销售。

仅限 jDocMunch： Builder，$29（1 名开发者） · Studio，$99（最多 5 名） · Platform，$499（组织范围内的内部部署）

完整 jMunch 套件（代码 + 文档 + 数据）： Trio Builder，$99 · Trio Studio，$449 · Trio Platform，$2,499

个人开发者和非商业项目无需许可。在内部团队中部署 jDocMunch 的组织则需要许可。

1.x 兼容性承诺

每份 1.x 许可都包含所有未来的 1.x 版本。我们绝不会发布违反以下承诺的 1.x 版本：

• 移除或重命名 MCP 工具（已弃用的工具名称会保留其别名），
• 从响应结构中删除 Section 字段，
• 在首次加载时未自动迁移现有索引就强制重新索引，
• 更改任何工具响应的 JSON 线格式，以致破坏现有使用方，
• 或使此前默认启用的行为引发错误。

任何需要打破这些承诺的变更都会留待未来的主版本（2.x）。完整的机器校验契约通过 tests/test_server.py（工具名称和必需字段不变量）以及每次发布都会运行的重放测试样例门禁来强制执行。

---

支持和项目状态

积极维护中。问题和 Bug 报告：GitHub Issues。安全问题报告：请参阅 SECURITY.md。商业许可相关问题请通过 jcodemunch.com 联系。

这是 jMunch 套件的一部分，与 jcodemunch-mcp（代码符号）和 jdatamunch-mcp（表格数据）并列。三者都实现了 jMRI，即开放的检索接口规范。