Codebase Brain

Codebase Brain MCP

[CI] [License: MIT] [Python 3.12+]

An MCP server that gives AI assistants a cited, searchable memory of a codebase, including its history. Point it at a local folder or a public git URL. Claude, Cursor or any MCP client can then answer questions about the code with exact path:start-end citations.

[Claude Code using Codebase Brain to explain the history, impact and docs of a function]

Claude Code asks why TimestampSigner.unsign looks the way it does, what breaks if it changes, and whether its docs are current. Codebase Brain answers with commits, callers, tests and doc findings, all cited. (Waiting time sped up.)

The problem

AI coding assistants are good at writing new code but struggle to understand code that already exists:

• They can't see the whole project. A real codebase has thousands of files. The assistant reads a few and guesses the rest, so it misses the function that matters or invents one that doesn't exist.
• You can't check their answers. "Expiry is handled in the auth module" is no use if you can't see where. Without file and line references, you have to trust the answer or re-read the code yourself.
• They don't know why code is the way it is. The code shows what it does. The reasons ("we added this check because it crashed on Windows") live in git history and pull requests, which assistants never read. So they "clean up" code that exists for a reason and bring old bugs back.
• They don't know what a change will break, or whether the documentation still matches the code.
• Many tools send your code to someone else's server to make it searchable.

What Codebase Brain gives you

A plug-in for any AI assistant that turns a codebase into something it can actually look things up in:

• Answers with proof. Every result points to the exact file and lines, and the assistant can open them.
• Search that understands code. It finds code whether you type the exact name (calculate_invoice_total) or describe it in plain words ("how are invoices totalled?").
• The story behind the code. For any function, it shows every change made to it, who made it, why (from the commit message and pull request), and what the change was.
• What breaks if you change something. Everything that uses a function, directly or indirectly, and the tests that cover it.
• Out-of-date docs, found automatically. Documentation that mentions functions, files or settings that no longer exist, or shows examples that would no longer work.
• Private by design. Everything runs on your machine. No API keys, and your code never leaves your computer.

Why it's different (technical)

• Code-aware chunking. Python (with ast) and JavaScript / TypeScript / JSX / TSX (with tree-sitter) are split by function, class, method, arrow function, interface, type and enum, with their doc comments. Markdown is split by heading. Each chunk knows its symbol (TimestampSigner.unsign, Ky.#retry) and exact lines, so citations point at real code. Other languages are indexed in overlapping line windows.
• Hybrid retrieval. SQLite FTS5 BM25 (with camelCase / snake_case identifier splitting) plus local embeddings, merged with reciprocal-rank fusion. Exact names and fuzzy questions both work.
• Local and free. Embeddings run on your machine (fastembed, ONNX). No API keys, and no code leaves your computer.
• Incremental. Re-indexing only re-embeds files whose content changed. On a 42-file repo, a re-index with no changes takes about 2 seconds.
• History-aware. explain_history follows a function's lines back through git (git log -L), shows who wrote the current lines, and links the pull requests behind each change. So agents can answer "why is it built this way?", not just "what does it do?".
• Impact analysis. impact_of_change lists everything that uses a function, directly and transitively, plus the tests that exercise it, before an agent changes anything. It works across Python, JavaScript and TypeScript files, and follows a constructor to the code that builds its class.
• Doc-drift detection. find_doc_drift checks Markdown and reStructuredText docs against the code. It finds files, functions, settings and flags that don't exist; examples passing parameters a function doesn't take; imports that would fail; and sections last edited long before the code they describe changed. Each finding cites the doc section and suggests a fix ("Was it renamed to checkout_total?").
• Agent-friendly output. Structured tool results, read-only tool annotations, progress notifications while indexing, and clear error messages the model can act on.

Tools

Also included: the resource brain://repos, and the prompt answer_with_citations.

Install

Codebase Brain runs on your own machine, so there's no server or account, and it's free. It works with any MCP-compatible assistant. All you need is uv, and every client runs the same command: uvx codebase-brain-mcp.

Claude Code

claude mcp add codebase-brain -- uvx codebase-brain-mcp

Cursor: ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project)

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

Claude Desktop: Settings → Developer → Edit Config (claude_desktop_config.json), then restart the app

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

