Skip to main content

Symbol-aware, staleness-tracking RAG over a codebase, exposed over MCP; layers on rag-timetravel.

Project description

codebase-rag

A self-updating, symbol-aware vector index and reference graph of a codebase, exposed over MCP, so any MCP-compatible LLM agent can understand a whole repository cheaply instead of burning tokens on dozens of grep and glob calls.

Why

Agents working against a shared codebase pay for context in two bad ways: full-context stuffing (expensive, slow, breaks on large repos) or ad hoc grep/glob exploration (burns tool calls, produces inconsistent understanding across agents). Most of that grep traffic is not semantic search; it is structural traversal: "where is this defined", "who calls this", "what does this depend on", "what breaks if I change it". A vector index alone cannot answer those. codebase-rag pairs a semantic vector index with a symbol reference graph and serves both over MCP, so an agent answers those questions in one tool call instead of N greps, and the index stays in sync as the code changes.

What it gives an agent

Three layers, all queryable over MCP:

  1. Vector layer: semantic search over symbol-level chunks (functions, methods, classes, module statements) for Python and JS/TS.
  2. Graph layer: a reference/call graph (calls, imports, contains edges) with go-to-definition, find-callers, find-callees, dependencies, and neighborhood traversal.
  3. Understanding layer: whole-codebase tools built on the graph: a token-budgeted repo map (PageRank over the reference graph), hybrid graph-aware retrieval, and change-impact analysis.

Architecture

codebase-rag/
  chunker/     tree-sitter symbol chunking (Python, TS/JS/JSX/TSX) + edge extraction + ignore rules
  store/       LanceDB tables (chunks, edges, annotations, repo_meta) + embedder fingerprinting
  graph/       name resolution + dependency-free PageRank
  sync/        git blob-hash staleness audit + pre-push hook backstop
  mcp/         the MCP tool surface (service core + server wiring)
  cli.py       init / reindex / status / serve / graph

Storage, embedding, and reranking are not reimplemented here. codebase-rag depends on rag-timetravel for the Embedder protocol, the reranker, and LanceDB dataset versioning. It uses a direct-write path: rag-timetravel's own ingest() re-chunks with a fixed-size splitter and has a hardcoded schema, so codebase-rag owns its own symbol-aware LanceDB tables and writes pre-chunked symbol rows directly, reusing only the embedder and reranker. This package is the code-aware layer on top: chunking, edges, staleness, sync, and the MCP tools.

Storage schema

Four LanceDB tables, versioned via rag-timetravel's dataset versioning:

  • chunks: one row per symbol. Fields include chunk_id, file_path, symbol, symbol_kind, content, embedding, imports, git_blob_sha, start_line, end_line, repo_id, embedder_fingerprint.
  • edges: one row per graph edge. Fields: id, src_symbol, dst_name, edge_kind (calls | imports | contains), file_path, git_blob_sha, start_line, repo_id.
  • annotations: semantic notes attached to a symbol, versioned separately from chunks so reindexing a symbol never touches its annotations.
  • repo_meta: per-repo metadata (repo_id, root_path, embedder_fingerprint, last_full_index_sha, languages).

Embedder fingerprinting

embedder_fingerprint is a hash of the embedder's model id and dimensionality, stored in repo_meta at init time. Every write path checks the incoming embedder's fingerprint before writing; on mismatch the write is rejected rather than silently corrupting search quality for a shared index. Switching embedders requires an explicit full re-embed.

Staleness detection

A chunk is stale when its stored git_blob_sha no longer matches the current blob hash of its file (git hash-object). status walks the index, recomputes current blob hashes, and reports ok / stale / deleted per file. This is a deterministic audit, independent of any wall-clock or version-count heuristic.

Sync

Two triggers keep the index fresh, both re-deriving chunks and edges from the file on disk (the index is never written directly by an LLM):

  • Git pre-push hook (codebase-rag init --install-hook): the correctness backstop; catches edits from anything that did not go through an MCP client (IDE edits, merges).
  • The reindex_file MCP tool: the latency optimization; an agent calls it right after editing a file so its own session sees fresh results without waiting for a push.

Concurrent reindex_file writes are safe: LanceDB uses manifest-based optimistic concurrency, and the store retries on commit conflict rather than overwriting.

Install

pip install codebase-rag
# or, from source:
pip install -e .

Requires Python 3.10+ and a git repository as the source of truth for change detection. The default embedder (all-MiniLM-L6-v2, local, 384-dim) needs the optional local extra:

