mcp-retrieval-spec

The jMRI (jMunch Retrieval Interface) specification — an open interface standard for token-efficient context retrieval in MCP servers.

Agents that read whole files to answer specific questions waste 99% of their token budget. jMRI is a minimal interface for MCP servers that do retrieval right: index once, search by intent, retrieve exactly what you need.

Four operations. One response envelope. Two compliance levels.

The problem in numbers: A typical FastAPI codebase costs ~42,000 tokens to read naively. jMRI retrieval of the same answer costs ~480 tokens. At $3/1M tokens, that's $0.126 vs. $0.0014 per query. Across millions of queries, the savings are material.

The jMunch tools have saved billions of tokens across user sessions. This spec is the formal definition of what they do.

Agent
  │
  ├─ discover()    → What knowledge sources are available?
  ├─ search(query) → Which symbols/sections are relevant? (IDs + summaries only)
  ├─ retrieve(id)  → Give me the exact source for this ID.
  └─ metadata(id?) → What would naive reading have cost?

Every response includes a _meta block with tokens_saved and total_tokens_saved. Agents can see exactly what they're saving on every call.

→ SPEC.md

The full jMRI v1.0 specification. Apache 2.0. Implement it however you want.

The spec is open. The best implementations are commercial.

Both implement jMRI-Full. Licenses available at https://j.gravelle.us/jCodeMunch/

from sdk.python.mri_client import MRIClient

client = MRIClient()  # connects to local jcodemunch-mcp

# List available repos
sources = client.discover()

# Search
results = client.search("database session dependency", repo="fastapi/fastapi")
for r in results:
    print(r["id"], r["summary"])

# Retrieve
symbol = client.retrieve(results[0]["id"], repo="fastapi/fastapi")
print(symbol["source"])
print(f"Tokens saved: {symbol['_meta']['tokens_saved']:,}")

Add to your ~/.claude.json:

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

See examples/claude-code/ for full setup.

See examples/cursor/.

mcp-retrieval-spec/
├── SPEC.md                    # The jMRI specification (Apache 2.0)
├── CHANGELOG.md               # Spec version history
├── LICENSE                    # Spec: Apache 2.0. Reference impls: commercial.
├── reference/
│   ├── server.py              # Minimal jMRI-compliant server
│   └── config.example.json   # Sample configuration
├── sdk/
│   ├── python/mri_client.py  # Python client helper (Apache 2.0)
│   └── typescript/mri-client.ts
├── examples/
│   ├── claude-code/           # Claude Code integration
│   ├── cursor/                # Cursor integration
│   └── generic-agent/         # Minimal jMRI agent
└── benchmark/                 # munch-benchmark suite

This is the Stripe model: the API spec is open and well-documented; the best implementation is commercial.

→ jmri/conformance/

Any MCP retrieval server claiming jMRI compliance can run the bundled conformance suite to validate against the spec. Two tiers (Core MUST / Full SHOULD), 14 named cases pinned to specific SPEC.md invariants. Markdown or JSON output for CI / dashboards.

pip install jmri-sdk
python -m jmri.conformance --repo owner/repo --server-cmd "your-jmri-server"

Verdict: jMRI-Full compliant / jMRI-Core compliant / NOT compliant — N MUST failure(s). Exit code 0 on Core-compliant runs (with or without Full gaps), 1 otherwise.

Self-reporting only. Maintainers run the suite against their own servers and publish the report. We don't run conformance against competitors — that's adversarial and not the shape we want a standards-bearer to take. Third parties claiming compliance: run, save, link.

If you reference jMRI in research or as the substrate for a benchmark, please cite the spec — not a vendor methodology paper. The canonical citation is the Zenodo deposit:

Gravelle, J. (2026). jMRI: jMunch Retrieval Interface Specification (v1.1.1) [Software]. Zenodo. https://doi.org/10.5281/zenodo.20102349

CITATION.cff in the repo root has the structured form for citation managers.

→ benchmark/

Clone and run in under 5 minutes. Compares Naive, Chunk RAG, and jMRI on FastAPI and Flask. Results are honest: if RAG beats jMRI on a metric, it's reported.

Real numbers on FastAPI (950K naive tokens):

1,979x fewer tokens than naive. Higher precision than RAG.

The spec is intentionally minimal. PRs that extend the core interface require strong justification. PRs that improve examples, fix errors, or add language-specific SDK clients are welcome.

Open an issue before proposing spec changes.