VS Code (GitHub Copilot agent mode): .vscode/mcp.json

{  "servers": {    "codebase-brain": { "type": "stdio", "command": "uvx", "args": ["codebase-brain-mcp"] }  }}

Windsurf: ~/.codeium/windsurf/mcp_config.json. Gemini CLI: ~/.gemini/settings.json. Both use the same mcpServers block as Cursor.

OpenAI Codex CLI

codex mcp add codebase-brain -- uvx codebase-brain-mcp

Tool doesn't start? Desktop apps often don't see your shell's PATH. Run which uvx and put that full path in "command", for example "/Users/you/.local/bin/uvx".

Optional: install the skill. It tells the agent which tool fits which question, to cite every claim, to check history before removing odd code, and to run impact analysis before editing. For Claude Code, run the commands below. Other agents that read SKILL.md files take the same file in their own skills folder.

mkdir -p ~/.claude/skills/codebase-braincurl -fsSL https://raw.githubusercontent.com/Nomannazir/codebase-brain-mcp/main/skills/codebase-brain/SKILL.md \  -o ~/.claude/skills/codebase-brain/SKILL.md

Quick start

uv syncuv run codebase-brain index https://github.com/pallets/itsdangerousuv run codebase-brain search "how is the signature timestamp checked for expiry"

0.0313  src/itsdangerous/timed.py:72-158  method TimestampSigner.unsign0.0311  docs/timed.rst:1-28  code0.0301  src/itsdangerous/timed.py:170-228  class TimedSerializer

Ask why it looks like that. explain_history(symbol="TimestampSigner.unsign") returns its line-by-line history:

src/itsdangerous/timed.py:72-158  3edfbbbc 2022-03-24 handle OverflowError in timed unsign on 32-bit systems  177196d3 2022-03-09 catch OSError on Windows  37f09970 2022-03-08 catching year overflow ValueError  c30678d1 2019-05-31 don't allow timestamps from the future  910a7a94 2020-04-17 datetimes are timezone-aware utc  ...

Use a local checkout instead (for development)

claude mcp add codebase-brain -- uv run --directory /path/to/codebase-brain-mcp codebase-brain

Run it as a remote server (Streamable HTTP)

export CODEBASE_BRAIN_TOKEN="$(python -c 'import secrets; print(secrets.token_urlsafe(32))')"uv run codebase-brain serve --transport streamable-http --host 0.0.0.0 --port 8765

Clients connect to http://<host>:8765/mcp with Authorization: Bearer <token>. GET /healthz is open for load balancers. Remote mode is locked down by default:

• No token, no public port. The server refuses to listen beyond localhost without a token of at least 24 characters. Tokens are compared in constant time.
• Remote clients can't read the server's disk. Only public https:// git URLs can be indexed, not local paths, unless you set CODEBASE_BRAIN_ALLOW_LOCAL_PATHS=1.
• Big repos are refused above CODEBASE_BRAIN_MAX_FILES (default 20,000), and every git command has a timeout.
• DNS-rebinding protection is on for localhost, and for any hosts listed in CODEBASE_BRAIN_ALLOWED_HOSTS.

Docker

docker build -t codebase-brain-mcp .docker run -p 8765:8765 -e CODEBASE_BRAIN_TOKEN="$CODEBASE_BRAIN_TOKEN" -v brain-data:/data codebase-brain-mcp

The image runs as a non-root user and includes the embedding model, so it starts fast and needs no download at runtime. It has a health check, and keeps indexes in the /data volume. Indexing uses about 1.2 GB of memory, so give the container 2 GB.

Configuration

Doc drift, tested honestly

On a well-maintained project (itsdangerous), find_doc_drift reports no false alarms. It only reports three "worth a look" sections whose docs date from 2020 while the code they describe changed in 2024–2025. On docs with planted mistakes, it catches every one: a moved file, a renamed function (with the right suggestion), an unknown setting and flag, a keyword argument the function doesn't take, and an import that would fail. Changelogs are skipped, because they're supposed to mention removed things.

Evaluation

Does search actually put the right code in front of the model? codebase-brain eval answers that with a benchmark. There are two, each with 32 questions pinned to one commit, and each question lists the code or docs a good answer must come from. The questions were written by reading the code before any results were measured, and haven't been changed since.