pip install -e ".[local]"

Quickstart

# 1. Index a repo and install the pre-push hook
codebase-rag init /path/to/repo --install-hook

# 2. Check freshness at any time
codebase-rag status

# 3. Reindex manually (full, or only what changed since a commit)
codebase-rag reindex --full
codebase-rag reindex --changed-since <sha>

# 4. Print the neighborhood of a symbol as text
codebase-rag graph UserService.authenticate --depth 1

# 5. Serve the MCP tools to an agent
codebase-rag serve

Point any MCP client at codebase-rag serve and the tools below become available.

Add it to an existing codebase

Five minutes, from the root of a git repository:

# 1. Install (with the local embedder extra so no API key is needed)
pip install -e ".[local]"        # or: pip install codebase-rag[local]

# 2. (optional) Tell it what to skip, on top of the built-in defaults
#    (node_modules, .venv, dist, build, __pycache__, *.min.js are always skipped)
cat > .codebaseragignore <<'EOF'
# gitignore syntax
migrations/
*.generated.ts
vendor/
EOF

# 3. Build the index and install the git pre-push hook
codebase-rag init . --install-hook

# 4. Confirm it indexed cleanly
codebase-rag status          # expect: ok=<N> stale=0 deleted=0

The first init embeds every symbol, so it takes a moment on a large repo; subsequent updates are incremental. From then on the index stays fresh two ways: the pre-push hook reindexes changed files on every push, and an agent can call reindex_file right after editing. Commit .codebaseragignore if you want it shared; the .codebase-rag/ index directory is local and should stay gitignored (add /.codebase-rag/ to your .gitignore).

For a team, everyone runs init once locally against the same checkout. The index itself is not committed; it is derived from source, so each clone rebuilds it deterministically.

Use it with a coding agent

codebase-rag serve is a standard stdio MCP server, so any MCP-capable agent can connect with the usual config. In every case the command is codebase-rag and the args are serve --repo <path>.

Claude Code (from the repo root):

claude mcp add codebase-rag -- codebase-rag serve --repo .

or add it to .mcp.json at the project root (shareable with the team):

{
  "mcpServers": {
    "codebase-rag": {
      "command": "codebase-rag",
      "args": ["serve", "--repo", "."]
    }
  }
}

Cursor (.cursor/mcp.json in the project, or the global ~/.cursor/mcp.json):

{
  "mcpServers": {
    "codebase-rag": {
      "command": "codebase-rag",
      "args": ["serve", "--repo", "/absolute/path/to/repo"]
    }
  }
}

Codex CLI (~/.codex/config.toml):

[mcp_servers.codebase-rag]
command = "codebase-rag"
args = ["serve", "--repo", "/absolute/path/to/repo"]

Any other MCP client (Windsurf, Zed, Continue, a custom Agent SDK host) uses the same command/args pair. If codebase-rag is installed in a virtualenv, point command at that env's executable (for example /path/to/.venv/bin/codebase-rag) so the agent launches the right one.

How an agent should use it

The tools are most effective in this order; a short system-prompt note like the following trains the agent to prefer them over grep:

This repo has a codebase-rag MCP server. Call get_repo_map first to orient. Use search_context for "how does X work", find_definition / get_callers / get_callees for navigation, and impact_of before changing a signature. Prefer these over grep. After editing a file, call reindex_file on it so later searches stay accurate.

A typical loop: get_repo_map to learn the important symbols, search_context("where are requests authenticated") to pull a function plus its call context in one shot, get_callers / impact_of to scope a change, edit, then reindex_file to keep the index in sync.

MCP tools

Vector and retrieval

  • search_code(query, k=8, kind=None): semantic search over symbols, optionally filtered by symbol_kind (function | method | class | module_statement). Reranked before return.
  • search_context(query, k=5, hops=1): hybrid graph-aware retrieval. Finds semantic entry points, then graph-expands each hops steps into one coherent, token-bounded subgraph. Nodes are tagged by role (match | caller | callee | dependency). Use this instead of a search followed by several follow-up greps.

Structural navigation (the grep replacements)

  • find_definition(name): candidate definitions for a name (go-to-definition), resolved across files by name plus import hints.
  • get_callers(symbol): every call site of a symbol.
  • get_callees(symbol): everything a symbol calls.
  • get_dependencies(file_path): the imports a file depends on.
  • neighborhood(symbol, depth=1): the connected subgraph around a symbol, token-bounded.

