CodeSeek: Call Graphs and Hybrid Search as MCP Tools for Claude Code

The gap CodeSeek fills between grep and a full language server

An agent asked to change a function has two bad options by default. It can grep for the name and get every string match in the tree, including comments, tests and unrelated identifiers. Or it can read whole files until it finds the definition. Neither tells it who else depends on the change. CodeSeek targets that specific gap: symbol-level lookup plus call-graph traversal, packaged so an agent can call it as a tool rather than as a shell command it has to construct. The README frames it as a "Code intelligence CLI tool for Claude Code", and the command set backs that framing. callers, callees and callgraph answer structural questions; search answers the looser "where does this concept live" question. The intended user is someone running an agent against a codebase large enough that file reading is wasteful, in one of the seven languages Tree-sitter parsing covers. Anyone working in a single small file does not need it.

What codeseek init actually writes to disk

The indexing pipeline is documented as a linear sequence. Source files go through a Tree-sitter AST parse across seven languages, functions, classes and methods are extracted, texts are embedded in batches of 20 per API call with a SQLite cache in front of them, vectors land in LanceDB, a BM25 index is built in Tantivy, and the call graph is serialized as something the README calls PetCodeGraph. The whole artifact is saved under ~/.codeseek/<project_hash>/. Two details matter more than the rest. First, the cache is keyed so that repeated embeddings of identical text do not hit the API again, which is what makes re-indexing tolerable rather than expensive. Second, the process is described as idempotent: the first run is a full build, and later runs compare MD5 hashes so only changed files are reprocessed. That is a content-hash incremental scheme, not a timestamp one, so a touched-but-unchanged file costs nothing. The README does not state how the project hash is computed, which means you cannot predict the index directory name from the repository path alone; codeseek list exists to resolve that.

Three retrievers, RRF, then a cross-encoder

The search pipeline is the part with the most moving pieces. A query is embedded, then run through three retrievers in parallel: dense search over LanceDB using approximate nearest neighbour, sparse search over Tantivy using BM25, and a graph search over the call graph structure. The three result lists are merged by Reciprocal Rank Fusion, which is documented as producing a top-20 candidate set. Those 20 candidates then go to a cross-encoder reranker, named in the diagram as Qwen3-Reranker, which scores each query and code pair jointly. The final output is top-5 by default, or top-N. The ranking logic here is standard for a hybrid retrieval stack, and the choice to fuse by rank rather than by score avoids the problem of comparing a cosine distance against a BM25 score on incompatible scales. What the README does not give is any statement about latency for the reranker stage, which is the expensive one, since a cross-encoder runs a forward pass per candidate rather than one pass for the whole corpus. Treat the "Fast" labels in the stage table as applying to the retrievers, not to the rerank.

Getting it running: npm, Homebrew, or build.sh

The primary path is npm install -g codeseek. The npm package is a JavaScript wrapper that runs a first-run wizard prompting for an embedding API token, model and base URL, downloads the matching Rust binary from GitHub Releases, and forwards every subsequent command to that binary. The wizard matters because the embedding model is an API dependency, not a bundled local model; without a token the index cannot be built. Homebrew is the second route, via brew tap CodeBendKit/codeseek followed by brew install codeseek. Building from source requires protoc first (brew install protobuf on macOS, sudo apt install protoc on Ubuntu), then git clone, cd codeseek, and ./build.sh --release, which compiles the TypeScript wrapper into dist/ alongside the Rust binary and installs to ~/.codeseek/bin/. Supported platforms are listed as macOS arm64 and x64, and Linux x64. Windows is absent from that table. After setup, the working sequence is codeseek init, then codeseek install to register MCP tools, then codeseek install-hooks if you want post-commit and post-merge re-indexing. All query commands accept --json.

The five MCP tools and where their config lands

