You're Wasting Tokens... That Stops NOW

Most AI agents still explore documentation the expensive way:

open file → skim hundreds of irrelevant paragraphs → open another file → repeat

That burns tokens, floods context windows with noise, and forces models to reason through a lot of text they never needed in the first place.

jDocMunch-MCP lets AI agents navigate documentation by section instead of reading files by brute force.
It indexes a documentation set once, then retrieves exactly the section the agent actually needs, with byte-precise extraction from the original file.

Index once. Query cheaply forever.
Precision context beats brute-force context.

jDocMunch MCP

AI-native documentation navigation for serious agents

Commercial licenses

jDocMunch-MCP is free for non-commercial use.

Commercial use requires a paid license.

jDocMunch-only licenses

• Builder — $29 — 1 developer
• Studio — $99 — up to 5 developers
• Platform — $499 — org-wide internal deployment

Want the full jMunch suite (code + docs + data)?

• Munch Trio Builder Bundle — $99
• Munch Trio Studio Bundle — $449
• Munch Trio Platform Bundle — $2,499

1.x compatibility commitment

Every 1.x license entitles you to every future 1.x release. We will never ship a 1.x version that:

• removes or renames an MCP tool (deprecated tool names keep their aliases),
• drops a Section field from the response shape,
• forces a reindex without auto-migrating your existing index on first load,
• changes the JSON wire format of any tool response in a way that breaks an existing consumer,
• or makes a previously-default behavior raise.

Anything that would require breaking these promises is reserved for a future major version (2.x). The full machine-checked contract is enforced via tests/test_server.py (tool-name and required-field invariants) and the replay-fixture gate that runs on every release.

Stop dumping documentation files into context windows. Start navigating docs structurally.

jDocMunch indexes documentation once by heading hierarchy and section structure, then gives MCP-compatible agents precise access to the explanations they actually need instead of forcing them to brute-read files.

It is built for workflows where token efficiency, context hygiene, and agent reliability matter.

Why this exists

Large context windows do not fix bad retrieval.

Agents waste money and reasoning bandwidth when they:

• open entire documents to find one configuration block
• repeatedly re-read headings, boilerplate, and unrelated sections
• lose important explanations inside oversized context payloads
• consume documentation as flat text instead of structured knowledge

jDocMunch fixes that by changing the unit of access from file to section.

Instead of handing an agent an entire document, it can retrieve exactly:

• an installation section
• a configuration section
• an API explanation
• a troubleshooting section
• a specific subtree of related headings

That makes documentation exploration cheaper, faster, and more stable.

What makes it different

Section-first retrieval

Search and retrieve documentation by section, not just file path or keyword match.

Byte-precise extraction

Full content is pulled on demand from exact byte offsets into the original file.

Stable section IDs

Sections retain durable identities across re-indexing when path, heading text, and heading level remain unchanged.

Local-first architecture

Indexes and raw docs are stored locally. No hosted dependency required.

MCP-native workflow

Works with Claude Desktop, Claude Code, Google Antigravity, and other MCP-compatible clients.

What gets indexed

Every section stores:

• title and heading level
• one-line summary
• extracted tags and references
• SHA-256 content hash for drift detection
• byte offsets into the original file

This allows agents to discover documentation structurally, then request only the specific section they need.

Why agents need this

Traditional doc retrieval methods all break in different ways:

• File scanning loads far too much irrelevant text
• Keyword search finds terms but often loses context
• Chunking breaks authored hierarchy and separates explanations from examples

jDocMunch preserves the structure the human author intended:

• heading hierarchy
• parent/child relationships
• section boundaries
• coherent explanatory units

Agents do not need bigger context windows.
They need better navigation.

How it works

jDocMunch implements jMRI-Full — the open specification for structured retrieval MCP servers. jMRI-Full covers the full stack: discover, search, retrieve, and metadata operations with batch retrieval, hash-based drift detection, byte-offset addressing, and a complete _meta envelope on every call.

1. Discovery GitHub API or local directory walk

2. Security filtering Traversal protection, secret exclusion, binary detection

3. Parsing Format-aware section splitting: heading-based (Markdown/MDX/HTML/RST/AsciiDoc), structure-based (OpenAPI tags, JSON keys, XML elements), or cell-based (Jupyter)

4. Hierarchy wiring Parent/child relationships established

5. Summarization Heading text → AI batch summaries → title fallback

6. Storage JSON index + raw files stored locally under ~/.doc-index/

7. Retrieval O(1) byte-offset seeking via stable section IDs

Stable section IDs

{repo}::{doc_path}::{ancestor-chain/slug}#{level}

The slug is prefixed with the ancestor heading chain, making IDs both readable and stable. A new heading inserted in one branch of a document never renumbers IDs in another branch.

Examples:

• owner/repo::docs/install.md::installation#1
• owner/repo::docs/install.md::installation/prerequisites#3
• owner/repo::README.md::usage/configuration/advanced-configuration#4
• local/myproject::guide.md::configuration#2

IDs remain stable across re-indexing when the file path, heading text, heading level, and parent heading chain do not change.

Installation

Prerequisites

• Python 3.10+
• pip

Install

pip install jdocmunch-mcp

Verify:

jdocmunch-mcp --help

Configure an MCP client

PATH note: MCP clients often run with a restricted environment where jdocmunch-mcp may not be found even if it works in your shell. Using uvx is the recommended approach because it resolves the package on demand without relying on your system PATH. If you prefer pip install, use the absolute path to the executable instead.

Common executable paths

• Linux: /home/<username>/.local/bin/jdocmunch-mcp
• macOS: /Users/<username>/.local/bin/jdocmunch-mcp
• Windows: C:\\Users\\<username>\\AppData\\Roaming\\Python\\Python3xx\\Scripts\\jdocmunch-mcp.exe

Claude Desktop / Claude Code

Config file location:

Minimal config

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

With optional AI summaries and GitHub auth

{
  "mcpServers": {
    "jdocmunch": {
      "command": "uvx",
      "args": ["jdocmunch-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_...",
        "ANTHROPIC_API_KEY": "sk-ant-..."
      }
    }
  }
}

For Anthropic or Gemini, the base uvx jdocmunch-mcp command is enough once the corresponding API key is present. For OpenAI-compatible providers such as OpenAI, MiniMax, or GLM-5, include the optional dependency in the launcher command:

{
  "mcpServers": {
    "jdocmunch": {
      "command": "uvx",
      "args": ["--with", "openai", "jdocmunch-mcp"],
      "env": {
        "MINIMAX_API_KEY": "mx-...",
        "JDOCMUNCH_SUMMARIZER_PROVIDER": "minimax"
      }
    }
  }
}

After saving the config, restart Claude Desktop / Claude Code.

Claude Code hooks (recommended)

jDocMunch ships enforcement hooks that keep your agent honest:

• PreToolUse — warns when Claude tries to Read a large doc file, suggesting search_sections + `get_sec