Whole-codebase understanding

  • get_repo_map(budget_symbols=50, file_path=None): a token-budgeted structural map. Ranks symbols by PageRank over the reference graph and returns the most central ones as a compact skeleton. Call this first to orient in an unfamiliar repo for a few hundred tokens instead of reading dozens of files. Pass file_path to focus the map on one file and its neighbors.
  • impact_of(symbol, max_depth=3): reverse-reachability. The transitive set of symbols that depend on the given symbol. Check this before changing a signature.

Retrieval and bookkeeping

  • get_symbol(symbol_id): a single chunk plus its attached annotations.
  • get_file_context(file_path): all chunks for a file, ordered by line number.
  • reindex_file(file_path): re-derive a single file's chunks and edges from disk. Call after any edit; skipping it leaves subsequent searches against that file stale.
  • annotate(symbol_id, note, author="agent"): attach a semantic note to a symbol (never mutates derived chunks or embeddings).
  • status(): the staleness audit (ok / stale / deleted per file).

Language support and resolution strategy

  • Python (tree-sitter-python): top-level functions, classes (whole-class chunk plus one chunk per method), and a single module-statement chunk. Decorators attach to their target. Imports are collected once per file and attached to every chunk.
  • JS/TS (tree-sitter-typescript): function declarations, named arrow/function-expression bindings, class methods, and exported const/type declarations. .tsx / .jsx components are chunked whole (JSX body included).

Graph edges are extracted from the same parse (no second pass): contains (class to method), imports (module to imported name), and calls (enclosing symbol to callee identifier). Resolution of a call/reference name to a concrete definition is intra-file precise, cross-file name-based: exact within a file, matched by name plus import hints across files. Full cross-file type resolution (the job of an LSP or type checker) is intentionally out of scope; unresolved names are still stored as useful candidate edges, and ambiguous names return multiple candidates.

Both chunkers skip generated files, node_modules, .venv, and anything matching a .codebaseragignore file (gitignore syntax).

Configuration

  • Embedder: any model the rag-timetravel Embedder protocol accepts. Default all-MiniLM-L6-v2 (local). OpenAI-compatible and Ollama endpoints are supported via the rag-timetravel factory.
  • Reranker: none by default; other rerankers from rag-timetravel can be selected.
  • Default index location: <repo_root>/.codebase-rag/lancedb.

Development

# Tests (unit + integration are offline and fast; the slow e2e uses a real model)
pip install -e ".[test,local]"
python -m pytest -q                 # full suite
python -m pytest -q -m "not slow"   # skip the model-download e2e

Non-goals

  • No non-git staleness backend; git is the source of truth for change detection.
  • No languages beyond Python and JS/TS.
  • No UI; CLI and MCP tools only.
  • No direct LLM writes to chunk text or embeddings; the index is always re-derived from source.
  • No hosted multi-tenant service; this ships as a library and CLI.

License

MIT. See LICENSE.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

codebase_rag-1.0.1.tar.gz (58.9 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

codebase_rag-1.0.1-py3-none-any.whl (46.7 kB view details)

Uploaded Python 3

File details

Details for the file codebase_rag-1.0.1.tar.gz.

File metadata

  • Download URL: codebase_rag-1.0.1.tar.gz
  • Upload date:
  • Size: 58.9 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.14.6

File hashes

Hashes for codebase_rag-1.0.1.tar.gz
Algorithm Hash digest
SHA256 d92d62ae59188b05197cb42d22a1c62237b00a889309e2feb5dcfebeb9fd220d
MD5 99821ecc6ca7d9029b407fa3d1b58930
BLAKE2b-256 2b597e6f39d026f0c9e995aa91d2bba4eacafad56530953907ea691951157b13

See more details on using hashes here.

File details

Details for the file codebase_rag-1.0.1-py3-none-any.whl.

File metadata

  • Download URL: codebase_rag-1.0.1-py3-none-any.whl
  • Upload date:
  • Size: 46.7 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.14.6

File hashes

Hashes for codebase_rag-1.0.1-py3-none-any.whl
Algorithm Hash digest
SHA256 3d3e6259597b21c4801b11565aef1be407548837c25e194202e724d3ea3d62d7
MD5 2f09b81a35842db06f14a10a923fed3f
BLAKE2b-256 dad6adc3143d1f91ef16e5de5bb66db92fff6b1ea3adcc2f1df6594e63911186

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page