Skip to main content
Glama
deenesjakoruzh
roomi-fields

RTFM

by roomi-fields
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

RTFM

Retrieve The Forgotten Memory

The open retrieval layer your AI agent was missing

Index everything in your project — code, docs, PDFs, legal texts, research, data — and your agent finds the right context instantly. No hallucinations. No cloud. No API costs.

Free · Local · Open Source · MIT

RTFM vs vanilla Claude Code — same task, same model, who pays the bill?

PyPI version License: MIT Python MCP Claude Code GitHub stars

The problem

Your AI agent is flying blind.

It greps through thousands of files, misses the doc that answers the question, invents modules that don't exist, forgets what you decided last session. The bigger the project, the worse it gets. You've added a smarter model. It didn't help. Because the bottleneck isn't intelligence — it's retrieval.

Code indexers (Augment, Sourcegraph, Cursor) only see code. But your project isn't just code. It's specs, PRs, architecture decisions, research papers, PDFs, regulations, vault notes — the context your agent needs to stop guessing.

Why I built this

I was writing a French tax article (~50 pages of regulatory text, cross-references between code articles, case law, administrative doctrine). Claude Code kept grep-ing the same directories in loops, running out of context, and producing confidently wrong citations. I'd added more memory, better prompts, a smarter model. None of it worked, because the agent wasn't reasoning badly — it just couldn't find the right paragraph in a 2,000-file legal corpus. So I stopped trying to make the model smarter and built the layer it was missing. That's RTFM.

Related MCP server: MemoryMesh

The solution

RTFM indexes everything. One command, one SQLite file, one retrieval layer your agent queries before grepping.

pip install rtfm-ai && cd your-project && rtfm init

30 seconds. Claude Code now searches your indexed knowledge base — code and docs and PDFs and whatever else you drop in — with full-text, semantic, or hybrid search. The agent sees 300 tokens of metadata first, then expands only what's relevant. Progressive disclosure instead of context dumps.

Free. Runs locally. No API keys. No cloud. Your data stays yours.

What it looks like

$ rtfm search "authentication flow" --limit 3
[1] src/auth/handlers.py > authenticate_user (p.2)    score 9.12
    src/auth/handlers.py:147  42 lines
[2] docs/architecture/auth.md > SSO flow (p.1)        score 7.84
    docs/architecture/auth.md:1   23 lines
[3] docs/ADR/0007-oauth.md > Decision (p.1)           score 6.90
    docs/ADR/0007-oauth.md:12  18 lines

Three results, ~300 tokens. The agent decides what to read next with rtfm_expand(source, target_section) — not a context dump, a conversation.

Quick start

Recommended — Claude Code plugin

In Claude Code (CLI or Desktop Code tab) :

/plugin marketplace add roomi-fields/claude-plugins
/plugin install rtfm@roomi-fields

RTFM is distributed via the roomi-fields/claude-plugins marketplace, which also ships notebooklm-mcp for citation-backed Q&A. To grab both at once:

/plugin install notebooklm@roomi-fields

That's it. The plugin auto-initializes each project on first use:

  • Creates .rtfm/library.db (one SQLite file)

  • Injects search instructions into CLAUDE.md

  • Pre-grants permission for the MCP tools (no prompt every search)

  • Indexes the project on the first prompt, re-indexes incrementally on every prompt

No pip install required. Pure Python, runs on Linux / macOS / Windows / WSL with Python 3.10+ already on PATH. The plugin bundles its own MCP server (no mcp SDK dep) and resolves python3 / python / py automatically.

Then say to Claude: "Find the authentication flow" — it uses rtfm_search instead of grepping.

Optional extras (semantic search, PDF parsing)

The core plugin is dependency-free. Heavier optional extras (embedding model, PDF parsers) install on demand into an isolated venv inside the plugin's data directory — no pollution of your system Python, no PEP 668 conflicts:

/rtfm:install-embeddings    # FastEmbed ONNX (~85 MB), semantic + hybrid search
/rtfm:install-pdf           # pdftext only (~50 MB), fast text extraction
/rtfm:install-pdf-full      # + marker-pdf + CPU-only torch (~1.5 GB), complex layouts

The pdf-full install uses PyTorch's CPU-only index (no CUDA, no GPU needed) to stay around 1.5 GB instead of 5 GB.

Restart Claude Code after install for the extras to be picked up.

Manual install (Cursor, Codex, Claude Desktop chat, other MCP clients)

For clients without Claude Code's plugin system :

pip install rtfm-ai
cd /path/to/your-project
rtfm init

Then point your MCP client at rtfm-serve (the entry exposed by the pip package). Optional extras via pip install rtfm-ai[embeddings,pdf].

How it compares

RTFM

Augment CE

Sourcegraph

Code-Index-MCP

MemPalace

Code indexing

✅ (AST-aware)

✅

✅

✅

Shallow (char-chunk)

Docs, specs, markdown

✅ (header-parsed)

Partial

❌

Limited

Verbatim chunks

Legal / regulatory

✅ (XML, BOFiP)

❌

❌

❌

❌

Research (LaTeX, PDF)

✅

❌

❌

❌

❌

Custom parsers

✅ (~50 lines)

❌

❌

❌

❌

Knowledge graph

✅ (file/code links)

❌

Partial

❌

Entity graph (people)

File version history

✅ (unlimited)

❌

❌

❌

❌ (purge-and-replace)

MCP native

✅

✅

✅

✅

✅

Runs locally

✅

Cloud

Enterprise

✅

✅

Open source

MIT

❌

Partial

✅

MIT

Price

Free

$20-200/mo

$$$/mo

Free

Free

RTFM is the only open-source option that indexes multi-domain content with structural parsing, a code-level knowledge graph, and unlimited per-file history. That's the niche.

Different from MemPalace specifically: MemPalace is an entity-level memory for conversations (who/project/decision triples in SQLite, plus verbatim chunks in ChromaDB). RTFM is a retrieval layer for artefacts — parsed by format, linked at the file level, versioned over time. The two are stackable, not competing.

For a deeper breakdown of the design choices behind any RAG (chunking, retrieval, augmentation, integration, freshness, storage), see RAG Fundamentals — the 6 axes →

Memory that survives sessions

Between sessions, most agents forget. RTFM indexes Claude Code's own memory files across every project on your machine, with full version history.