codeseek install writes MCP server configuration to one of three files depending on the target: ~/.claude.json for global Claude Code use across all projects, ./.mcp.json for project-local Claude Code use, or ~/.codex/config.toml for Codex CLI. Claude Code is documented as auto-discovering the tools after a restart, and the README names five: codeseek_search, codeseek_callers, codeseek_callees, codeseek_callgraph and codeseek_status. The server itself runs as codeseek serve --mcp over stdio JSON-RPC, which is what Claude Code invokes internally. The practical consequence of the global-versus-local split is that a global install points every project at whatever index exists for that project's hash, so a repository you never ran codeseek init in will return nothing useful. The project-local .mcp.json avoids that ambiguity at the cost of a file in your repository. codeseek uninstall reverses the registration; codeseek uninit deletes only the current project's index.

Where the design strains: API dependency, Windows, and a thin CLI contract

The embedding API is the sharpest constraint. Indexing requires a reachable embedding endpoint and a token, so air-gapped environments and CI runners without egress cannot build an index at all. The SQLite cache softens repeat cost but does nothing for the first build of a large repository, where every function body is a new text to embed. The second constraint is platform coverage: macOS arm64, macOS x64 and Linux x64 only. If your team develops on Windows, the documented install paths do not reach you. Third, the CLI surface is documented as a command table rather than a configuration reference. There is no documented config file format, so the embedding settings captured by the wizard appear to live in whatever state the wrapper maintains, and there is no documented way to set them non-interactively for a scripted install. That is a real obstacle for anyone trying to bake codeseek init into a container build. Finally, the version history supplied runs v0.1.29 through v0.1.31 across roughly three weeks, which is a normal cadence for a young tool and also a reason to expect command or output changes between upgrades.

How it differs from an LSP-based or pure-embedding approach

The obvious comparison is a language server. An LSP gives exact, compiler-accurate definitions and references, because it resolves types and scopes rather than matching names. CodeSeek parses with Tree-sitter, which is fast and language-agnostic but syntactic: it sees the shape of the AST, not the result of name resolution. That trade is deliberate and it buys coverage. One index format works across seven languages instead of requiring a separate server per language, and the same index feeds the semantic search path, which an LSP cannot do at all. The other comparison is a plain vector store over code chunks. That approach answers "find code like this query" and nothing else. CodeSeek's call graph is a separate retriever feeding the same RRF fusion, so a query that matches a symbol name can surface results the embedding model would rank poorly, and codeseek callers answers questions no embedding index can. The README's own example query, "how the code embedding work", returns get_embedding at 0.7973 followed by EmbeddingService at 0.2855 and three more results below 0.15, which shows the fusion working on a natural-language query but also shows how steeply the scores fall after the first hit.

Maintenance cost and the MIT licence in practice

Ongoing cost has three components. The embedding API bill scales with how much code changes, since only changed files are re-embedded after the first build. The reranker adds per-query compute on top of that. And the index itself lives outside your repository in ~/.codeseek/<project_hash>/, so it is machine-local state that a fresh clone or a new CI machine does not inherit; every new environment pays a full build. The git hooks installed by codeseek install-hooks run codeseek init on post-commit and post-merge, which keeps the index current but also means every commit triggers MD5 comparison across the tree. The project is MIT licensed, which permits commercial and closed-source use and modification, and requires that the copyright notice and permission notice be preserved in copies or substantial portions. That is the extent of what the repository metadata supports saying here; it is not legal advice, and if you are vendoring the binary or the wrapper into a distributed product, read the LICENSE file itself rather than this summary.

Editorial conclusion

Adopt CodeSeek if your agent workflow is already Claude Code or Codex CLI and your questions are symbol-shaped: who calls this, what does this call, where is the embedding code. Do not adopt it if you need offline indexing, Windows support, or a stable CLI contract, because the README documents no config-file format, no Windows build and version numbers still in the 0.1.x range. Before committing, run codeseek status after codeseek init on your largest repository and check the reported function and file counts against what you expect, then run codeseek install and confirm the five tools appear in Claude Code after a restart.

Official sources

1. CodeBendKit/codeseek on GitHub
2. Issues
3. License: MIT
4. README
5. Releases