Python: pallets/itsdangerous

32 questions about pallets/itsdangerous at commit 672971d, in evals/datasets/itsdangerous.toml.

What this shows:

• Hybrid finds a right answer in the top 3 for 88% of questions, against 75% and 72% for either method alone. The gain comes from questions written in plain words and questions about the docs. When the question names the code, every mode finds it.
• It's honest about uncertainty. With 32 questions, the confidence intervals for MRR overlap, so hybrid is better on this set but not yet proven in general. Per question, hybrid beats keyword-only on 8 questions and loses on 4.
• It has known misses. Four questions describing behaviour in very different words from the code don't reach the top 5. They're listed in evals/results/itsdangerous.md and are the next thing to improve. A larger, held-out question set will come first, so any tuning isn't fitted to these 32.

TypeScript: sindresorhus/ky

32 questions about sindresorhus/ky at commit 3541888, in evals/datasets/ky.toml. The readme is one 2,000-line file, so docs questions must find the right section, not just the file.

What this shows:

• Naming the code or asking about the docs works well: 91–100% in the top 5.
• Describing behaviour in plain words is the weak spot (36%). ky has about 25,000 lines of tests next to 5,000 lines of source, and the tests describe the same behaviour in plain words, so they outrank the source. Every miss is listed in evals/results/ky.md.
• Hybrid is not better than vector-only here. The intervals overlap heavily (hybrid beats vector on 5 questions and loses on 9), so neither is proven better. Keyword-only is clearly worst: hybrid beats it on 12 questions and loses on none.
• These results are published as measured. Tuning (for example, ranking source above tests) will be checked against a new held-out set, so it isn't fitted to these questions.

Reproduce either benchmark (the first run downloads the repo and the embedding model):

uv run codebase-brain eval evals/datasets/itsdangerous.toml --out evals/resultsuv run codebase-brain eval evals/datasets/ky.toml --out evals/results

How it's measured:

• Hit@k: a relevant result is in the top k.
• MRR: 1 / rank of the first relevant result.
• nDCG@10: each target is credited once, so duplicate chunks don't inflate the score.
• Confidence intervals: 95% bootstrap over questions, seeded.
• Relevance: a result is relevant if it's in the target file and, when the target names a symbol, is that symbol or one of its methods. A docs target can name a section (FAQ > How do I stop retrying early?), and then that section or one of its subsections counts.
• Dataset rot: the harness fails if a target no longer exists at the pinned commit.

How it works

source ─► resolve (local dir / blobless https clone) ─► list files (.gitignore-aware, skips binaries and lockfiles)       ─► chunk (ast / tree-sitter / headings / windows) ─► embed (fastembed) ─► SQLite: chunks + vectors + FTS5query  ─► BM25 top 50 ┐       ─► vector top 50 ┴─► reciprocal-rank fusion ─► filters ─► cited sources

Security

• Clones are blobless (--filter=blob:none): full history, with file contents fetched only when needed.
• Commit authors are shown by name only; email addresses are never stored or returned.
• Only https:// clone URLs are accepted. Git runs with GIT_ALLOW_PROTOCOL=https:file and no terminal prompts.
• read_lines resolves paths and refuses anything outside the indexed repository.
• Repo names are validated, so they can't escape the index directory.
• All query tools are marked read-only.
• In HTTP mode: a required bearer token (constant-time check), git URLs only, repo size limits, DNS-rebinding protection, and a non-root container.

Development

uv run pytest           # 67 tests, offline (hash embedder, temporary git repos, in-process MCP client)uv run ruff check .     # lintuv run ruff format .    # formatuv run pyright          # types

Roadmap

• Git history and PR discussions: explain_history, search_history
• Symbol references and transitive dependents: impact_of_change
• find_doc_drift: Markdown and reStructuredText, signatures, imports, settings, flags, staleness
• JavaScript and TypeScript (tree-sitter): chunking, references, impact analysis
• More languages (Go, Rust, Java) with tree-sitter
• Retrieval evals with confidence intervals (codebase-brain eval)
• Larger held-out eval set, then retrieval tuning (reranking, query expansion)
• Streamable HTTP with bearer-token auth, Docker image
• PyPI package, MCP Registry listing
• Hosted demo
• OpenTelemetry tracing