rtfm memory                    # Manual snapshot
rtfm memory --install-hook     # Auto-snapshot on every SessionEnd

  • Cross-project index — one DB at ~/.rtfm/memory.db sees every ~/.claude/projects/*/memory/ directory on your machine. Ask rtfm_search("OAuth auth decisions") and get hits from all 18 of your projects.

  • Unlimited version history — every change to a memory file is snapshotted (no prune). rtfm_history <slug> returns the full evolution.

  • Auto-snapshot on SessionEnd — one command installs a global Claude Code hook. Every session you close captures a new snapshot.

  • Curated, not verbatim — RTFM indexes the notes the agent already curated itself during the session (small, structured, signal-dense). Different philosophy from MemPalace, which indexes the full conversation transcripts in ChromaDB (large, noisy, needs aggressive semantic filtering).

Obsidian vault mode

RTFM is the retrieval layer for the Karpathy LLM Wiki pattern. Karpathy himself wrote: "at small scale the index file is enough, but as the wiki grows you want proper search." This is proper search.

cd /path/to/your-obsidian-vault
rtfm vault

  • Detects .obsidian/, proposes a folder → corpus mapping

  • Resolves [[wikilinks]] following Obsidian rules → stored as graph edges

  • Generates _rtfm/ with Obsidian-native navigation (index, graph with Mermaid, hubs, orphans, Dataview frontmatter)

  • Tested on a 1,700-note research vault

_rtfm/
├── index.md      # Hub: corpus list, top connected documents
├── graph.md      # Hub documents, orphans, broken links, Mermaid
├── recent.md     # Recently modified files
└── corpus/       # Per-corpus indexes

The LLM still writes your wiki. RTFM handles the retrieval that index.md can't scale to.

Full Obsidian guide →

NotebookLM integration

RTFM pairs naturally with notebooklm-mcp. NotebookLM caps you at 50 queries/day per notebook; RTFM removes that ceiling by indexing answers locally — ask once, retrieve forever, offline, in milliseconds.

notebooklm-mcp's /batch-to-vault endpoint writes citation-backed Q&A as {slug}.md (markdown with frontmatter) plus {slug}.json (structured nblm-answer-v1 sidecar). Both are guaranteed to coexist. Two integration paths, both ship today:

  • Path A — Markdown (zero config): drop the vault into RTFM and rtfm sync. The default markdown parser slices each answer into question / answer / per-citation chunks automatically. No mapping, no schema, no code.

  • Path B — JSON sidecar (typed metadata): drop a nblm-answer.yaml mapping into .rtfm/mappings/. Each .json answer file produces typed chunks with notebook_id, source_name, citation_marker queryable via SQL, plus cites edge candidates between answers and sources.

Use Path A unless you specifically need to filter or graph by structured citation fields.

Full NotebookLM recipe →

What I measured

I ran two kinds of benchmarks. The honest picture is nuanced — retrieval helps most on tasks that are actually solvable and where the agent is spending time looking for things.

Document-heavy task: French tax article generation (B10)

Writing a ~50-page regulated article from a corpus of legal code, case law, and administrative doctrine. Same agent (Claude Code + Sonnet 4), same prompt, eight configurations tested.

Configuration

Duration

Cost

Tokens

Baseline (no RTFM)

8m 16s

$22.61

8.21 M

With RTFM (FTS default)

6m 58s

$11.14

3.22 M

Δ : −51 % cost, −61 % tokens, −16 % duration — with better factual accuracy. This is the use case RTFM was built for: navigating a large multi-domain corpus where grep misses the right paragraph.

Code task: FeatureBench (LiberCoders dataset)

11 tasks, 3 repos of varying size, 4 conditions (A = standard prompt with file paths; B = discovery, no paths; C = RTFM FTS; D = RTFM hybrid), 3 runs each.

Repo

Size

Where RTFM helps

metaflow

620 files

Everyone resolves — RTFM adds no measurable gain

astropy

1,119 files

All conditions 25–30 % F2P pass; none fully resolve

mlflow

8,255 files

All conditions 0–5 % F2P pass; none fully resolve

On a single smaller-scope run (test_stub_generator on metaflow), RTFM cut agent time by −37 % vs the no-paths baseline. On the larger repos, the tasks themselves were too hard for Sonnet 4 to resolve inside a 20-minute timeout regardless of retrieval.

The honest caveats

  • Single model (Sonnet 4), single agent (Claude Code). Not statistically bullet-proof.

  • On small repos (< 1k files), grep is enough and RTFM adds overhead.

  • FeatureBench measures code modification, not information retrieval. It's the wrong benchmark for a retrieval tool — I'm running against it because it's what exists. Better-suited benchmarks (RepoQA, SWE-QA, LocAgent) are on the roadmap.

What this says

RTFM measurably wins when the bottleneck is "find the right paragraph in a 2,000-file corpus". It doesn't magically make unsolvable tasks solvable. The model still has to do the work — RTFM just makes sure it has the right context to do it with.

Who it's for

RTFM works anywhere your project isn't just code:

  • LegalTech — Code + tax law + regulatory specs. Ships with Legifrance XML and BOFiP parsers.

  • Research — Code + LaTeX papers + datasets. Ships with LaTeX and PDF parsers.

  • FinTech — Code + financial regulations + XBRL reports. Write an XBRL parser in 50 lines.

  • HealthTech — Code + medical records (HL7/FHIR) + clinical guidelines.

  • Solo devs with big projects — Stop watching your agent grep the same 8,000 files every session.

  • Obsidian / PKM users — Make your vault actually searchable by your AI.

  • Any regulated industry — If your project mixes code with domain documents, RTFM is for you.

Full feature list

Search & retrieval

  • FTS5 full-text search — instant, zero-config, works out of the box

  • Semantic search — optional embeddings (FastEmbed/ONNX, no GPU needed)

  • Hybrid mode — combine both, rank by relevance score

  • Metadata-first — results return file paths + scores (~300 tokens), not content dumps

  • Progressive disclosure — agent expands only the chunks it actually needs

  • Knowledge graph — wikilinks + Python imports resolved as graph edges, hub detection, centrality ranking

Multi-format indexing

  • 22 parsers built-in — Markdown, Python (AST), LaTeX, YAML, JSON, TOML, Shell, PDF, XML, HTML, SQLite, Jupyter, CSV/TSV, XLSX, EPUB, MOBI/AZW, FB2, DJVU, DOCX, ODT, RTF, plain text

  • Extensible — add any format in ~50 lines of Python

  • Auto-sync hooks — index stays fresh every prompt, zero manual work

  • Incremental — only re-indexes what changed

Integration

  • Native Claude Code plugin — /plugin install rtfm@roomi-fields/rtfm, auto-init per project

  • Pure-Python MCP server — 0 external deps, no mcp SDK / pydantic / native binaries

  • Cross-platform — Linux, macOS, Windows, WSL (only requires Python ≥ 3.10 on PATH)

  • 13 MCP tools — search, context, expand, graph, history, sync, tags, ...

  • Manual install fallback — pip install rtfm-ai for Cursor, Codex, Claude Desktop chat, any other MCP client

  • CLI + Python API — scriptable for pipelines

  • Non-invasive — doesn't touch your code, doesn't replace your editor

The parser architecture

Need to index a format nobody supports? Write a parser in ~50 lines.

from rtfm.parsers.base import BaseParser, ParserRegistry
from rtfm.core.models import Chunk
import json
from uuid import uuid4

@ParserRegistry.register
class FHIRParser(BaseParser):
    """Parse HL7 FHIR medical records."""
    extensions = ['.fhir.json']
    name = "fhir"

    def parse(self, path, metadata=None):
        data = json.loads(path.read_text())
        for entry in data.get('entry', []):
            resource = entry.get('resource', {})
            yield Chunk(
                id=resource.get('id', str(uuid4())),
                content=json.dumps(resource, indent=2),
                book_title=f"FHIR {resource.get('resourceType', 'Unknown')}",
                book_slug=resource.get('id', 'unknown'),
                page_start=1,
                page_end=1,
            )

Drop it in your project, restart Claude Code, your medical AI agent now understands FHIR records.

Two levels of JSON integration

For JSON-based formats specifically, RTFM offers a second extensibility path that doesn't need any Python:

Level

What you do

What you get

1. Generic

Nothing. Just index the file.

Each top-level key becomes a chunk. Full-text search works on values.

2. Mapped

Drop a YAML mapping in .rtfm/mappings/ (~30 lines).

Typed chunks with declared metadata, custom titles, foreach extraction over arrays, edge candidates. The producing project (NotebookLM, Linear, Notion, OpenAPI…) ships the mapping; RTFM stays generic.

See JSON schema mappings for the full reference, and RTFM × NotebookLM for a concrete recipe.

Built-in parsers

Parser

Extensions

Strategy

Markdown

.md

Split by headers, YAML frontmatter extraction

Python

.py

AST-based: each class/function = 1 chunk

LaTeX

.tex

Split by \section, \chapter, etc.

YAML

.yaml, .yml

Split by top-level keys

JSON

.json

Split by top-level keys or array elements

TOML

.toml

Top-level tables; emits depends_on edges (PEP 621, Cargo, Poetry)

Shell

.sh, .bash, .zsh

Function-aware chunking

PDF

.pdf

Page-based (pip install rtfm-ai[pdf])

Legifrance XML

.xml

French legal codes (LEGI format)

BOFiP HTML

.html

French tax doctrine

SQLite

.sqlite, .sqlite3, .db

Schema + sample rows per table; FK edges (read-only)

Jupyter

.ipynb

Group cells by markdown heading; outputs dropped

CSV / TSV

.csv, .tsv

Header + sample rows + lightweight type inference

XLSX

.xlsx

Per-sheet schema + sample (pip install rtfm-ai[xlsx])

Plain text

.js, .ts, .rs, .go, ...

Line-boundary chunks (~500 chars)

MCP tools

Tool

What it does

rtfm_search

Search the index (FTS, semantic, or hybrid)

rtfm_context

Get relevant context for a subject (metadata-only)

rtfm_expand

Show all chunks of a source with full content

rtfm_discover

Fast project structure scan (~1s, no indexing needed)

rtfm_books

List indexed documents

rtfm_stats

Library statistics

rtfm_sync

Sync a directory (incremental)

rtfm_ingest

Ingest a single file

rtfm_tags

List all tags

rtfm_tag_chunks

Add tags to specific chunks

rtfm_remove

Remove a file from the index

rtfm_graph

Show dependency graph for a source (imports, links)

rtfm_history

File version history and memory snapshots

CLI reference

# Search
rtfm search "authentication flow"
rtfm search "article 39" --corpus cgi --limit 5

# Sync
rtfm sync                              # All registered sources
rtfm sync /path/to/docs --corpus docs  # Specific directory
rtfm sync . --force                    # Force re-index

# Source management
rtfm add /path/to/docs --corpus docs --extensions md,pdf
rtfm sources

# Obsidian vault
rtfm vault                             # Initialize for cwd vault
rtfm vault /path/to/vault              # Specific vault
rtfm vault --regenerate                # Regenerate _rtfm/ files

# Cross-project Claude memory
rtfm memory                            # Manual snapshot
rtfm memory --install-hook             # Auto-snapshot on SessionEnd

# Status & info
rtfm status
rtfm books
rtfm tags
rtfm history path/to/file.md           # Memory version history

# Semantic search
rtfm embed                             # Generate embeddings (one-time)
rtfm semantic-search "tax deductions" --hybrid

# MCP server
rtfm serve

Python API

from rtfm import Library

lib = Library("my_library.db")

# Index
stats = lib.ingest("documents/article.md", corpus="docs")
result = lib.sync(".", corpus="my-project")  # SyncResult(+3 ~1 -0 =42)

# Search
results = lib.search("depreciation", limit=10, corpus="cgi")
results = lib.hybrid_search("amortissement fiscal", limit=10)

# Export for LLM
prompt_context = results.to_prompt(max_chars=8000)

lib.close()

Where RTFM fits

RTFM isn't a task manager. It's not an agent framework. It's the knowledge layer your agent needs underneath whatever you're already using.

┌─────────────────────────────────┐
│  GSD / Taskmaster / Claude Flow │  ← Orchestration
├─────────────────────────────────┤
│              RTFM               │  ← Knowledge (you are here)
├─────────────────────────────────┤
│          Claude Code            │  ← Execution
└─────────────────────────────────┘

Without RTFM, your orchestrator drives an agent that hallucinates. With RTFM, the agent knows what it's building on.

Contributing

Adding a parser is the easiest way to contribute — and the most impactful. See CONTRIBUTING.md.

Found a bug? Have an idea? Open an issue.

Thanks

@AVeryTastyRaspberry made RTFM run on native Windows. RTFM is developed on Linux, and every command was broken there — the CLI died at import time before it could parse an argument. The report (#8) named the line; the testing that followed, on a real Windows 11 machine and checked against tasklist rather than against RTFM's own claims, found five more defects behind it and confirmed each fix. #9 then traced the console windows that kept popping up. That is a platform this project could not otherwise support.

License

MIT — use it, fork it, extend it, ship it.

Author

Romain Peyrichou — @roomi-fields

Code indexers see your code. RTFM sees everything.

⭐ Star on GitHub if RTFM saves your agent from hallucinating.

Curious how it works under the hood? See the Architecture — SQLite + FTS5, the parser registry, and the priority-queue worker (ingest → embed → OCR).

Available Tools

8 tools
rtfm_booksB

List indexed books with per-corpus summary and pagination.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNomax books per page (default 50, 0 for all)
corpusNofilter by corpus name (optional)
offsetNoskip N books for pagination (default 0)
projectNoanother project's index to read instead of this one — its name (``"hub"``), or its path when two projects share a name.

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full behavioral burden. It does convey the read-only 'List' behavior and the presence of pagination, which is useful context. But it does not explain what the per-corpus summary contains, what the response looks like, or whether cross-project access (via the project parameter) has any caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler or repetition of schema details. Every word adds value: the operation, the per-corpus summary, and pagination.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four parameters, no output schema, and no annotations, the description is too thin to fully specify the returned shape of the per-corpus summary or the default/current project behavior. It covers the high-level operation but leaves an agent guessing about response format and cross-project semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already documented in the input schema. The description only vaguely relates to corpus and pagination without adding meaning beyond the schema, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific operation ('List indexed books') and adds distinctive qualifiers (per-corpus summary, pagination) that separate it from the search, coverage, and history siblings. However, it never explicitly names a sibling or defines the per-corpus summary, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to choose this tool over rtfm_search, rtfm_discover, or rtfm_coverage, and no exclusions are given. The only signal is the literal purpose, which is not enough to steer an agent among eight siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rtfm_contextA

Get sources relevant to a subject. Returns paths + line ranges, no content. Use rtfm_expand to read.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNomax sources (default 5)
scopeNocorpus filter (optional)
projectNoanother project's index to read instead of this one — its name (``"hub"``), or its path when two projects share a name.
subjectYestopic, concept, file path, or question

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that only paths and line ranges are returned and that content is intentionally excluded, which is a non-obvious and important behavior. It does not mention side effects, but the read-oriented language makes mutation unlikely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler: purpose, output shape, and the sibling alternative are each covered. Every sentence earns its place, and the most decision-relevant facts are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-style lookup tool with fully documented parameters and a clear output description, the definition is largely complete. It could be more complete by contrasting with rtfm_search, but nothing essential for selecting or invoking the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters already have meaningful descriptions. The tool description adds no extra parameter-level meaning beyond what the schema provides, which matches the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Get sources relevant to a subject') and clarifies the result shape as paths + line ranges, not content. It distinguishes itself from rtfm_expand, but does not explicitly differentiate from sibling rtfm_search, which likely serves a similar lookup purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear alternative: 'Use rtfm_expand to read', which tells the agent to use a different tool when content is needed. It does not, however, specify when to prefer rtfm_context over rtfm_search or other siblings, so the guidance is partial.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rtfm_coverageA

How much of a project this index actually holds.

Say this before answering from the index when completeness matters: a partial index read as a complete one is how an absent result becomes "there is nothing on the subject".

The denominator is the scan's own list of files — not everything in the directory. Logs, lock files, state files and build output are not counted as gaps, because RTFM was never going to index them.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectNoanother project to measure — its name ("hub"), or its path when two projects share a name. Omit for the current one.

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does well: it clarifies that the denominator is the scan's file list, not the whole directory, and that excluded files are not counted as gaps. It does not disclose the return format, but the core measurement semantics are transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each adding a distinct piece of information: purpose, usage trigger, denominator definition, and exclusion rationale. It is slightly discursive but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description should clarify what the agent receives in return; 'how much ... holds' is suggestive but not explicit. It also leaves the optional parameter's 'current project' default to the schema. Overall it is adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the optional 'project' parameter fully. The description adds no parameter-level detail beyond the schema, placing it at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description answers 'how much of a project the index holds,' which identifies the tool as a coverage-measuring operation on a specific resource. It is distinct from the search/expand/context siblings in subject matter, though it does not explicitly compare itself to them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to invoke/mention coverage before answering from the index when completeness matters, giving a concrete condition of use. It does not name the sibling alternatives or state when not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rtfm_discoverA

Scan a project directory and return a structural map (file types, languages, entry points, size breakdown). ~1 second.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoproject root directory (default ".")

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It adds a useful performance trait ('~1 second') and implies a read-only scan, but it does not disclose behaviors like recursive traversal, handling of invalid paths, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that communicates the action, expected output, and rough execution time without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no output schema, the description adequately explains what is returned and the expected scope. Some guidance about errors or edge cases would improve completeness, but it is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter, 'path', is already described as 'project root directory (default ".")'. The description adds little semantic detail beyond the schema; it merely repeats the notion of a project directory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Scan a project directory' and return a 'structural map' with concrete output elements. It is clear but does not explicitly differentiate itself from sibling tools like rtfm_search or rtfm_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: if you need a structural overview of a project directory, this is the tool. However, there is no explicit guidance about when to prefer it over sibling tools or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rtfm_expandA

Read content of an indexed file with line numbers.

Use after rtfm_search. Like Read, but for indexed files.

ParametersJSON Schema
NameRequiredDescriptionDefault
countNochunks to return, 0 for all remaining (default 1)
queryNofilter chunks by relevance within the file
offsetNopagination offset (default 0)
sourceYesabsolute file path (from search results)
targetNojump to section name ("class Foo") or "L120"
projectNoanother project's index to read instead of this one — its name (``"hub"``), or its path when two projects share a name.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the primary behavior (returns file content with line numbers) and the indexed-file precondition, but it does not elaborate on other behavioral traits such as pagination behavior, the meaning of 'chunks', or any limitations. For a read-only tool this is acceptable but minimal, so a mid-range score is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The main purpose is front-loaded, and the usage guidance is immediately after. Every sentence earns its place without repeating schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with no output schema, the description is short but supported by rich parameter descriptions in the schema. It clearly tells the agent when to use the tool and what the output looks like (content with line numbers). Missing details like how target or offset interact are already covered by the schema, so the description is comparatively complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters thoroughly. The description does not add extra meaning about count, offset, target, or project beyond what the schema provides, so the baseline of 3 applies. No parameter guidance is missing because the schema handles it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Read') and resource ('content of an indexed file with line numbers'), which clearly distinguishes it from rtfm_search and other sibling tools. The secondary sentence 'Use after rtfm_search' reinforces that this is the follow-up read step, and 'Like Read, but for indexed files' differentiates it from a general-purpose Read tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Use after rtfm_search', telling the agent when in the workflow to invoke this tool. The comparison 'Like Read, but for indexed files' provides an alternative and clarifies that this should be used instead of Read when the file is part of an index. This is strong, actionable usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rtfm_graphB

Show graph neighbors of a file (imports, links, includes, citations).

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesbook slug or absolute file path
directionNo"outgoing" (deps), "incoming" (dependents), or "both"
relation_typeNofilter by "import" | "link" | "include" | "cite"

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. It discloses that the tool returns graph neighbors and hints at scoping via relation types, which is useful. However, it does not clarify whether traversal is immediate only, whether results are ordered or limited, whether filtering is optional, or any side effects (though this appears read-only). The lack of annotation support leaves room for ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero filler. Every word contributes: the verb, the resource, the graph-neighbor scope, and the enumerated relation types. This is model conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-style tool with 100% parameter schema coverage, the description covers the core purpose but leaves gaps: no default behavior for 'direction' or 'relation_type' is stated, no output format is described, and no distinction from sibling tools is provided. Since there is no output schema, a bit more detail about the result shape or default behavior would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all three parameters. The description adds a small amount of context by listing relation types in prose, but it does not meaningfully enrich the semantic understanding beyond what the schema provides. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Show'), a resource ('graph neighbors of a file'), and enumerates the relation types (imports, links, includes, citations). It clearly communicates what the tool does, though it doesn't explicitly differentiate from the sibling tool rtfm_expand, which may have a similar graph-expansion role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like rtfm_expand or rtfm_context. The description implies use when needing neighbor information, but there is no explicit context, prerequisites, or exclusions to help an agent choose among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rtfm_historyA

Show version history of an indexed file, or retrieve a specific version.

Each time a file is re-synced, its previous content is saved as a snapshot.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesfile path (an identity also works).
projectNoanother project's index to read instead of this one — its name ("hub"), or its path when two projects share a name.
versionNoVersion number to retrieve (optional). If omitted, lists all versions.

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It discloses the snapshot mechanism ('Each time a file is re-synced, its previous content is saved as a snapshot'), and the verbs 'Show' and 'retrieve' indicate a read-only operation. It does not discuss edge cases or restrictions, but the core behavioral trait is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with no filler. The primary action is front-loaded in the first sentence, and the second sentence provides essential background about snapshots. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All parameters are documented in the schema and the snapshot mechanism is explained, but there is no output schema and the description does not state what the returned history or retrieved version looks like. An agent may not know whether it gets a list of version numbers, metadata, or file content. This is a moderate gap given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only mirrors the role of the version parameter. No additional detail about source, project, or version formats is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb and resource: 'Show version history of an indexed file, or retrieve a specific version.' This clearly identifies the tool's function and distinguishes it from sibling search, graph, and discovery tools by focusing on historical snapshots. The second sentence adds insight into how history is captured.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the context clear: use this tool when you need a file's version history or a particular saved version. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of fully explicit usage routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.45.0
    • First observedrtfm_books
    • First observedrtfm_context
    • First observedrtfm_coverage
    • First observedrtfm_discover
    • First observedrtfm_expand
    • First observedrtfm_graph
    • First observedrtfm_history
    • First observedrtfm_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation3/5

Most tools are clearly distinct, but rtfm_search and rtfm_context both accept a subject and return paths plus line ranges with no content, making their boundaries unclear. The descriptions do not offer a crisp rule for choosing between them, though the other six tools are easy to tell apart.

Naming Consistency3/5

All tools share the rtfm_ prefix and use snake_case, which is good, but the pattern mixes verbs (search, discover, expand) with bare resource nouns (books, coverage, context, graph, history). A consistent verb_noun convention like rtfm_list_books or rtfm_get_coverage would be more predictable.

Tool Count5/5

Eight tools is a well-scoped size for a knowledge-base/index server: enough to cover search, context, reading, exploration, coverage, history, and project discovery without feeling bloated. Each tool has a reasonable place in the workflow even if search and context could potentially be consolidated.

Completeness4/5

The server covers the core read-only workflows well: finding sources, reading content, exploring relationships, checking coverage, and viewing history. Minor gaps exist around explicit index management and book-specific operations, but most agent tasks involving querying an indexed codebase can be completed without dead ends.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

  • MemoryMesh

    kilhubprojects
    A
    license
    A
    quality
    D
    maintenance
    A universal, local-first MCP hub that indexes personal files (documents, code, etc.) and provides private semantic search via hybrid dense+BM25 retrieval, enabling agents like Claude Desktop to query your data without sending it to the cloud.
    17
    6
    MIT

  • rag-retriever-mcp

    code-lawyer
    F
    license
    A
    quality
    B
    maintenance
    A local-first document retrieval engine that mounts as an MCP tool for agents to index files, search for relevant passages, and let the agent's own LLM answer.
    4
    -

  • minirag-mcp

    sfrangulov
    A
    license
    A
    quality
    B
    maintenance
    Local-first RAG MCP server that indexes local documents and provides hybrid search (semantic + keyword) with file ingestion, URL fetching, and a CLI, keeping data on-device.
    11
    65
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/roomi-fields/rtfm'

If you have feedback or need assistance with the MCP directory API, please join our Discord server