Skip to main content
Glama
DeusData

codebase-memory-mcp

by DeusData
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

codebase-memory-mcp

GitHub Release License CI Tests Languages Hybrid LSP Agents Pure C Platform OpenSSF Scorecard SLSA 3 VirusTotal arXiv

The fastest and most efficient code intelligence engine for AI coding agents. Full-indexes an average repository in milliseconds, the Linux kernel (28M LOC, 75K files) in 3 minutes. Answers structural queries in under 1ms. Ships as a native executable with a small verified runtime-asset set for macOS, Linux, and Windows — download, run install, done.

High-quality parsing through tree-sitter AST analysis across all 162 languages, enhanced with Hybrid LSP semantic type resolution for Python, TypeScript / JavaScript / JSX / TSX, PHP, C#, Go, C, C++, Java, Kotlin, Rust, and Perl — producing a persistent knowledge graph of functions, classes, call chains, HTTP routes, and cross-service links. 17 MCP tools. No language runtime, hosted service, or API key. Plug and play across 45 supported automatic/conditional client surfaces.

Research — The design and benchmarks behind this project are described in the preprint Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP (arXiv:2603.27277). Evaluated across 31 real-world repositories: 83% answer quality, 10× fewer tokens, 2.1× fewer tool calls vs. file-by-file exploration.

Security & Trust — This tool reads your codebase and writes to your agent configuration files. That is what it is designed to do. If you prefer to audit before running, the full source is here. For each release product, three behaviourally identical executable candidates (unstripped, debug-stripped, stripped) are submitted to VirusTotal before testing; the selected candidate is then packaged with its SHA-256 unchanged. Release notes link every measured candidate result. Publication permits only the narrowly documented single-Microsoft !ml tolerance in SECURITY.md. All processing happens 100% locally; your code never leaves your machine. Found a security issue? We want to know — see SECURITY.md. Security is Priority #1 for us.

Why codebase-memory-mcp

  • Extreme indexing speed — Linux kernel (28M LOC, 75K files) in 3 minutes. RAM-first pipeline: LZ4 compression, in-memory SQLite, fused Aho-Corasick pattern matching. Memory released after indexing.

  • Plug and play — native executable plus authenticated release-owned assets for macOS (arm64/amd64), Linux (arm64/amd64), and Windows (amd64). The native install needs no Docker, language runtime, or API keys. Download → install → restart agent → done.

  • 162 languages — vendored tree-sitter grammars compiled into the binary. Nothing to install, nothing that breaks.

  • 120x fewer tokens — 5 structural queries: ~3,400 tokens vs ~412,000 via file-by-file search. One graph query replaces dozens of grep/read cycles.

  • 45 supported automatic/conditional client surfaces — install configures detected clients and safely activates conditional clients only when their documented platform, marker, or explicit existing config path is present. See Multi-Agent Support for the complete matrix and manual/UI-only boundaries.

  • Built-in graph visualization — 3D interactive UI at localhost:9749, served from the binary itself.

  • Infrastructure-as-code indexing — Dockerfiles, Kubernetes manifests, and Kustomize overlays indexed as graph nodes with cross-references. Resource nodes for K8s kinds, Module nodes for Kustomize overlays with IMPORTS edges to referenced resources.

  • 17 MCP tools — search, trace, architecture, impact analysis, targeted index-coverage checks, Cypher queries, dead code detection, cross-service HTTP linking, ADR management, and more.

Related MCP server: Orihime

Quick Start

One-line install (macOS / Linux):

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

With graph visualization UI:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Windows (PowerShell):

# 1. Download the installer
Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1

# 2. (Optional but recommended) Inspect the script
notepad install.ps1

# 3. Unblock the downloaded file (removes Mark-of-the-Web restriction added by browsers/Invoke-WebRequest)
Unblock-File .\install.ps1

# 4. Run it
.\install.ps1

Note: If you see a script execution policy error, run Set-ExecutionPolicy -Scope Process Bypass first, or invoke with PowerShell -ExecutionPolicy Bypass -File .\install.ps1.

Options: --skip-config (binary only, no agent setup), --dir=<path> (custom location).

Antivirus note: Microsoft Defender may flag a release binary as Trojan:Script/Wacatac.B!ml. This is a known false positive — typically 61 of ~62 engines return clean, and the same detection family hits gh, llama.cpp, Godot and Microsoft's own Go toolchain. See Antivirus False Positives for the evidence, how to verify the artifacts yourself, and how to report it if you think we are wrong.

Restart your coding agent. Say "Index this project" — done.

  1. Download the archive for your platform from the latest release:

    • codebase-memory-mcp-<os>-<arch>.tar.gz (macOS/Linux) or .zip (Windows)

  2. Extract and install (each archive includes install.sh or install.ps1):

    macOS / Linux:

    tar xzf codebase-memory-mcp-*.tar.gz
./install.sh

    Windows (PowerShell):

    Expand-Archive codebase-memory-mcp-windows-amd64.zip -DestinationPath .
Unblock-File .\install.ps1
.\install.ps1

  3. Restart your coding agent.

The install command automatically strips macOS quarantine attributes and ad-hoc signs the binary — no manual xattr/codesign needed.

The install command auto-detects installed coding agents and configures their documented MCP entries plus durable instructions, skills, and lifecycle hooks where supported.

Session Coordination Daemon

CBM automatically shares one per-account coordination daemon across Claude Code, Codex, OpenCode, and every other configured client. There is no opt-in setting for MCP servers or hook clients: the first daemon-backed CBM session starts it, each session registers its own work, and the final session shuts it down. The daemon owns long-lived background services such as watchers, shared indexing jobs, and the optional UI. Closing one session cancels work owned only by that session, while work still needed by another session continues.

The detached daemon does not depend on an MCP frontend's stderr. It keeps owner-only durable records under the canonical ${CBM_CACHE_DIR}/logs directory (default ~/.cache/codebase-memory-mcp/logs):

File

Contents

cbm-daemon.log

Daemon lifecycle, watcher/indexing, UI, resource, and error events.

daemon-conflicts.ndjson

Exact-build, coordination-ABI, and cache-root admission conflicts.

activation-events.ndjson

Install/update/uninstall activation progress and outcomes.

Thin frontends still write immediate startup and session-specific errors to their own stderr; MCP JSON-RPC stdout remains clean.

All active CBM processes must run the exact same version, executable build, coordination ABI, and canonical cache root. Equivalent CBM_CACHE_DIR aliases resolve to the same root; a genuinely different root is rejected while any CBM process is active. MCP servers, hooks, one-shot CLI commands, temporary index workers, and the daemon share a crash-safe OS admission barrier; starting an ordinary conflicting process fails before doing work and records an explicit conflict in ${CBM_CACHE_DIR}/logs/daemon-conflicts.ndjson.

The native install, update, and uninstall commands are the deliberate exception to that conflict rule. Download, verification, and private same-filesystem staging happen first so a bad candidate never disrupts active work. Activation then publishes account-wide maintenance intent, asks the daemon and every temporary local operation to cancel, and waits to a finite deadline for all coordinated CBM processes to exit. It holds the admission and lifetime barriers exclusively while changing the active binary, configuration, PATH, or indexes. New CBM work cannot enter during this window. Activation progress and results are recorded in ${CBM_CACHE_DIR}/logs/activation-events.ndjson, and a successful command tells you to restart open coding-agent sessions so they launch the activated build.

Package-manager setup (npm, PyPI, or Go) verifies and publishes a coherent private cached runtime set. Sidecars are replaced before the executable with per-file atomic renames; an interrupted multi-file publication is detected and repaired on the next launch rather than being described as one crash-atomic filesystem transaction. It does not replace the active native installation and therefore does not stop running CBM sessions. When that cached binary is executed, it still enters the same exact-build admission barrier. The shell and PowerShell installers invoke the verified candidate's native install command, so they do receive the full account-wide activation guarantee.

The ordinary cli mode is intentionally separate: it runs one command locally and never starts or connects to the coordination daemon, registers a daemon session, or starts watchers/UI. Its only shared state is the OS admission barrier plus per-project locks for graph mutations. While the command is running, a temporary monitor lets activation cancel that operation and its supervised worker safely; the monitor exits with the command and never becomes a standing daemon. See CLI Mode for details.

Graph Visualization UI

The graph UI is built into the binary — every install on every channel has it. Then run it:

codebase-memory-mcp --ui=true --port=9749

Open http://localhost:9749 in your browser. The UI is owned by the shared coordination daemon, so concurrent agent sessions do not start duplicate HTTP servers.

Auto-Index

Enable automatic indexing on MCP session start:

codebase-memory-mcp config set auto_index true

When enabled, new projects are indexed automatically on first connection. Previously-indexed projects are registered with the background watcher for ongoing git-based change detection. Configurable file limit: config set auto_index_limit 50000.

Watcher registration is controlled separately by auto_watch (default true). Set config set auto_watch false to keep a session from registering its project with the background watcher — useful when working across many projects and you want each session contained to explicit indexing.

To turn the watcher off entirely, set config set watcher_enabled false (default true): the background poll thread never starts and no project is registered, while auto_index and manual index_repository keep working. Unlike auto_watch — which is consulted per session — watcher_enabled is read once when the background daemon starts, so run codebase-memory-mcp daemon stop after changing it; reconnecting your MCP client alone will not restart the daemon. See docs/CONFIGURATION.md.

Keeping Up to Date

Updates run from the install script on every platform, not from inside the running binary. codebase-memory-mcp update validates your flags and then prints the exact command to run:

# macOS / Linux
bash "<install-dir>/install.sh"
# Windows
powershell -ExecutionPolicy Bypass -File "<install-dir>\install.ps1"

The install script is placed next to the binary at install time, so the printed path resolves beside the executable. It is idempotent, so re-running it is the update: it stops the daemon, retires the running binary, installs the new one, and cleans up.

Why it works this way. On Windows it is a hard requirement — a running executable cannot replace its own image, so the swap has to happen from a process that is not the binary being replaced. On macOS and Linux it is a deliberate choice: an in-process updater is structurally a downloader (fetch an archive, verify it, unpack it, mark a file executable, run it), and shipping that composite in every binary to serve a command most people run a handful of times is a poor trade. The release archives now carry no download URLs at all, and cbm makes no network request of its own accord — it does not check for new versions in the background, and nothing phones home. You find out about releases from the install script, your package manager, or GitHub.

If PowerShell refuses to run the script because the file came from the internet, Unblock-File it first.

Installed through npm or pip? Update with your package manager on every platform (npm install -g codebase-memory-mcp@latest / pip install -U codebase-memory-mcp).

Uninstall

codebase-memory-mcp uninstall

Removes owned agent config entries, skills, hooks, instructions, and the installed binary. Existing graph indexes are listed and deleted only after confirmation.

The install script placed beside the binary is reported, not deleted — uninstall prints its path and the rm command for it. It is left alone on purpose: it may be your own copy, a symlink into a checkout, or managed by a package manager, and an uninstaller should not delete a file it cannot prove it owns.

Features

Graph & analysis

  • Architecture overview: get_architecture returns languages, packages, entry points, routes, hotspots, boundaries, layers, and clusters in a single call

  • Architecture Decision Records: manage_adr persists architectural decisions across sessions

  • Louvain community detection: Discovers functional modules by clustering call edges

  • Git diff impact mapping: detect_changes maps uncommitted changes to affected symbols with risk classification

  • Call graph: Resolves function calls across files and packages (import-aware, type-inferred)

  • Dead code detection: Finds functions with zero callers, excluding entry points

  • Cypher-like queries: MATCH (f:Function)-[:CALLS]->(g) WHERE f.name = 'main' RETURN g.name

Search

  • Semantic search (semantic_query): vector search across the entire graph, powered by bundled Nomic nomic-embed-code embeddings (40K tokens, 768d int8) compiled into the binary — no API key, no Ollama, no Docker. 11-signal combined scoring (TF-IDF, RRI, API/Type/Decorator signatures, AST profiles, data flow, Halstead-lite, MinHash, module proximity, graph diffusion).

  • BM25 full-text search via SQLite FTS5 with cbm_camel_split tokenizer (camelCase / snake_case aware)

  • Structural search (search_graph): regex name patterns, label filters, min/max degree, file scoping

  • Code search (search_code): graph-augmented grep over indexed files only

Cross-service linking

  • HTTP route ↔ call-site matching with confidence scoring

  • gRPC, GraphQL, tRPC service detection with protobuf Route extraction

  • Channel detection (EMITS / LISTENS_ON) for Socket.IO, EventEmitter, and generic pub-sub patterns across 8 languages with constant resolution

Cross-repo intelligence

  • CROSS_* edges link nodes across multiple repos indexed under the same store

  • Multi-galaxy 3D UI layout for cross-repo architecture visualization

  • Cross-repo architecture summary combining services, routes, and dependencies across the indexed fleet

Edge types (selected)

  • CALLS — a callable is invoked at the source site

  • CALL_REFERENCE — a callable is used at a supported reference site (for example, a direct value argument) and resolves to one exact target

  • USAGE — an identifier is used, but a unique callable target is not proven (including ambiguous or complex expressions)

  • IMPORTS, DEFINES, IMPLEMENTS, INHERITS

  • HTTP_CALLS, ASYNC_CALLS (cross-service)

  • EMITS, LISTENS_ON (channels)

  • DATA_FLOWS with arg-to-param mapping + field access chains

  • SIMILAR_TO (MinHash + LSH near-clone detection, Jaccard scored)

  • SEMANTICALLY_RELATED (vocabulary-mismatch, same-language, score ≥ 0.80)

Indexing pipeline

  • 158 vendored tree-sitter grammars compiled into the binary

  • Generic package / module resolution — bare specifiers like @myorg/pkg, github.com/foo/bar, use my_crate::foo resolved via manifest scanning (package.json, go.mod, Cargo.toml, pyproject.toml, composer.json, pubspec.yaml, pom.xml, build.gradle, mix.exs, *.gemspec)

  • Infrastructure-as-code indexing — Dockerfiles, Kubernetes manifests, Kustomize overlays as graph nodes

  • Hybrid LSP semantic type resolution for Python, TypeScript / JavaScript / JSX / TSX, PHP, C#, Go, C, C++, Java, Kotlin, Rust, and Perl — a lightweight C implementation of language type-resolution algorithms, structurally inspired by and compatible with major language servers including tsserver / typescript-go, pyright, gopls, Roslyn, Eclipse JDT, and rust-analyzer (parameter binding, return-type inference, generic substitution, JSX component dispatch, JSDoc inference for plain JS files, namespace + trait + late-static-binding resolution for PHP, file-scoped namespaces + records + LINQ method syntax for C#, class-hierarchy + overload + lambda resolution for Java, extension-function + scope-function resolution for Kotlin, trait-method + UFCS resolution for Rust)

  • RAM-first pipeline: LZ4 compression, in-memory SQLite, single dump at end. Memory released after.

Distribution & operation

  • Native runtime set, zero infrastructure services: SQLite-backed, persists to ~/.cache/codebase-memory-mcp/

  • Auto-sync: Background watcher detects file changes and re-indexes automatically

  • Route nodes: REST endpoints are first-class graph entities

  • CLI mode: codebase-memory-mcp cli search_graph '{"project": "my-project", "name_pattern": ".*Handler.*"}'

  • Available on: npm, PyPI, Homebrew, Scoop, Winget, Chocolatey, AUR, go install

Team-Shared Graph Artifact

Commit a single compressed file to your repo and your teammates skip the reindex.

.codebase-memory/graph.db.zst is a zstd-compressed snapshot of the knowledge graph that lives next to your source. When you index, the artifact is written or refreshed; when a teammate clones the repo and runs codebase-memory-mcp for the first time, the artifact is decompressed and incremental indexing fills in their local diff.

  • Format: SQLite database, indexes stripped, VACUUM INTO compacted, then zstd 1.5.7 compressed (8–13:1 ratio typical)

  • Two tiers:

    • Best (zstd -9 + index strip + VACUUM INTO) — written on explicit index_repository

    • Fast (zstd -3) — written by the watcher for low-latency incremental updates

  • Bootstrap: when no local DB exists but the artifact is present, index_repository imports the artifact first, then runs incremental indexing — avoiding the full reindex cost

  • No merge pain: a .codebase-memory/.gitattributes line with merge=ours is auto-created on first export, so concurrent edits don't produce conflicts on the binary artifact

  • Commit it deliberately: the artifact is rewritten on every index, including the watcher's Fast tier, and git stores each rewrite as a full new blob. Committing every refresh is what turns a 20 MB file into gigabytes of history — one team reached ~6 GB across ~350 commits of this single path. Pick a cadence (a release, a milestone, a nightly job) rather than committing every save.

  • Git LFS, if it must move on every commit: track it from the repo-root .gitattributes and leave the auto-created .codebase-memory/.gitattributes in place — the nearer file goes on supplying merge=ours, and only filter comes from the root:

    .codebase-memory/graph.db.zst filter=lfs diff=lfs merge=lfs -text

    Track only the .zst; artifact.json is small and carries the schema version. The attribute applies to future commits only, so a repo that already has the blobs in history needs git-filter-repo to rewrite them first. Two costs to weigh before adopting it: GitHub meters LFS storage and bandwidth, and its objects cannot be pruned without contacting support; and every teammate needs git lfs install — without it their checkout leaves a pointer file where the artifact should be, the integrity-checked import refuses it, and they fall back to a full reindex.

  • Optional: never committed unless you want it. Add .codebase-memory/ to .gitignore if you prefer everyone to reindex from scratch.

The result is similar in spirit to graphify's graphify-out/ directory, but as a single compressed file with explicit two-tier export, integrity-checked import, and zero merge friction.

How It Works

codebase-memory-mcp is a structural analysis backend — it builds and queries the knowledge graph. It does not include an LLM. Instead, it relies on your MCP client (Claude Code, or any MCP-compatible agent) to be the intelligence layer.

You: "what calls ProcessOrder?"

Agent calls: trace_path(function_name="ProcessOrder", direction="inbound")

codebase-memory-mcp: executes graph query, returns structured results

Agent: presents the call chain in plain English

Why no built-in LLM? Other code graph tools embed an LLM for natural language → graph query translation. This means extra API keys, extra cost, and another model to configure. With MCP, the agent you're already talking to is the query translator.

Performance

Benchmarked on Apple M3 Pro:

Operation

Time

Notes

Linux kernel full index

3 min

28M LOC, 75K files → 4.81M nodes, 7.72M edges

Linux kernel fast index

1m 12s

1.88M nodes

Django full index

~6s

49K nodes, 196K edges

Cypher query

<1ms

Relationship traversal

Name search (regex)

<10ms

SQL LIKE pre-filtering

Dead code detection

~150ms

Full graph scan with degree filtering

Trace call path (depth=5)

<10ms

BFS traversal

RAM-first pipeline: All indexing runs in memory (LZ4 HC compressed read, in-memory SQLite, single dump at end). Memory is released back to the OS after indexing completes.

Token efficiency: Five structural queries consumed ~3,400 tokens via codebase-memory-mcp versus ~412,000 tokens via file-by-file grep exploration — a 99.2% reduction.

To measure comparable quality, latency, and agent-efficiency metrics on your own workload, see Measuring quality, latency, and agent savings. Exact reproduction of the figures above requires the original inputs and raw artifacts.

Troubleshooting & Diagnostics

codebase-memory-mcp runs 100% locally and collects no telemetry — your code, queries, environment, and usage never leave your machine. That privacy guarantee also means that when you hit something we can't reproduce on our side (a slow memory climb over hours, a performance regression, a leak that only appears after days of real use), we have no data at all unless you choose to send it. Here is how to capture it yourself.

Capture a diagnostics log

Set CBM_DIAGNOSTICS=1 before the first daemon-backed MCP session starts, then reproduce the problem (let it run as long as it takes — a slow leak needs time to show in the trend). The shared daemon captures this setting from the session that starts it. If it is already running, close all daemon-backed sessions so it exits before changing the setting. The daemon creates a fresh owner-private cbm-diagnostics-<pid>-<random> directory below the system temp directory ($TMPDIR or /tmp on macOS/Linux, %TEMP% on Windows). The exact paths are recorded by the diagnostics.start event in ${CBM_CACHE_DIR}/logs/cbm-daemon.log:

File

What it is

trajectory.ndjson

The memory trajectory — one JSON line every 5 s with rss, committed (Windows commit charge), peak_*, page_faults, fd, and queries. This is the file we need for memory/leak reports — the trend over time is what pinpoints a leak. It is kept on disk after the server exits (so you can grab it post-mortem) and rotates to trajectory.ndjson.1 past ~8 MB.

snapshot.json

The latest snapshot only — handy for a quick live check. Removed on clean exit.

The private randomized directory prevents another local account from pre-placing a link or special file at a predictable diagnostics path. Its <pid> component is the shared daemon's process ID, also recorded by the daemon.start event. Set the variable consistently in the env block of each agent's MCP server config, or export it before launching the first session.

What to share

When you open a memory/performance issue, attach the .ndjson trajectory — it contains no source code or query text, only resource counters. If you'd rather not attach a file, paste it (or an agent's summary of it) into the issue: your assistant can read the NDJSON directly and report whether rss/committed grow monotonically, how fast, and relative to query count — which is exactly what we need to find the cause.

Installation

Pre-built Binaries

Platform

Archive

macOS (Apple Silicon)

codebase-memory-mcp-darwin-arm64.tar.gz

macOS (Intel)

codebase-memory-mcp-darwin-amd64.tar.gz

Linux (x86_64)

codebase-memory-mcp-linux-amd64.tar.gz

Linux (ARM64)

codebase-memory-mcp-linux-arm64.tar.gz

Windows (x86_64)

codebase-memory-mcp-windows-amd64.zip

Every release includes checksums.txt with SHA-256 hashes. The executable is self-contained — no adjacent data file is required. Linux -portable archives contain the fully static builds; ordinary platform archives use their native system ABI.

Windows note: SmartScreen may show a warning for unsigned software. Click "More info" → "Run anyway". Verify integrity with checksums.txt.

Setup Scripts

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/scripts/setup.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/scripts/setup-windows.ps1 | iex

AUR (Arch Linux)

yay -S codebase-memory-mcp-bin
paru -S codebase-memory-mcp-bin

The codebase-memory-mcp-bin package is available at: https://aur.archlinux.org/packages/codebase-memory-mcp-bin

Nix (flake)

The flake exposes two server packages plus the standalone frontend:

Package

Contents

default (codebase-memory-mcp)

Standard server, no UI

codebase-memory-mcp-ui

Server with the graph UI embedded (--ui=true works)

graph-ui

Just the built frontend assets (dist/)

Run directly without installing:

# Standard server
nix run github:DeusData/codebase-memory-mcp

# Server with the embedded graph UI
nix run github:DeusData/codebase-memory-mcp#codebase-memory-mcp-ui -- --ui=true --port=9749
# then open http://127.0.0.1:9749

Or build a binary into ./result/bin/codebase-memory-mcp:

nix build github:DeusData/codebase-memory-mcp                          # standard
nix build github:DeusData/codebase-memory-mcp#codebase-memory-mcp-ui   # with UI

Working in a clone? Use . in place of the flake URL, e.g. nix run .#codebase-memory-mcp-ui -- --ui=true, or drop into a shell that puts the binary on PATH with nix shell .#codebase-memory-mcp-ui.

Note: launched by hand (not from an MCP client) the server exits as soon as stdin closes — that's normal MCP behaviour. Keep stdin open while testing the UI, e.g. sleep infinity | codebase-memory-mcp --ui=true --port=9749. The codebase-memory-mcp-ui package embeds the UI at build time; nix run'ing the standard default package with --ui=true will refuse to start the HTTP server.

Install via Claude Code

You: "Install this MCP server: https://github.com/DeusData/codebase-memory-mcp"

Build from Source

Requirement

Check

Install

C compiler (gcc or clang)

gcc --version or clang --version

macOS: xcode-select --install, Linux: apt install build-essential

C++ compiler

g++ --version or clang++ --version

Same as above

zlib

—

macOS: included, Linux: apt install zlib1g-dev

Git

git --version

Pre-installed on most systems

git clone https://github.com/DeusData/codebase-memory-mcp.git
cd codebase-memory-mcp
scripts/build.sh --with-ui          # the shipped composition (graph UI embedded)
scripts/build.sh                    # without the UI (development only)
# Binary at: build/c/codebase-memory-mcp   (codebase-memory-mcp.exe on Windows)

Every platform ships one self-contained executable: the graph UI and the agent integration templates are linked into the binary, so an extracted archive is immediately complete.

Run the test suite (8,060 tests across 141 suites):

scripts/test.sh                     # full: clean sanitizer build + all suites + guards
scripts/test.sh --suites <name>     # one suite, incremental, seconds
build/c/test-runner --list-suites   # what is available

scripts/test.sh is the same entry the CI gates run, so a local pass means the same thing a CI pass does. The canonical local artifact-flow check builds both stripped/unstripped candidates, defaults to the stripped candidate for this explicitly unscanned local run, packages those exact bytes, extracts the archive, and smokes it:

scripts/ci/smoke-artifact.sh <linux|darwin|windows> <amd64|arm64>

scripts/package-release.sh is intentionally a lower-level immutable boundary: it accepts only an already-final --selected-binary plus its --expected-sha256; it never builds, strips, signs, or relinks the executable.

Manual MCP Configuration

Add to ~/.claude.json (user scope) or project .mcp.json:

{
  "mcpServers": {
    "codebase-memory-mcp": {
      "command": "/path/to/codebase-memory-mcp",
      "args": []
    }
  }
}

Restart your agent. Verify with /mcp — you should see codebase-memory-mcp with 17 tools.

Multi-Agent Support

install configures 45 client surfaces: 39 detected automatically and 6 conditional or explicit. “Conditional” means the installer writes only when the documented platform or an explicit, already-existing config path proves the target is active. It never flips experimental feature flags, enables plugins, YOLO modes, global permission bypasses, or third-party instruction trust.

Where a client has a documented custom-agent format, the installer creates three exact-owned definitions from one canonical contract:

  • Scout (Tier 1) — about 3–4 narrow calls for fast positive, provisional discovery; no absence, exhaustive-impact, or dead-code claims.

  • Verify (Tier 2, default) — task-directed graph evidence, exact source checks, path coverage for every cited file, and scope coverage before negative claims.

  • Auditor (Tier 3) — bounded scope, current index generation, complete relevant pagination, broader relationship checks, and explicit unresolved limitations.

Every direct tier batches check_index_coverage for its evidence paths and reads flagged ranges or skipped/excluded files directly. A clean coverage result means only “no recorded gap,” never proof of completeness. Clients without safe child MCP access receive the same three tiers as parent-handoff agents; the parent must supply project, generation, pagination state, graph evidence, and coverage results. Updates migrate only byte-identical prior Verify definitions and never overwrite user-modified agents.

Agent

Activation

MCP config

Durable context / augmentation

Claude Code

Detected

~/.claude.json

Skill + three exact-tool graph agents; SessionStart, SubagentStart, non-blocking PreToolUse for Grep/Glob/Bash, and post-Read coverage

Codex CLI

Detected

$CODEX_HOME/config.toml

Managed AGENTS.md activation pointer, skill, three read-only agents; SessionStart + SubagentStart

Gemini CLI

Detected

.gemini/settings.json

GEMINI.md, three explicit read/graph-tool subagents; BeforeTool, AfterTool read_file coverage, and SessionStart

Zed

Detected

platform settings.json (JSONC)

AGENTS.md + shared skill

OpenCode

Detected

$OPENCODE_CONFIG or resolved global config

AGENTS.md, skill, three deny-by-default read-only agents; plugin adds grep/glob graph lookup, post-read coverage, first-tool-result session context, and post-compaction reinjection

Antigravity

Detected

.gemini/config/mcp_config.json

.gemini/GEMINI.md

Aider

Detected

—

CONVENTIONS.md via .aider.conf.yml

KiloCode

Detected

.config/kilo/kilo.jsonc

Rule + three graph-tool subagents with deny-by-default permissions

VS Code

Detected

platform Code/User/mcp.json

~/.copilot/skills, three read-only agents, sessionStart + subagentStart

Cursor

Detected

.cursor/mcp.json

Skill + three read-only parent-handoff agents; context hooks withheld because session injection races and readonly blocks MCP

Windsurf

Detected

~/.codeium/windsurf/mcp_config.json

Always-on global_rules.md

Augment / Auggie

Detected

~/.augment/settings.json

Rule, three read-only handoff subagents, SessionStart + post-view coverage

OpenClaw

Detected

$OPENCLAW_CONFIG_PATH or state openclaw.json

Active-workspace AGENTS.md + TOOLS.md; compaction reinjection

Kiro

Detected

$KIRO_HOME/settings/mcp.json

Steering, skill, three JSON agents with isolated Scout/Analysis-profile MCP and explicit graph-tool selectors (includeMcpJson: false)

Junie

Detected

.junie/mcp/mcp.json

Skill + three graph subagents for EAP-capable builds; Scout and Analysis server aliases hard-limit the tier tool surfaces; no ineffective EAP SessionStart hook

Hermes

Detected

$HERMES_HOME/config.yaml

Skill + fail-open pre_llm_call context augmentation

OpenHands

Detected

.openhands/mcp.json

Shared .agents/skills/codebase-memory/SKILL.md

Cline

Detected

~/.cline/mcp.json + ${CLINE_DATA_DIR:-~/.cline/data}/settings/cline_mcp_settings.json

Rule + skill; automatic file hooks withheld because they auto-activate and their output is not reliably consumed; child agents cannot use MCP

Warp

Detected, skill only

UI, Warp Drive, or per invocation (manual)

Shared ~/.agents/skills/codebase-memory/SKILL.md

Qwen Code

Detected

.qwen/settings.json

QWEN.md, skill, three explicit read/graph-tool agents; SessionStart, SubagentStart, and post-ReadFile coverage

GitHub Copilot CLI

Detected

$COPILOT_HOME/mcp-config.json

Instructions, skill, three read-only agents; sessionStart + subagentStart

Factory Droid

Detected

.factory/mcp.json

AGENTS.md, skill, three droids with exact per-tier graph-tool lists (without additive whole-server exposure); SessionStart + post-Read coverage on macOS/Linux, withheld on Windows

Crush

Detected

.config/crush/crush.json

Managed context path with explicit parent-to-child handoff

Goose

Detected

.config/goose/config.yaml

.goosehints

Mistral Vibe

Detected

$VIBE_HOME/config.toml

AGENTS.md, skill, and three matched agent/prompt pairs with explicit read-only graph-tool allowlists

Grok Build

Detected

$GROK_HOME/config.toml

Owned rules/codebase-memory.md, skill, three graph agents with named-server mcpInheritance and exact server__tool dispatcher ids; context hooks withheld because its passive hook events discard stdout

Qoder CLI

Detected

~/.qoder/settings.json

Skill, three directly MCP-attached agents with named-server scoping and exact per-tier graph-tool lists; SessionStart, SubagentStart, and post-Read coverage, including documented PowerShell execution on Windows

Kimi Code CLI

Detected

$KIMI_CODE_HOME/mcp.json (default ~/.kimi-code)

Same-root AGENTS.md + skill; fail-open UserPromptSubmit hook in config.toml

GitLab Duo CLI

Detected

$GLAB_CONFIG_DIR/duo/mcp.json or platform fallback

Fail-open user SessionStart on macOS/Linux; hook withheld on Windows; no experimental global skill enablement

Rovo Dev CLI

Detected

configured override or ~/.rovodev/mcp.json

Global AGENTS.md, skill + three read-only handoff subagents; no undocumented hook

Amp

Detected

~/.config/agents/skills/codebase-memory/mcp.json

Colocated skill + ~/.config/amp/AGENTS.md; no plugin

Devin CLI / Local

Detected

~/.config/devin/config.json (platform app-data path on Windows)

Same-root AGENTS.md + skill; macOS/Linux UserPromptSubmit + PostCompaction, and SessionStart only when Claude does not already provide it; hooks withheld on Windows

Tabnine

Detected

~/.tabnine/mcp_servers.json

MCP only; no experimental/YOLO setting

Continue / cn

Conditional

Existing ~/.continue/config.yaml or $CBM_CONTINUE_CONFIG_PATH

MCP only

Visual Studio

Conditional, Windows

~/.mcp.json

MCP only

TRAE

Conditional

Existing $CBM_TRAE_CONFIG_PATH

MCP only

Roo Code

Conditional

Existing $CBM_ROO_CONFIG_PATH

MCP only

Amazon Q Developer IDE

Detected

~/.aws/amazonq/default.json (preserves an existing agents/default.json or legacy mcp.json)

MCP only

CodeBuddy Code CLI

Detected

~/.codebuddy/.mcp.json (preserves an active deprecated/legacy file)

CODEBUDDY.md, skill, three read-only graph agents; beta hooks are not auto-installed

IBM Bob Shell

Detected by bob

~/.bob/mcp_settings.json

Shared rule; no invented hook or agent

Pochi

Detected

~/.pochi/config.jsonc (mcp)

README.pochi.md, skill, and three readFile-only parent-handoff agents

Pi

Detected

—

~/.pi/agent/AGENTS.md + skill; MCP/subagents require an explicit reviewed extension

IBM Bob IDE

Conditional

Existing ~/.bob/mcp.json

Shared rule + IDE skill; no invented hook or agent

Oh My Pi (omp)

Detected

Effective agent directory (OMP_PROFILE / PI_CODING_AGENT_DIR; default ~/.omp/agent/mcp.json)

Skill and three direct-MCP graph-tool subagents (Scout/Verify/Auditor); preserves user AGENTS.md

Sourcegraph Cody

Explicit opt-in

Existing $CBM_CODY_CONFIG_PATH

MCP only

For Codex, install keeps only a tiny managed activation pointer in global $CODEX_HOME/AGENTS.md; all detailed behavior lives in the installed codebase-memory skill. Fresh installs create the pointer, upgrades replace the legacy full managed block while preserving all user-owned bytes, and uninstall removes only the managed pointer.

Sessions, compaction, and subagents

Hooks installed by this project are fail-open and context-only. Claude Code's PreToolUse observes Grep/Glob/Bash and injects matching graph symbols as additionalContext; PostToolUse on Read adds targeted coverage context when the graph could not fully parse or index that file. It never denies or replaces the requested tool call.

Claude Code, Codex CLI, Qwen Code, GitHub Copilot CLI, and VS Code's Copilot runtime receive paired session/subagent context where the vendor exposes a documented context-output contract. Codex users must review and trust installed hooks through /hooks; changing a hook definition changes its trust hash, so an update can require re-trust. Qoder uses SessionStart, SubagentStart, and post-Read coverage, including its documented PowerShell executor on Windows. Kimi uses UserPromptSubmit, while Hermes uses pre_llm_call; both retain their documented Windows execution paths. Devin installs UserPromptSubmit and PostCompaction on macOS/Linux and adds SessionStart only when Claude's equivalent managed hook is not present. GitLab Duo gets a narrowly scoped macOS/Linux user SessionStart entry on its experimental hook surface. GitLab Duo, Devin, and Factory hooks are withheld on Windows because those vendors do not document a deterministic shell/executor contract there. Gemini CLI, Factory Droid, and Augment also add documented post-read/view coverage context but expose no equivalent documented child-start context.

For runtimes without a stable context-producing lifecycle event, durable files carry the contract across fresh sessions and compaction: verify the graph project and index freshness, query structural facts in the parent, then pass the project, qualified symbols, paths, and call-chain evidence in every delegated task. Claude, Codex, Gemini, Kiro, Qwen, Copilot, CodeBuddy, OpenCode, Kilo, Vibe, Qoder, Junie, Factory, and Grok Build receive Scout, Verify, and Auditor graph profiles. Kiro embeds this MCP server with --tool-profile scout for Scout and --tool-profile analysis for Verify/Auditor. Junie registers equivalent named server aliases because its subagent schema filters by server rather than by individual tool. Both process profiles use positive allowlists: Scout exposes seven fast inspection tools, Analysis exposes eleven, and future or mutating tools remain unavailable until explicitly reviewed. If either Junie alias collides with user configuration, the installer preserves it and installs parent-handoff profiles instead. Qoder combines its documented named-server selection with exact tier-specific MCP tool IDs. Factory uses exact registered MCP tool IDs without its additive mcpServers field, which would expose the whole server. Codex, Kilo, Vibe, and other capable formats likewise enumerate the narrowest supported tool set. Rovo, Cursor, Augment, Pochi, and Cline use parent handoff where direct child MCP is unavailable or unsafe; Pochi is limited to readFile, and Cline child agents cannot use MCP.

Cline's file hooks auto-activate when present, and current Cline does not reliably consume their context output, so automatic adapters are withheld and older owned adapters are cleaned up. CodeBuddy's beta, version-gated hooks are not auto-installed. Junie's EAP SessionStart output is documented as ignored, so no context hook is installed. Junie custom agents remain EAP-dependent. Qoder can resolve higher-priority project or plugin agents before user agents with the same name; reload the client after installation or profile changes. Cursor context hooks are withheld: session context injection has a known race, subagentStart is control-only, and read-only subagents cannot safely receive MCP access. Grok Build's passive hook events (SessionStart, SubagentStart, PostToolUse) discard stdout and PreToolUse honors only deny/rewrite decisions, so its context hooks are withheld; Grok also reads Claude and Cursor MCP, skill, and hook files through its compat layer, and the native config.toml entry shadows that copy by name. Rovo has no documented session context-output hook, and Bob documents neither a suitable hook nor a custom-agent surface. Those surfaces are not approximated with invented augmentation. Kimi plugins, Amp plugins, and GitLab experimental global skills remain opt-in.

OpenClaw reinjects the Codebase Knowledge Graph (codebase-memory-mcp) AGENTS section after compaction and places the same guidance in TOOLS.md, the bootstrap files inherited by its subagents. Automatic augmentation covers the active/default workspace. Separate agents.list[].workspace directories require making that workspace active for installation or copying the managed block there.

The installed Claude shim is named cbm-code-discovery-gate for backward compatibility; despite the legacy name, it never gates or blocks.

Manual or UI-managed integrations

These are intentionally not counted as automatic installs: Qodo MCP is added through its UI and may be governed by enterprise allowlists; Warp MCP is managed through Warp Drive/UI or per invocation (only the shared skill is automatic); JetBrains AI Assistant / ACP is IDE-managed; GitHub Copilot coding agent, Jules, and CodeRabbit are cloud/repository-managed; Replit exposes a remote/service integration rather than a stable local user-global client; BLACKBOX AI does not document a stable arbitrary user-global MCP/instruction/agent schema; Plandex has no stable global registry safe to mutate; and SWE-agent uses explicit YAML and is no longer a suitable automatic global target.

CLI Mode

Every MCP tool can be invoked as a local, one-shot command. CLI tools neither start nor connect to the coordination daemon and leave no standing process behind. They hold a crash-safe exact-build admission lease only for the command lifetime. index_repository is the only exception internally: it starts a temporary, exact-build supervised worker for the index, then stops that worker before the CLI command exits; the worker holds its own lease until exit.

Commands that mutate graph data use shared OS-backed, per-project locks. This serializes conflicting work from CLI and MCP sessions on the same project while allowing unrelated projects to proceed independently.

When stderr is an interactive terminal, the CLI automatically shows lifecycle and indexing progress. Pass --progress to force the same feedback when stderr is redirected or the command is run non-interactively. Pass --quiet to disable automatic terminal progress and ordinary diagnostics while retaining errors; it cannot be combined with --progress or outer cli --verbose. Routine informational logs are quiet by default; pass outer cli --verbose to include them. Progress and logs use stderr while stdout remains reserved for the command result. Read tools return a compact tree by default; pass a tool's --format json for machine-readable payload JSON, or outer --json for the full MCP envelope.

Large compact-tree tables may start with a response-local <section>_refs directory and an explicit <section>_ref_rule. A cell such as @0+handler.go reconstructs to ref 0's prefix plus handler.go. References are local to that sibling <section> table and expansion is non-recursive: entries inside <section>_refs are always literal prefixes. This is limited to declared path and qualified-name columns and activates only when the exact rendered table is at least 15% and 64 bytes smaller and a conservative model-neutral token-shape proxy also improves by at least 1%. Search and trace likewise render direct and prefix-grouped tree shapes and keep the smaller complete representation, so singleton or scattered answers do not pay directory overhead. Keys are declared once per table but never cryptically abbreviated, and --format json keeps stable literal strings for machine consumers. Both gates are deterministic; exact token counts still depend on the caller's tokenizer.

Lean responses truncate semantically, never by cutting arbitrary bytes from code or identifiers. Ranked graph rows are retained ahead of raw grep rows and diagnostic summaries; omitted rows/sections report totals, has_more, and a strictly advancing continuation offset or cursor. If even the first whole row cannot fit, CBM asks for a higher budget and emits no self-looping cursor. max_output_tokens is model-neutral sizing guidance: CBM enforces a deterministic ceiling of four UTF-8 bytes per requested token, so it is not a tokenizer-exact count. Detail flags such as diagnostics, source_mode, and detail opt into heavier fields. search_code pages ranked rows with result_limit/result_offset (limit remains a compatibility alias), raw rows with raw_limit/raw_offset, and directory summaries with directory_limit/directory_offset. Raw lines default to a UTF-8-safe match-centered preview; each row reports content_start_byte, returned/total byte counts, match byte bounds when known, and a content continuation offset. Pass raw_content_offset to page the original line without moving the raw-row cursor. match_limit and source_max_lines bound per-result details, with exact omission metadata. detect_changes pages changed files, impacted symbols, and module summaries independently; prefer its snapshot-bound *_cursor continuations, which reject changed commits, worktree bytes, graph generation, or semantic arguments instead of silently skipping or duplicating rows.

Every response is standard UTF-8. Identifiers, paths, and raw search previews preserve POSIX byte-string identities: a preserved value containing malformed UTF-8 is emitted reversibly as @bytes:<lowercase hex of every original byte>. A valid preserved value that literally begins with the reserved @bytes: or @utf8: prefix is emitted as @utf8:<original value>, so decoding is unambiguous: strip one @utf8: prefix for literal UTF-8, or hex-decode one @bytes: prefix for original bytes. Ordinary valid UTF-8 is unchanged and pays no output-token overhead. To keep code readable, source bodies replace malformed UTF-8 with U+FFFD; use the pageable raw search preview when byte-exact source inspection is required.

Use cli <tool> --help to see the flags generated from that tool's input schema:

codebase-memory-mcp cli index_repository --repo-path /path/to/repo
codebase-memory-mcp cli list_projects

# Use the "name" returned by list_projects as the project value.
codebase-memory-mcp cli search_graph --project my-project --name-pattern '.*Handler.*' --label Function
codebase-memory-mcp cli trace_path --project my-project --function-name Search --direction both
codebase-memory-mcp cli query_graph --project my-project --query 'MATCH (f:Function) RETURN f.name LIMIT 5'

# Force human-readable progress without contaminating stdout.
codebase-memory-mcp cli --progress index_repository --repo-path /path/to/repo
# Suppress automatic terminal progress and non-error diagnostics.
codebase-memory-mcp cli --quiet list_projects --format json
codebase-memory-mcp cli search_graph --project my-project --label Function --format json
codebase-memory-mcp cli list_projects --format json --detail stats | jq '.projects[].name'

JSON arguments can also be piped on stdin, for tools that take arguments. A tool whose input schema declares none — list_projects — never reads stdin, so it stays responsive when it inherits a pipe the caller never closes (the default for child_process.spawn and similar wrappers). Inline JSON remains accepted for backward compatibility but is deprecated in favor of flags, --args-file, or stdin.

MCP Tools

Indexing

Tool

Description

index_repository

Index a repository into the graph. Auto-sync keeps it fresh after that.

list_projects

List all indexed projects with node/edge counts.

delete_project

Remove a project and all its graph data.

index_status

Check indexing status of a project.

check_index_coverage

Check whether exact paths or a scope are indexed and fresh. A clean result means no recorded gap, not proof of completeness.

Querying

Tool

Description

search_graph

Structural, BM25, and semantic search. Page structural rows with offset/limit and ranked semantic rows independently with semantic_offset/semantic_limit.

trace_path

BFS traversal — who calls a function and what it calls (alias: trace_call_path). Depth 1-5.

detect_changes

Map git diff to affected symbols + blast radius with risk classification.

query_graph

Execute Cypher-like graph queries (read-only).

get_graph_schema

Node/edge counts, relationship patterns, property definitions per label. Run this first.

compare_graphs

Compare two indexed snapshots: node/edge additions and removals between a base and a target.

get_code_snippet

Read source code for a function by qualified name.

get_file_outline

Declaration outline of one repository-relative file in source order, with optional label filter and paging.

get_architecture

Codebase overview: languages, packages, routes, hotspots, clusters, ADR.

search_code

Grep-like text search within indexed project files.

manage_adr

CRUD for Architecture Decision Records (get reads, update replaces the whole document, set_sections rewrites only the named sections and leaves every other byte untouched, sections lists headings). Query modes do not wait behind a same-project reindex; writes remain serialized.

ingest_traces

Ingest runtime traces to validate HTTP_CALLS edges.

manage_adr(mode='set_sections') writes one or more sections by name and splices them into the stored document, so text outside the named sections — including a preamble, code fences and section ordering — is preserved byte-for-byte. Any ## Heading works, not just the conventional PURPOSE / STACK / ARCHITECTURE / PATTERNS / TRADEOFFS / PHILOSOPHY set; names match exactly, including case. Writing the same section twice is a no-op, so a retry after a lost response cannot duplicate content.

manage_adr query modes (get and sections) use the server's cached query store so they can proceed while a same-project reindex is running. If another process publishes a replacement store during reindexing, they can return the pre-publication ADR until idle eviction refreshes that cache. Updates remain serialized through the project mutation guard.

Graph Data Model

Node Labels

Project, Package, Folder, File, Module, Class, Function, Method, Interface, Enum, Type, Route, Resource

Edge Types

CONTAINS_PACKAGE, CONTAINS_FOLDER, CONTAINS_FILE, DEFINES, DEFINES_METHOD, IMPORTS, CALLS, CALL_REFERENCE, HTTP_CALLS, ASYNC_CALLS, IMPLEMENTS, HANDLES, USAGE, CONFIGURES, REFERENCES_FILE, WRITES, MEMBER_OF, TESTS, USES_TYPE, FILE_CHANGES_WITH

Qualified Names

get_code_snippet uses qualified names: <project>.<path_parts>.<name>. Use search_graph to discover them first.

Supported Cypher (openCypher read subset)

query_graph is a read-only openCypher subset:

  • Clauses: MATCH, OPTIONAL MATCH, multiple MATCH, WHERE, WITH (+ WITH … WHERE), RETURN, ORDER BY, SKIP, LIMIT, DISTINCT, UNWIND, UNION / UNION ALL, CASE.

  • Patterns: labelled nodes, label alternation (n:A|B), relationship types/direction, variable-length paths [*1..3], inline property maps.

  • WHERE: = <> < <= > >=, AND/OR/XOR/NOT, IN, CONTAINS, STARTS WITH, ENDS WITH, IS [NOT] NULL, regex =~, label test n:Label, and EXISTS { (n)-[:TYPE]->() } (single-hop existence — great for dead-code, e.g. WHERE NOT EXISTS { (f)<-[:CALLS]-() }).

  • Aggregates: count (+DISTINCT), sum, avg, min, max, collect.

  • Functions: labels, type, id, keys, properties; toLower/toUpper/toString/toInteger/toFloat/toBoolean; size, length, trim/ltrim/rtrim, reverse; coalesce, substring, replace, left, right.

Anything outside this subset (write/MERGE/CALL clauses, unsupported functions, list/map literals, comprehensions, path functions, parameters) fails with a clear unsupported … error rather than returning empty results.

Ignoring Files

Layered: hardcoded patterns (.git, node_modules, etc.) → .gitignore hierarchy → .cbmignore (project-specific, gitignore syntax). Symlinks are always skipped.

See docs/cbmignore.md for the full .cbmignore how-to: syntax, precedence across the ignore layers, and negation semantics.

Configuration

codebase-memory-mcp config list                          # show all settings
codebase-memory-mcp config set auto_index true           # auto-index on session start
codebase-memory-mcp config set auto_index_limit 50000    # max files for auto-index
codebase-memory-mcp config set auto_watch false          # don't register background git watcher (default: true)
codebase-memory-mcp config set watcher_enabled false     # stop the watcher thread entirely (default: true)
codebase-memory-mcp config set index_max_files 250000    # optional per-index source-file limit
codebase-memory-mcp config set index_max_source_mb 16384 # optional per-index source-size limit
codebase-memory-mcp config reset auto_index              # reset to default

The two index_max_* settings default to off. Exceeding one fails the complete index attempt rather than publishing a partial graph; an existing serving index is preserved. See Index resource limits.

Environment Variables

Variable

Default

Description

CBM_ALLOWED_ROOT

(unset)

Confine index_repository to paths within this directory. When set, a repo_path that resolves (after symlink / .. resolution) outside this root is refused, and the same check now applies to the graph UI's POST /api/index route rather than only to the MCP tool. Unset imposes no containment restriction — but see the always-on limits below, which apply whether or not this is set. Useful when the server may be driven by an untrusted caller, e.g. agentic or multi-tenant deployments.

CBM_CACHE_DIR

~/.cache/codebase-memory-mcp

Override the database storage directory. All project indexes and config are stored here. One account can use only one canonical cache root at a time; close active CBM sessions/commands before switching it.

CBM_DIAGNOSTICS

false

Set to 1 or true to enable the shared daemon's periodic snapshot.json and retained trajectory.ndjson below a fresh owner-private directory in the system temp directory. Exact paths are logged by diagnostics.start.

CBM_DOWNLOAD_URL

(GitHub releases)

Override the download URL for updates. Used for testing or self-hosted deployments.

CBM_LOG_LEVEL

role-aware

Set the minimum log level. Thin MCP/CLI/hook frontends default to warn; the detached daemon and its supervised index workers default to info so lifecycle and liveness records remain available. Accepted values (case-insensitive): debug, info, warn, error, none — or their numeric equivalents 0–4. A physical worker retains INFO liveness records even under a stricter override because its private log drives the supervisor's no-progress timeout. Frontend messages go to that session's stderr; detached daemon events go to ${CBM_CACHE_DIR}/logs/cbm-daemon.log. Stdout is reserved for MCP JSON-RPC.

CBM_WORKERS

(detected)

Override the parallel-indexing worker count returned by cbm_default_worker_count. Useful inside containers where sysconf(_SC_NPROCESSORS_ONLN) reports host CPUs rather than the cgroup's effective quota. Range 1–256; invalid values are ignored with a warning.

CBM_MEM_BUDGET_MB

(detected)

Override the in-memory graph budget with an explicit cap in MiB, taking precedence over the ram_fraction × total_RAM default. Useful on bare-metal hosts without a cgroup limit, or to pin a budget below the cgroup limit so headroom is left for sibling processes. Must be a positive integer; it is clamped to detected total RAM (logged as mem.budget.clamped), and non-numeric or non-positive values are ignored with a warning (mem.budget.env.invalid).

CBM_DUMP_VERIFY_MIN_RATIO

0.5

After indexing, compare persisted SQLite node count to the in-memory dump count. When persisted nodes fall below this fraction of committed nodes (and committed > 50), index_repository returns status:"degraded" instead of silent indexed. Range 0–1; set 0 to disable. Invalid values are ignored with a warning.

Environment used by daemon-owned components—such as diagnostics, daemon logging, and process-wide indexing resource limits—is captured from the first daemon-backed session that starts the daemon. Later sessions join that process and cannot replace those values. To change them, close all daemon-backed sessions, update the relevant agent configurations consistently, and restart a session. CBM_ALLOWED_ROOT remains session-specific, a conflicting CBM_CACHE_DIR is rejected, and one-shot CLI commands read their own environment without starting the daemon.

# Store indexes in a custom directory
export CBM_CACHE_DIR=~/my-projects/cbm-data

Custom File Extensions

The JSON config files support a single key, extra_extensions, which maps additional file extensions to supported languages. Useful for framework-specific extensions like .blade.php (Laravel) or .mjs (ES modules). (For other tunables, see Environment Variables and the config subcommand above.)

Need the full config-file reference? See docs/CONFIGURATION.md.

Per-project (in your repo root):

// .codebase-memory.json
{"extra_extensions": {".blade.php": "php", ".mjs": "javascript"}}

Global (applies to all projects):

// ~/.config/codebase-memory-mcp/config.json  (or $XDG_CONFIG_HOME/...)
{"extra_extensions": {".twig": "html", ".phtml": "php"}}

Each entry maps an extension (which must start with .) to a language name. Language names are matched case-insensitively. Accepted values (aliases in parentheses) are:

bash (sh), c, c++ (cpp), c# (csharp), clojure, cmake, cobol, common lisp (commonlisp, lisp), css, cuda, dart, dockerfile, elixir, elm, emacs lisp (emacslisp), erlang, f# (fsharp), form, fortran, glsl, go, graphql, groovy, haskell, hcl (terraform), html, ini, java, javascript, json, julia, kotlin, lean, lua, magma, makefile, markdown, matlab, meson, nix, objective-c (objc), ocaml, perl, php, protobuf, python, r, ruby, rust, scala, scss, sql, svelte, swift, toml, tsx, typescript, verilog, vimscript, vue, wolfram, xml, yaml, zig.

Project config overrides global for conflicting extensions. An entry whose language name is unknown, or whose extension does not start with ., is skipped and a warning is logged to stderr (shown at the default info log level). Missing config files are ignored.

Persistence

SQLite databases stored at ~/.cache/codebase-memory-mcp/. Persists across restarts (WAL mode, ACID-safe). To reset: rm -rf ~/.cache/codebase-memory-mcp/.

Troubleshooting

Problem

Fix

/mcp doesn't show the server

Check .mcp.json path is absolute. Restart agent. Test: echo '{}' | /path/to/binary should output JSON.

index_repository fails

Pass absolute path: index_repository(repo_path="/absolute/path")

trace_path returns 0 results

Use search_graph(name_pattern=".*PartialName.*") first to find the exact name.

Queries return wrong project results

Add project="name" parameter. Use list_projects to see names.

Binary not found after install

Add to PATH: export PATH="$HOME/.local/bin:$PATH"

UI not loading

Ensure you ran --ui=true. Check http://localhost:9749.

Hybrid LSP

Semantic type resolution beyond tree-sitter.

Tree-sitter alone gives a syntactic AST. That handles naming, structure, and call sites well, but it can't tell you that user.profile.display_name() resolves to Profile.display_name declared three modules away — tree-sitter doesn't track imports, generics, inheritance, or stdlib types.

codebase-memory-mcp ships a lightweight C implementation of language type-resolution algorithms, structurally inspired by and compatible with major language servers (tsserver / typescript-go, pyright, gopls, Roslyn, Eclipse JDT, rust-analyzer), embedded directly into the native executable. No language server process, no per-project setup, no API key. We call this layer Hybrid LSP: it runs alongside tree-sitter on every parse and refines invocation resolution (CALLS / RESOLVED_CALLS) and callable-value resolution (CALL_REFERENCE, with ambiguous values retained as USAGE) using type information, so the resulting graph mirrors what an IDE "Go to Definition" would resolve.

Languages with full Hybrid LSP:

Language

What it handles

Python (new in v0.7.0)

imports + dotted submodule walks, dataclasses, Self return types, generics, @property, match/case class patterns, SQLAlchemy 2.0 Mapped[T], Pydantic BaseModel, typing.Annotated / ClassVar / Final / InitVar, async/await, classmethod/staticmethod, narrowing (isinstance / is not None / walrus), typing.cast / assert_type, common stdlib (logging, pathlib, json, functools). Target ~95% resolution on idiomatic code.

TypeScript / JavaScript / JSX / TSX

generics, JSX component dispatch, JSDoc inference for plain JS, .d.ts declarations, module re-exports, method chaining via return-type propagation, per-file overlay chained to a shared cross-file registry

PHP (new in v0.7.0)

namespaces, traits, late-static-binding, PHPDoc inference, parameter binding, return-type inference

C# (new in v0.7.0)

global usings, file-scoped namespaces, records (incl. C# 12 primary constructors), LINQ method syntax, async Task<T> / ValueTask<T> unwrap, generic methods, this / base dispatch, var inference, common BCL stdlib

Go (sharpened in v0.7.0)

pre-built per-package cross-file registry, generics, embedded structs, interface satisfaction, package-aware import resolution

C / C++ (sharpened in v0.7.0)

pre-built per-language cross-file registry shared across C and C++; C side handles macros + typedef chains + header-vs-source linking; C++ side handles templates, namespaces, auto inference, and method resolution via class hierarchy

Java (new in v0.8.0)

imports (single-type, on-demand, static), class hierarchies with this / super dispatch, generics, annotations, overload matching by arity and parameter types, lambdas / method references bound to functional interfaces, field-type inference, common JDK stdlib

Kotlin (new in v0.8.0)

imports + same-package resolution, classes / objects / companion objects, extension functions, data classes, nullable-type unwrapping, scope functions (let / apply / run / also / with), infix calls, common stdlib

Rust (new in v0.8.0)

use declarations + module paths, impl blocks and trait methods, struct fields, generics with trait bounds, operator-trait desugaring, derive-macro method synthesis, UFCS static paths, common std prelude

Perl

packages + @ISA / use parent / use base inheritance with method-resolution-order dispatch, SUPER:: calls, Exporter (use Foo qw(...)) import maps, bless / ref($class)||$class self-type inference, qualified Pkg::sub static calls, curated perlfunc + CPAN OOP stdlib; unresolved receivers emit no edge (zero-edge guarantee)

Two-layer architecture:

  1. Tree-sitter pass — fast, syntactic, runs for every one of the 162 languages. Extracts definitions, calls, imports.

  2. Hybrid LSP pass — type-aware, runs above the tree-sitter pass per-language. Refines call edges using the import graph plus a per-file or pre-built cross-file definition registry. Languages without a Hybrid LSP pass yet fall back to textual resolution, so you always get some answer.

The result is a knowledge graph accurate enough to drive trace_path across packages, inheritance hierarchies, and stdlib calls — without paying for a language server process per project.

Language Support

162 languages, all parsed via vendored tree-sitter grammars compiled into the binary. Benchmarked against 64 real open-source repositories (78 to 49K nodes):

Tier

Score

Languages

Excellent (>= 90%)

Lua, Kotlin, C++, Perl, Objective-C, Groovy, C, Bash, Zig, Swift, CSS, YAML, TOML, HTML, SCSS, HCL, Dockerfile

Good (75-89%)

Python, TypeScript, TSX, Go, Rust, Java, R, Dart, JavaScript, Erlang, Elixir, Scala, Ruby, PHP, C#, SQL

Functional (< 75%)

OCaml, Haskell

Also supported (not yet benchmarked): Ada, Agda, Apex, Assembly (NASM), Astro, AWK, Beancount, BibTeX, Bicep, Bitbake, Blade, Cairo, Cap'n Proto, Clojure, CMake, COBOL, Common Lisp, Crystal, CSV, CUDA, D, Devicetree, Diff, .env, Elm, Emacs Lisp, F#, Fennel, Fish, FORM, Fortran, FunC, GDScript, .gitattributes, .gitignore, Gleam, GLSL, GN, Go module, Go template, GraphQL, Hare, HLSL, Hyprlang, INI, ISPC, Janet, Jinja2, JSDoc, JSON, JSON5, Jsonnet, Julia, Just, Kconfig, KDL, Lean 4, Linker Script, Liquid, LLVM IR, Luau, Magma, Makefile, Markdown, MATLAB, Mermaid, Meson, Move, Nickel, Nim, Nix, Odin, Pascal, Pkl, PO (gettext), Pony, PowerShell, Prisma, .properties, Protobuf, Puppet, PureScript, Racket, Regex, requirements.txt, ReScript, RON, reStructuredText, Scheme, Slang, Smali, Smithy, Solidity, SOQL, SOSL, Squirrel, SSH config, Starlark, Svelte, Sway, SystemVerilog, TableGen, Tcl, Teal, Templ, Thrift, TLA+, Typst, Verilog, VHDL, Vim script, Vue, WGSL, WIT, Wolfram, XML, Zsh.

Architecture

src/
  main.c              Entry point (MCP stdio server + CLI + install/update/config)
  daemon/             Per-account session coordination, IPC, lifecycle, shared jobs/watchers
  mcp/                MCP server (17 tools, JSON-RPC 2.0, session detection, auto-index)
  cli/                Install/uninstall/update/config (45 client surfaces, hooks, instructions)
  store/              SQLite graph storage (nodes, edges, traversal, search, Louvain)
  pipeline/           Multi-pass indexing (structure → definitions → calls → HTTP links → config → tests)
  cypher/             Cypher query lexer, parser, planner, executor
  discover/           File discovery (.gitignore, .cbmignore, symlink handling)
  watcher/            Background auto-sync (git polling, adaptive intervals)
  traces/             Runtime trace ingestion
  ui/                 Local HTTP server + verified external 3D-UI asset pack
  foundation/         Platform abstractions (threads, filesystem, logging, memory)
internal/cbm/         Vendored tree-sitter grammars (162 languages) + AST extraction engine

Security

Every release is verified through a multi-layer pipeline before publication:

  • VirusTotal — all 24 executable candidates (unstripped, debug-stripped and stripped) across the eight release products are scanned before smoke/soak (clean is preferred and only the single-Microsoft !ml tolerance documented in SECURITY.md may pass; the number of engines that returned a decisive result is recorded as evidence but is VirusTotal fleet availability, not a pass condition). The selected executable is packaged without changing its SHA-256, release notes link the verdict for the exact bytes shipped, and the full per-candidate evidence is published alongside the release as TSVs for anyone auditing the selection. Every distinct object extracted from the shipped containers — install.sh, install.ps1, LICENSE, THIRD_PARTY_NOTICES.md, the MCPB manifest.json and the unpacked UI assets — is then scanned as well, so the full published surface is covered, not just the executables.

  • SLSA Level 3 — cryptographic build provenance generated by the trusted GitHub Actions build workflow; verify with gh attestation verify <file> --repo DeusData/codebase-memory-mcp --signer-workflow DeusData/codebase-memory-mcp/.github/workflows/_build.yml

  • Sigstore cosign — keyless signatures on all artifacts; bundles included in every release

  • SHA-256 checksums — checksums.txt published with every release; verified by both install scripts before extraction

  • CodeQL SAST — blocks release pipeline if any open alerts remain

  • No language-runtime dependency chain — libraries are vendored at compile time; the small release-owned runtime assets are checksum-verified and content-addressed

v0.7.0 VirusTotal scans

Binary

SHA-256

VirusTotal

linux-amd64

8e12bb2d6ead7f20a6d3...

0/72 ✅

linux-arm64

10f7136bfbf3950c6b2a...

0/72 ✅

darwin-arm64

7062a7408906344bf4f8...

0/72 ✅

darwin-amd64

28c6d640e1a0ac7bfcab...

0/72 ✅

windows-amd64

9c3ddcf78368fd4fa891...

0/72 ✅

Scan links for every release are also included in the GitHub Release notes automatically.

License

MIT

Available Tools

17 tools
check_index_coverageA
Read-onlyIdempotent

Best-effort exact-path/scope coverage and freshness, paged separately. full diagnostics adds raw detail. Clean is not proof of completeness.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathsNo
formatNotree
scopesNo
projectYes
path_limitNo
diagnosticsNonone
path_offsetNo
scope_limitNo
scope_offsetNo

TDQS

A3.9/5.0
Behavior5/5

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

The description adds meaningful behavioral context beyond the readOnly/idempotent annotations: 'Best-effort' signals potential incompleteness, 'paged separately' discloses pagination behavior, 'full diagnostics adds raw detail' explains an output mode, and 'Clean is not proof of completeness' is a crucial caveat for interpreting results. No contradiction with annotations.

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 three short sentences with no filler. The main purpose is front-loaded, followed by a diagnostics tip and a critical caveat. Every sentence earns its place, and the density is appropriate for the tool's complexity.

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 no output schema and sparse parameter documentation, the description provides a useful high-level concept but leaves gaps: it does not explain what 'coverage' or 'freshness' outputs look like, how tree vs json differ, or how to interpret 'clean'. The caveat about completeness is helpful but does not fully compensate for missing return-value 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 0%, so the description must compensate. It does add meaning for paths/scopes ('exact-path/scope'), pagination ('paged separately'), and diagnostics ('full diagnostics'). However, it leaves several parameters (project, format, limits, offsets) semantically unexplained, though some are self-evident from their names and defaults.

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 resource and scope: 'exact-path/scope coverage and freshness'. It clearly indicates a read-only check operation with pagination, going beyond a mere restatement of the tool name. It does not explicitly differentiate from siblings like index_status, but 'exact-path/scope' is distinctive enough.

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 context is implied: you would call this when you need granular coverage or freshness for specific paths/scopes. The phrase 'full diagnostics adds raw detail' hints at when to set diagnostics=full. However, no explicit when-not-to-use guidance or alternatives (e.g., index_status) are mentioned, leaving routing decisions to inference.

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

compare_graphsA
Read-onlyIdempotent

Compare two indexed snapshots: deterministic target-only additions and base-only removals of stable node/edge identities; each set capped by limit and a 512 KiB budget with exact totals and truncation reasons.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
scan_limitNo
base_projectYes
target_projectYes

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses meaningful behavior: deterministic diffing, cap enforcement via limit and a 512 KiB budget, and exact totals with truncation reasons. This is especially valuable because there is no output schema to convey what the tool returns.

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 dense sentence with no filler. It front-loads the core purpose and then packs in behavioral details about caps, totals, and truncation reasons without redundancy.

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 description covers the core behavior and output well, especially given no output schema. However, it leaves scan_limit unexplained and does not mention alternatives or prerequisites beyond 'indexed snapshots', so an agent may not fully understand all input semantics or when to prefer a sibling tool.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it does not explain scan_limit at all and only implicitly covers limit. base_project and target_project are inferable from 'Compare two indexed snapshots', and limit's role is hinted by 'capped by limit', but the parameter semantics remain under-specified for an agent.

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 ('Compare two indexed snapshots') and states what it returns: target-only additions and base-only removals of stable node/edge identities. This is clear and specific, though it does not explicitly distinguish the tool from sibling tools such as detect_changes.

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 provides clear context on when to use the tool: comparing two indexed snapshots to identify deterministic additions and removals. It does not state exclusions or point to alternatives, but the usage context is clear enough to guide selection.

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

delete_projectB
DestructiveIdempotent

Delete a project from the index

ParametersJSON Schema
NameRequiredDescriptionDefault
projectYes

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description adds the 'from the index' scoping, which clarifies that deletion is limited to the index rather than the underlying project, but it does not disclose side effects, reversibility, or permissions. Given that annotations carry the main behavioral burden, a 3 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?

The entire description is a single front-loaded sentence that directly states the action and object. No unnecessary words or redundant information; it is appropriately sized for a simple tool.

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 destructive one-parameter tool, the description states the core operation but leaves out practical details such as the expected format of the project parameter and the exact consequences of deletion. However, the annotation set (destructive, idempotent) partially compensates, so the description is minimally adequate but not fully complete.

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

Parameters1/5

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

With 0% schema description coverage, the description is the only source of parameter meaning, but it merely repeats the parameter name ('project') without explaining what value it should take (e.g., ID, name, path) or any constraints. This is tautological and provides no semantic value beyond the schema.

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 uses a specific action verb 'Delete' and names the exact resource and scope ('a project from the index'), making the tool's function immediately clear. It is clearly distinct from sibling tools like list_projects, search_graph, or get_architecture.

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 gives no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or side conditions. Usage is only implicitly derived from the purpose, but nothing tells an agent when deletion is appropriate or how it differs from other index management tools.

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

detect_changesC
Read-onlyIdempotent

Map a Git diff to files and impact. Page with snapshot cursors.

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNo
limitNo
scopeNoimpact
sinceNo
formatNotree
projectYes
directionNoinbound=callers; outbound=dependencies; both=union.inbound
base_branchNomain
module_limitNo
changed_limitNo
impact_cursorNo
impact_offsetNo
module_cursorNo
module_offsetNo
changed_cursorNo
changed_offsetNo
max_output_tokensNoSizing hint; hard ceiling is 4 UTF-8 bytes/token.

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds the behavioral detail of pagination via 'snapshot cursors,' which is beyond the annotations. However, it does not explain what a snapshot cursor is, how pagination behaves, or any other operational traits like output size limits or error conditions.

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?

The description is very short, with only two sentences, and the main purpose is front-loaded. Each sentence contributes information: the first states the primary purpose, the second notes pagination behavior. There is no redundancy or filler, though the brevity veers toward under-specification rather than tight, informative conciseness.

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

Completeness1/5

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

This is a complex tool with 17 parameters, minimal schema descriptions, no output schema, and no usage guidance. The description does not explain how the Git diff is determined, what 'impact' means, what the output contains, or how the pagination cursor system works. An agent cannot reliably call this tool correctly based on the provided description alone.

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

Parameters2/5

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

With schema description coverage at only 12% and 17 parameters, the description must compensate, but it only hints that cursor-related parameters support pagination via 'Page with snapshot cursors.' It does not explain key parameters like scope, direction, base_branch, since, limit, depth, or the various offsets and cursors. Most parameters remain semantically opaque, so the description adds minimal value beyond the schema.

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 clear action and resource: 'Map a Git diff to files and impact.' This is specific enough to distinguish the tool from siblings like compare_graphs or trace_path, which do not focus on Git diffs. However, 'impact' is somewhat vague and not explained, so it falls short of a 5.

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 provides no guidance on when to use this tool versus its siblings such as compare_graphs, trace_path, or get_architecture. There are no conditional use cases, exclusions, or alternative tool mentions. The only hint is the purpose, which implies usage but does not explicitly state it.

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

get_architectureA
Read-onlyIdempotent

Compact counts, languages, packages, entry points. Request structure, dependencies, routes, hotspots, boundaries, layers, clusters, cycles, or file_tree; path scopes a directory.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoDirectory prefix (for example apps/hoa).
formatNotree
aspectsNoall=everything; overview=compact except file_tree; omitted=languages/packages/entry_points; cycles is opt-in.
projectYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish a read-only, idempotent, non-destructive profile, and the description adds useful behavior beyond that: output is compact by default, optional aspects can be requested, and path restricts scope. It does not describe output shape or edge cases, but the annotation coverage lowers the burden.

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 short, front-loaded sentences with no filler: default output, available aspects, and path scoping are all covered. Every clause earns its place and an agent can quickly parse the salient behavior.

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?

Between the description and the input schema, an agent knows the required project, the path scoping behavior, the selectable aspects, and the tree/json format choice. There is no output schema, but the description does indicate what the default result contains; the main residual gap is the exact return shape for each requested aspect.

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?

The description adds meaning for aspects by listing requestable options and for path by explaining that it scopes a directory. However, format and project receive no enrichment, and with only 50% schema description coverage those parameters remain under-explained in both schema and description.

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 identifies the resource as a project/directory architecture and enumerates the default compact output (counts, languages, packages, entry points) plus requestable aspects. It is specific and informative, though it never states an explicit verb or directly distinguishes itself from siblings like query_graph or get_file_outline.

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 gives concrete usage context: the agent can request structure, dependencies, routes, hotspots, boundaries, layers, clusters, cycles, or file_tree, and path scopes the analysis to a directory. It does not explicitly name alternatives or say when not to use this tool, so it stops short of full routing guidance.

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

get_code_snippetB
Read-onlyIdempotent

Read a search_graph symbol. auto bounds source and outlines large containers; full restores up to 500 lines. Source/outline pages continue; coverage_note marks gaps.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNotree
projectYes
max_linesNo
start_lineNo
source_modeNoauto outlines 200+ line containers; full returns source; outline lists members.auto
member_limitNo
member_offsetNo
qualified_nameYessearch_graph qn, or short name.
include_neighborsNo
max_output_tokensNoauto/outline sizing hint (default 2500), hard ceiling 4 UTF-8 bytes/token. Lines stay whole; explicit full is uncapped unless set.

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral detail: auto mode bounds source, full mode restores up to 500 lines, pagination continues across pages, and coverage_note marks gaps. This goes beyond the annotations, though 'full restores up to 500 lines' is slightly ambiguous given the uncapped note on max_output_tokens.

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?

Three short sentences with the core purpose front-loaded. The phrasing is terse, bordering on cryptic, but every clause carries relevant information and there is no filler.

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

Completeness2/5

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

Given 10 parameters, only 30% schema coverage, and no output schema, the description is not complete enough for reliable tool invocation. It hints at paging and coverage notes but omits how to configure pagination, what output formats look like, and how optional features such as include_neighbors behave.

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

Parameters2/5

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

Schema description coverage is only 30% across 10 parameters, so the description carries a heavy burden. It adds some meaning for source_mode and line limits, but it does not clarify qualified_name, project, format, start_line, member_offset, member_limit, include_neighbors, or max_output_tokens. This is not enough compensation for the large undocumented parameter set.

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 ('Read') and resource ('a search_graph symbol'), making the core purpose clear. It does not explicitly distinguish from siblings like get_file_outline or search_graph, so it falls just short of a 5.

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?

The description gives some usage context around source modes and pagination ('auto bounds source and outlines large containers; full restores up to 500 lines; Source/outline pages continue'). However, it never tells an agent when to prefer this tool over alternatives such as get_file_outline or search_code, nor states exclusions.

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

get_file_outlineC
DestructiveIdempotent

Declaration outline of one exact repository-relative file: optional exact label filter, source order, exact total/offset/limit paging; file/folder/container nodes excluded.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
formatNotree
labelsNoOptional exact node-label filter
offsetNo
projectYes
file_pathYesExact repository-relative file path

TDQS

C2.9/5.0
Behavior1/5

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

The annotations include destructiveHint: true, which strongly implies the tool may have destructive or mutating behavior, but the description describes a read-only operation (getting an outline) and provides no mention of any side effects or destructive actions. This is a clear contradiction. The description also fails to disclose any behavioral traits beyond what the schema provides, and with annotations carrying a conflicting hint, transparency is severely lacking.

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?

The description is a single sentence that packs significant detail without excessive verbosity. It front-loads the primary purpose ('Declaration outline of one exact repository-relative file') and then lists key features concisely. It is dense but not bloated, earning a high score for efficiency.

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

Completeness2/5

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

Given the tool has six parameters and no output schema, the description does not fully explain the return format or behavior. The contradiction with destructiveHint adds confusion, and the description omits any mention of error cases or prerequisites. The description covers basic functionality but is incomplete for an agent to use confidently, especially with the conflicting annotation.

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?

The description adds meaning for some parameters: 'optional exact label filter' corresponds to the labels array, and 'exact total/offset/limit paging' explains limit and offset semantics. However, it does not explain the project parameter, the format enum, or the meaning of 'source order' in detail. With schema description coverage at only 33%, the description partially compensates but leaves gaps for half the parameters.

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 identifies the operation as retrieving a declaration outline for a specific repository-relative file, and mentions key features like label filtering and paging. It distinguishes itself by scoping to a single file and explicitly excluding file/folder/container nodes, which differentiates it from broader tools like get_architecture or search_graph. However, it does not explicitly name sibling alternatives, 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 Guidelines3/5

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

The description implies usage when an agent needs a declaration outline of a specific file, and the phrase 'exact repository-relative file' sets context. It does not explicitly state when not to use it or name alternative tools, leaving some inference required. There is no mention of prerequisites or conditions for use, so guidance is adequate but not explicit.

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

get_graph_schemaB
Read-onlyIdempotent

Get node-label and edge-type counts. diagnostics=full also lists queryable properties.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
formatNotree
offsetNo
projectYes
diagnosticsNonone

TDQS

B3.2/5.0
Behavior3/5

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

Annotations indicate read-only, idempotent, and non-destructive, so the description does not need to repeat safety traits. It adds the 'diagnostics=full' behavior for listing properties, which is beyond annotations. However, it doesn't detail output structure or limitations, but annotations cover a lot.

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?

The description is concise (two sentences) and front-loads the primary purpose. It mentions the diagnostics special case without excess detail, though it could be slightly more structured.

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?

Given the tool's moderate complexity (5 params, enums) and lack of output schema, the description provides minimal but sufficient context for basic usage. It does not explain parameter interplay or output format, but annotations cover safety. Overall adequate but with gaps.

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

Parameters2/5

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

Schema coverage is 0% and the description mentions only the diagnostics parameter's effect, not explaining others like limit, format, offset, or project. With 5 parameters and no schema descriptions, the description fails to compensate, leaving agents to guess parameter purposes.

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 the tool retrieves node-label and edge-type counts, which is a specific resource and data type. It does not explicitly differentiate from siblings like query_graph or get_architecture, but the focus on schema/counts is distinctive.

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?

The description implies usage for schema inspection but does not provide explicit guidance on when to use this over alternatives like query_graph or compare_graphs. It lacks context on typical use cases or exclusions.

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

index_repositoryA
Idempotent

Index a repository. full/moderate add semantics; fast omits them; cross-repo-intelligence links services. Reports coverage gaps.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNofull: all+semantic; moderate: filtered+semantic; fast: filtered only; cross-repo-intelligence: link services.full
nameNoName override; Non-ASCII bytes are encoded; unsafe characters normalized.
repo_pathYesRepository path
persistenceNoWrite .codebase-memory/graph.db.zst.
target_projectsNoCross-repo targets; ["*"] means all.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already mark the tool as not read-only, idempotent, and not destructive; the description adds behavioral detail beyond those flags by explaining what each mode does and noting that the tool 'Reports coverage gaps.' It does not discuss cost, permissions, or persistence side effects, but it supplements the annotation profile meaningfully.

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 three short sentences with no filler, front-loads the core action, and compresses the mode distinctions into a compact contrast. Every clause earns its place.

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?

With no output schema, the description at least signals what the caller will learn ('Reports coverage gaps') and the mode semantics are covered. It does not describe the return shape or when to prefer sibling coverage tools, but given the 100% parameter schema and annotations, the main operational context is present.

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 every parameter. The description's mode language largely restates the schema's enum descriptions rather than adding new parameter-level meaning, and it adds no detail about name, persistence, or target_projects.

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 opens with 'Index a repository,' a specific verb and resource, and clarifies mode differences. It does not explicitly contrast itself with sibling tools like check_index_coverage or index_status, so it stops short of full sibling differentiation.

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?

The mode summary ('full/moderate add semantics; fast omits them; cross-repo-intelligence links services') gives implied guidance for choosing a mode, but the description never states when to use index_repository instead of related tools such as check_index_coverage or detect_changes. Usage context is present but not explicit.

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

index_statusA
Read-onlyIdempotent

Project readiness, counts, root, and coverage gaps. diagnostics adds coverage rows; verbose adds Git paths. Best-effort only; verify cited paths with check_index_coverage.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNotree
projectYes
verboseNoAdd worktree/shadow Git paths for index-location debugging.
diagnosticsNoCoverage rows: counts, five samples, or up to 500.none

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint), and the description adds non-annotated behavioral context: 'Best-effort only' warns results may be incomplete or stale, and 'verify cited paths with check_index_coverage' sets a verification expectation. The parameter-effect notes ('diagnostics adds coverage rows; verbose adds Git paths') further describe behavior without contradicting the annotations.

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?

Three short sentences in roughly 31 words, front-loaded with the key output fields, then flag effects, then the caveat and sibling pointer. No sentence is wasted; each earns its place. The telegraphic style slightly hurts clarity elsewhere, but for size and structure this is exemplary.

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 moderate 4-param report tool with full annotation coverage, the description covers the return-value terrain (readiness, counts, root, coverage gaps), the toggle behaviors, and the reliability caveat even with no output schema. Minor gaps remain — e.g., what 'root' means or how tree/json formats differ — but the schema's enums, defaults, and tool name make these semi-self-evident. Complete enough to call correctly.

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 50% — verbose and diagnostics have descriptions, but project and format do not. The description's mentions of diagnostics and verbose largely restate the schema ('coverage rows', 'Git paths') rather than adding new meaning, and it does nothing for the undocumented project and format parameters. Adequate but no enrichment beyond the structured fields.

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

Purpose3/5

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

The description enumerates concrete outputs ('Project readiness, counts, root, and coverage gaps') and points to the sibling check_index_coverage, so an agent can roughly infer this is an index-status report. However, it is a noun-phrase fragment with no verb ('reports', 'returns', 'gets'), leaving the tool's action implicit. It distinguishes from check_index_coverage but does not meet the 'specific verb+resource' bar.

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 an explicit alternative directive — 'verify cited paths with check_index_coverage' — telling the agent when to hand off verification to a sibling, plus the 'Best-effort only' caveat that sets expectations for trusting results. It does not explicitly state when to use this tool versus other siblings (e.g., index_repository), but the context is clear enough. Falls just short of a full when/when-not framing.

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

ingest_tracesC

Validate and count traces; graph edge creation is not implemented

ParametersJSON Schema
NameRequiredDescriptionDefault
tracesYes
projectYes

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already show this is non-read-only, non-idempotent, and non-destructive, so the bar is lower. The description adds one useful behavioral fact: graph edge creation is not implemented. However, it does not disclose whether data is persisted, whether existing traces are replaced, or what the return value is.

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?

Two short sentences with the primary action front-loaded and a key limitation stated directly. It is efficient and every sentence earns its place, though the brevity sacrifices substantive detail.

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

Completeness2/5

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

For a mutating ingestion tool with no output schema and sparse annotations, this is incomplete. It lacks return-value semantics, side-effect disclosure, prerequisites, and parameter meaning, leaving the agent with too much to infer before calling it safely.

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

Parameters1/5

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

Schema description coverage is 0%, and the description names no parameters or fields. The agent must infer the meaning of 'count', 'callee', 'caller', and 'project' from parameter names alone, with no clarification of what 'count' represents in the trace objects.

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 concrete action, 'validate and count traces', on a specific resource and explicitly notes that graph edge creation is not implemented, which helps distinguish it from graph-building siblings. It is not a 5 because 'count traces' is slightly ambiguous: it could mean returning a count, storing a count, or computing counts for validation.

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?

There is no explicit when-to-use guidance and no named alternative tool among the graph/index siblings. The note about graph edge creation not being implemented implies this is not the graph-write path, but the description never says when to call this instead of index_repository or query_graph.

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

list_projectsA
Read-onlyIdempotent

List projects with stable paging. Identity is lean; stats adds graph sizes.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
detailNostats adds node/edge/database-size counts.identity
formatNotree
offsetNo
metadata_onlyNoCompatibility: omit counts, size, and branch.
include_detailsNoAlias for detail=stats: include branch, node/edge counts and database size. Slower.

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the operation read-only and idempotent. The description adds meaningful behavioral context by highlighting 'stable paging' and explaining that identity mode is lean while stats mode adds graph sizes, which goes beyond the structured annotations.

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 short sentences deliver the core purpose, a key behavioral guarantee, and the main detail-mode tradeoff with no wasted words. The content is front-loaded and easy to scan.

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 tool with six parameters and no output schema, the description is brief but somewhat incomplete. It covers purpose and a few parameter semantics, but it does not explain response shape, how paging behaves beyond 'stable', or the format/metadata_only compatibility options. It is adequate but leaves meaningful gaps.

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 only 50%, so the description must compensate for undocumented parameters. It adds value by clarifying that the detail parameter controls whether graph sizes are included. However, it says nothing about limit, offset, format, metadata_only, or include_details beyond what the schema already provides, leaving several parameters unexplained.

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 the action and resource: 'List projects'. The mention of 'stable paging' and the detail-mode distinction adds useful specificity. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.

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?

The description implies when to use the tool by saying it lists projects with stable paging, and it gives some guidance on choosing between identity and stats detail. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions, leaving usage context mostly implicit.

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

manage_adrB
Destructive

Outline an ADR by default; get reads it; update replaces it

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNooutline pages headings; get reads; update replaces the whole document; set_sections rewrites only the named sections and leaves every other byte untouched (an identical repeated write is byte-identical, so retrying is safe); sections is legacy.outline
formatNotree
contentNoWhole document for update
projectYes
section_limitNo
section_offsetNo
section_updatesNoset_sections: section name -> new body. Any heading name works; names match exactly, including case.

TDQS

B3.2/5.0
Behavior4/5

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

The description explicitly states that 'update replaces it', aligning with the destructiveHint annotation and adding specificity. It also notes 'get reads it', which is read-only. This adds behavioral context beyond the annotations, though it does not cover set_sections behavior.

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 extremely concise with two short sentences, front-loading the default behavior. No redundant words, but it sacrifices completeness for brevity.

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

Completeness2/5

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

For a tool with 7 parameters, a mode enum, and no output schema, the description is too minimal. It fails to mention the set_sections mode, section pagination parameters, or format options, leaving important aspects unexplained.

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

Parameters2/5

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

The description does not elaborate on any parameters beyond what the schema already provides. With schema coverage at 43%, the description should compensate for undocumented parameters like format, section_limit, and section_offset, but it does not.

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+resource ('Outline an ADR') and contrasts it with 'get reads' and 'update replaces', clarifying it manages ADRs. It distinguishes from sibling tools by focusing on ADRs, but omits the set_sections mode, which is a significant feature.

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. The description does not mention sibling tools, exclusions, or specific conditions for using different modes, leaving the agent to infer usage from the tool name and schema.

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

query_graphA
Read-onlyIdempotent

Read-only Cypher for multi-hop, aggregation, complexity, or cross-service analysis. Default: 200 visible rows with exact/lower-bound totals and truncation; continue safely with next_cursor. graph=missed is a file tree of flagged coverage gaps; absence is not proof of completeness. Use get_graph_schema(diagnostics=full) for properties.

ParametersJSON Schema
NameRequiredDescriptionDefault
graphNocode graph (default) or missed coverage-gap file tree.code
queryYesCypher query
cursorNoSnapshot continuation; keep query/project/graph. Format, budget, and max_rows may change.
formatNotree may use local @N+suffix prefix refs; json uses direct strings.tree
offsetNoLive compatibility paging; cannot be combined with cursor.
projectYes
max_rowsNoVisible rows (default 200; max 99998); 0 uses the legacy maximum. Evaluation is unchanged.
max_output_tokensNoSizing hint; hard ceiling is 4 UTF-8 bytes/token. Rows stay whole.

TDQS

A3.8/5.0
Behavior1/5

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

Annotation Contradiction: openWorldHint=false indicates closed-world results, but the description says 'absence is not proof of completeness' for graph=missed, which is an open-world caveat. While pagination, truncation, and cursor behavior are disclosed, the contradiction with the annotation makes the behavioral guidance unreliable.

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 dense but efficient: it front-loads purpose, then covers pagination behavior, graph=missed semantics, and the get_graph_schema alternative. Every sentence earns its place with no filler.

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 an 8-parameter tool with no output schema, the description covers the most important non-obvious behaviors: pagination, truncation, graph modes, and property lookup. It is nearly complete, but the open-world annotation contradiction prevents it from being fully trustworthy.

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

Parameters4/5

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

Schema coverage is high (88%), so the baseline is 3, but the description adds valuable semantics: default 200 visible rows, truncation and lower-bound totals, safe cursor continuation, and the graph=missed coverage-gap caveat. These details meaningfully supplement the schema descriptions.

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 clearly defines the tool as read-only Cypher for multi-hop, aggregation, complexity, or cross-service analysis, which is specific and informative. It also differentiates from get_graph_schema by directing property-related needs there.

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 states when to use the tool (complex, multi-hop, aggregation, cross-service analysis) and explicitly points to get_graph_schema(diagnostics=full) for properties. It does not explicitly contrast with search_graph or other siblings, leaving room for stronger exclusions.

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

search_codeC
Read-onlyIdempotent

Graph-ranked text search: compact symbols, full bounded source, or file paths.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNocompact
debugNoAdd scope_ms/scan_ms/enrich_ms phase timings.
limitNo
regexNo
formatNotree
contextNo
patternYes
projectYes
raw_limitNo
raw_offsetNo
match_limitNo
path_filterNo
file_patternNo
result_limitNo
result_offsetNo
directory_limitNo
directory_offsetNo
source_max_linesNo
max_output_tokensNo
raw_content_offsetNoRaw-line byte offset; omit for match-centered preview.

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that results are graph-ranked and that modes vary between symbols, full source, and file paths. It does not disclose output shape, pagination behavior, or mode-specific limits, but the annotation coverage lowers the bar.

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

Conciseness3/5

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

The description is very short and free of fluff, which is positive, but it is closer to a tagline than a structured explanation. For a tool with 20 parameters and no output schema, the brevity borders on under-specification rather than efficient completeness.

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

Completeness2/5

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

Given the high complexity (20 parameters, 10% schema coverage, no output schema), the description is far from complete. It does not explain result formats, how graph ranking affects results, the meaning of raw offsets, or the tradeoffs between modes. An agent would likely need to probe the tool or inspect sibling definitions to use it confidently.

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

Parameters2/5

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

Schema description coverage is only 10%, so the description must compensate for the 20 parameters. It partially does by explaining the mode enum values ('compact symbols, full bounded source, or file paths'), but pattern, project, limit, regex, format, context, filters, offsets, and output token limits are left unexplained. This is insufficient for such a parameter-heavy tool.

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 action ('search') on a clear resource ('code') and names three distinct output modes: compact symbols, full bounded source, or file paths. It is reasonably clear but does not explicitly differentiate itself from likely siblings such as search_graph or get_code_snippet.

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 gives no guidance on when to use this tool versus alternatives. It does not mention search_graph for graph-oriented queries, get_code_snippet for retrieving a known snippet, or any exclusions. Usage context must be inferred from the name and the phrase 'graph-ranked text search.'

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

search_graphB
Read-onlyIdempotent

Find symbols via BM25 query, regex name/qn filters, or semantic_query. Rows keep qn/file/lines and in/out over CALLS/USAGE/CALL_REFERENCE/INHERITS/IMPLEMENTS.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo
limitNo
queryNo
detailNodefault
fieldsNo
formatNotree
offsetNo
projectYes
max_degreeNo
min_degreeNo
qn_patternNo
file_patternNo
name_patternNo
relationshipNo
semantic_limitNo
semantic_queryNoNot with query.
semantic_offsetNo
include_connectedNo
max_output_tokensNo
exclude_entry_pointsNo

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already establish read-only/idempotent/non-destructive behavior. The description adds useful context about result rows and relationship edge kinds, but it does not disclose behavioral details such as how filters combine, how degree limits affect traversal, or what output formats contain. With annotations covering safety, this is adequate but not rich.

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?

Two compact sentences with no filler; the main verb and resource appear immediately. The jargon density is high, but every clause adds information, making it appropriately sized for a first-level description.

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

Completeness2/5

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

For a 20-parameter search tool with no output schema, this description is too thin. It gives the result row shape but not enough guidance on filter semantics, output formatting, pagination, or the meaning of many parameters, leaving the agent to infer critical calling details.

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

Parameters2/5

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

Schema description coverage is only 5% across 20 parameters, so the description must compensate. It explains the core query modes and regex filters, but leaves most parameters—detail, fields, format, offset, degree bounds, include_connected, exclude_entry_points—unexplained. This is a significant gap.

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 identifies a symbol search tool with specific query modes (BM25, regex filters, semantic_query) and describes what rows contain. It does not explicitly distinguish this from siblings like search_code or query_graph, so it loses the top score.

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?

The description implies usage for symbol lookup across relationship types, but never states when to prefer this tool over search_code or query_graph, or when not to use it. There is no explicit alternative routing or exclusion guidance.

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

trace_pathA
Read-onlyIdempotent

Trace callers/callees, data flow, or cross-service paths. Defaults exclude tests and resolver evidence. Rows keep qn/hop with explicit totals, relations, and continuations.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNocalls, argument-aware data_flow, or service edges.calls
depthNo
limitNoRows/page; gte flags the 5000-node engine ceiling.
cursorNoPass next/next_cursor with traversal args unchanged; budget may increase.
formatNotree chooses smaller complete direct/grouped output; json uses stable grouped tables.tree
projectYes
directionNoboth
edge_typesNo
risk_labelsNoAdd hop-risk labels.
function_nameYes
include_testsNo
parameter_nameNodata_flow parameter filter.
include_evidenceNoAdd resolver class and confidence.
max_output_tokensNoSizing hint; hard ceiling is 4 UTF-8 bytes/token. Evidence/args yield before nearest graph rows.

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral details: default exclusions of tests and resolver evidence, and the fact that rows preserve qn/hop with explicit totals, relations, and continuations. No contradiction with annotations.

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 compact sentences with the core purpose front-loaded. Every phrase adds information, and there is no filler or repetition of schema details.

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 tool with 14 parameters and no output schema, the description is relatively sparse. It covers basic behavior and output row shape, but leaves mode-specific behavior, direction/edge_types semantics, and pagination details largely to the schema. Adequate but with clear gaps.

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 only 57%, so the description should compensate. It does add implicit meaning around include_tests and include_evidence by mentioning defaults, but it does not explain direction, edge_types, depth, or cursor behavior beyond what the schema already provides.

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 opens with the specific verb 'Trace' and names the resource types: callers/callees, data flow, and cross-service paths. It clearly distinguishes what the tool operates on, though it does not explicitly contrast it with sibling graph/query tools.

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?

There is no guidance on when to use trace_path versus search_graph, query_graph, or get_architecture. The description only states default exclusions (tests, resolver evidence) and row content, leaving the selection decision to the agent.

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.

  1. 15 tool updatesv0.11.0
    • Changedcheck_index_coverage7 fields changed
      • addedInput schema / properties / diagnostics
        Added value: +{
+  "default": "none",
+  "enum": [
+    "none",
+    "full"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / path_limit
        Added value: +{
+  "default": 20,
+  "maximum": 128,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / path_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • removedInput schema / properties / paths / description
        Removed value: -"Repository-relative files to check exactly. Required if 'scopes' is omitted."
      • changedInput schema / properties / scope_limit / default
        Previous value: -200New value: +20
      • removedInput schema / properties / scopes / description
        Removed value: -"Repository-relative path prefixes; use . for the project root. Required if 'paths' is omitted."
    • Addedcompare_graphs
    • Changeddetect_changes15 fields changed
      • addedInput schema / properties / changed_cursor
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / changed_limit
        Added value: +{
+  "default": 20,
+  "maximum": 5000,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / changed_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • removedInput schema / properties / depth / description
        Removed value: -"Max traversal hops from the changed symbols."
      • changedInput schema / properties / direction / description
        Previous value: -"inbound (default) = the blast radius: transitive CALLERS of the changed symbols. outbound = what the changed code depends on. both = union."New value: +"inbound=callers; outbound=dependencies; both=union."
      • addedInput schema / properties / impact_cursor
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / impact_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • removedInput schema / properties / limit / description
        Removed value: -"Per-symbol impacted rows shown (nearest hops first). impacted_total is always exact and the impacted_modules rollup always complete regardless."
      • addedInput schema / properties / max_output_tokens
        Added value: +{
+  "default": 3200,
+  "description": "Sizing hint; hard ceiling is 4 UTF-8 bytes/token.",
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}
      • addedInput schema / properties / module_cursor
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / module_limit
        Added value: +{
+  "default": 20,
+  "maximum": 256,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / module_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / scope / default
        Added value: +"impact"
      • removedInput schema / properties / scope / description
        Removed value: -"files: changed files only (no traversal). impact (default): files + the transitive impact set."
      • removedInput schema / properties / since / description
        Removed value: -"Git ref or tag to compare from (e.g. HEAD~5, v0.5.0). Diffs <ref>...HEAD."
    • Changedget_architecture3 fields changed
      • changedInput schema / properties / aspects / description
        Previous value: -"Aspects to include. 'all' = everything; 'overview' = compact summary (all except file_tree); omit = all. 'cycles' is opt-in ONLY (never via all/overview): it scans the whole call graph for circular CALLS dependencies (SCCs of size > 1)."New value: +"all=everything; overview=compact except file_tree; omitted=languages/packages/entry_points; cycles is opt-in."
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / path / description
        Previous value: -"Optional directory prefix to scope architecture (e.g. apps/hoa)"New value: +"Directory prefix (for example apps/hoa)."
    • Changedget_code_snippet8 fields changed
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / max_lines
        Added value: +{
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / max_output_tokens
        Added value: +{
+  "description": "auto/outline sizing hint (default 2500), hard ceiling 4 UTF-8 bytes/token. Lines stay whole; explicit full is uncapped unless set.",
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}
      • addedInput schema / properties / member_limit
        Added value: +{
+  "default": 50,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / member_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • changedInput schema / properties / qualified_name / description
        Previous value: -"Full qualified_name from search_graph, or short function name"New value: +"search_graph qn, or short name."
      • addedInput schema / properties / source_mode
        Added value: +{
+  "default": "auto",
+  "description": "auto outlines 200+ line containers; full returns source; outline lists members.",
+  "enum": [
+    "auto",
+    "full",
+    "outline"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / start_line
        Added value: +{
+  "minimum": 1,
+  "type": "integer"
+}
    • Addedget_file_outline
    • Changedget_graph_schema4 fields changed
      • addedInput schema / properties / diagnostics
        Added value: +{
+  "default": "none",
+  "enum": [
+    "none",
+    "full"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 50,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
    • Changedindex_repository5 fields changed
      • changedInput schema / properties / mode / description
        Previous value: -"All modes run type-aware LSP call/usage resolution (per-file + cross-file). full: all files + similarity/semantic edges. moderate: filtered files + similarity/semantic. fast: filtered files, no similarity/semantic. cross-repo-intelligence: match Routes/Channels across projects."New value: +"full: all+semantic; moderate: filtered+semantic; fast: filtered only; cross-repo-intelligence: link services."
      • changedInput schema / properties / name / description
        Previous value: -"Override the derived project name. Non-ASCII bytes are encoded and unsafe path characters are normalized."New value: +"Name override; Non-ASCII bytes are encoded; unsafe characters normalized."
      • changedInput schema / properties / persistence / description
        Previous value: -"Write compressed artifact to .codebase-memory/graph.db.zst for team sharing. Teammates can bootstrap from the artifact instead of full re-indexing."New value: +"Write .codebase-memory/graph.db.zst."
      • changedInput schema / properties / repo_path / description
        Previous value: -"Path to the repository"New value: +"Repository path"
      • changedInput schema / properties / target_projects / description
        Previous value: -"Projects to search for cross-repo links (cross-repo-intelligence mode). Use [\"*\"] for all indexed projects. Run list_projects to see available projects."New value: +"Cross-repo targets; [\"*\"] means all."
    • Changedindex_status3 fields changed
      • addedInput schema / properties / diagnostics
        Added value: +{
+  "default": "none",
+  "description": "Coverage rows: counts, five samples, or up to 500.",
+  "enum": [
+    "none",
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / verbose / description
        Previous value: -"Include the git context block (worktree/shadow path variants). Only needed when debugging where an index lives — omitted by default to keep the status lean."New value: +"Add worktree/shadow Git paths for index-location debugging."
    • Changedlist_projects6 fields changed
      • addedInput schema / properties / detail
        Added value: +{
+  "default": "identity",
+  "description": "stats adds node/edge/database-size counts.",
+  "enum": [
+    "identity",
+    "stats"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / include_details
        Added value: +{
+  "default": false,
+  "description": "Alias for detail=stats: include branch, node/edge counts and database size. Slower.",
+  "type": "boolean"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 50,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / metadata_only
        Added value: +{
+  "default": false,
+  "description": "Compatibility: omit counts, size, and branch.",
+  "type": "boolean"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
    • Changedmanage_adr8 fields changed
      • changedInput schema / properties / content / description
        Previous value: -"Complete replacement document required by update"New value: +"Whole document for update"
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / mode / default
        Added value: +"outline"
      • changedInput schema / properties / mode / description
        Previous value: -"update replaces the entire ADR document; sections only lists existing headings"New value: +"outline pages headings; get reads; update replaces the whole document; set_sections rewrites only the named sections and leaves every other byte untouched (an identical repeated write is byte-identical, so retrying is safe); sections is legacy."
      • changedInput schema / properties / mode / enum
        Previous value: -[
-  "get",
-  "update",
-  "sections"
-]New value: +[
+  "outline",
+  "get",
+  "update",
+  "set_sections",
+  "sections"
+]
      • addedInput schema / properties / section_limit
        Added value: +{
+  "default": 50,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / section_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / section_updates
        Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "set_sections: section name -> new body. Any heading name works; names match exactly, including case.",
+  "type": "object"
+}
    • Changedquery_graph8 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Snapshot continuation; keep query/project/graph. Format, budget, and max_rows may change.",
+  "type": "string"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "description": "tree may use local @N+suffix prefix refs; json uses direct strings.",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / graph / description
        Previous value: -"Which graph to query: the code knowledge graph (default) or the missed graph (only files not fully indexed, laid out as their file structure)."New value: +"code graph (default) or missed coverage-gap file tree."
      • addedInput schema / properties / max_output_tokens
        Added value: +{
+  "description": "Sizing hint; hard ceiling is 4 UTF-8 bytes/token. Rows stay whole.",
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}
      • addedInput schema / properties / max_rows / default
        Added value: +200
      • changedInput schema / properties / max_rows / description
        Previous value: -"Optional row limit. Default: unlimited up to a 100k row ceiling. No offset support — use search_graph for paginated browsing."New value: +"Visible rows (default 200; max 99998); 0 uses the legacy maximum. Evaluation is unchanged."
      • addedInput schema / properties / max_rows / minimum
        Added value: +0
      • addedInput schema / properties / offset
        Added value: +{
+  "default": 0,
+  "description": "Live compatibility paging; cannot be combined with cursor.",
+  "minimum": 0,
+  "type": "integer"
+}
    • Changedsearch_code18 fields changed
      • removedInput schema / properties / context / description
        Removed value: -"Lines of context around each match (like grep -C). Only used in compact mode."
      • addedInput schema / properties / debug
        Added value: +{
+  "default": false,
+  "description": "Add scope_ms/scan_ms/enrich_ms phase timings.",
+  "type": "boolean"
+}
      • addedInput schema / properties / directory_limit
        Added value: +{
+  "default": 20,
+  "maximum": 64,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / directory_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • removedInput schema / properties / file_pattern / description
        Removed value: -"Glob for grep --include (e.g. *.go)"
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • removedInput schema / properties / limit / description
        Removed value: -"Max enriched results per call. Default 10. Response includes 'total_grep_matches' and 'total_results' so callers can detect truncation. No offset parameter — raise limit or narrow with file_pattern / path_filter to see more."
      • addedInput schema / properties / limit / maximum
        Added value: +500
      • addedInput schema / properties / match_limit
        Added value: +{
+  "default": 8,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / max_output_tokens
        Added value: +{
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}
      • removedInput schema / properties / mode / description
        Removed value: -"compact: signatures+metadata (default). full: with source. files: just file list."
      • removedInput schema / properties / path_filter / description
        Removed value: -"Regex filter on result file paths (e.g. ^src/ or \\.(go|ts)$)"
      • addedInput schema / properties / raw_content_offset
        Added value: +{
+  "description": "Raw-line byte offset; omit for match-centered preview.",
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / raw_limit
        Added value: +{
+  "default": 5,
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / raw_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / result_limit
        Added value: +{
+  "default": 10,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / result_offset
        Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / source_max_lines
        Added value: +{
+  "default": 20,
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
    • Changedsearch_graph14 fields changed
      • removedInput schema / properties / detail / description
        Removed value: -"ids: bare qualified-name enumeration (one column) — cheapest form for wide sweeps where per-row metadata is noise. default: full rows."
      • removedInput schema / properties / fields / description
        Removed value: -"Extra per-node property columns, e.g. complexity, cognitive, signature, docstring, return_type, is_test, lines(int). Core row columns (qn/label/file/lines/in/out) are always present — do not request them here. Missing values emit as empty cells."
      • removedInput schema / properties / format / description
        Removed value: -"Response encoding. tree (default): prefix-grouped text rows. json: the SAME tree model as structured JSON (groups + column-ordered row arrays)."
      • addedInput schema / properties / limit / default
        Added value: +50
      • removedInput schema / properties / limit / description
        Removed value: -"Max results per call. Default 50. Response carries 'total' (full match count) and 'has_more' (true if truncated) so callers can detect the limit and paginate."
      • addedInput schema / properties / limit / maximum
        Added value: +500
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedInput schema / properties / max_output_tokens
        Added value: +{
+  "default": 3200,
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}
      • removedInput schema / properties / offset / description
        Removed value: -"Skip the first N matching nodes. Combine with 'limit' to page: increment offset by limit and re-call while has_more is true."
      • addedInput schema / properties / offset / minimum
        Added value: +0
      • removedInput schema / properties / query / description
        Removed value: -"Natural-language or keyword full-text search using BM25 ranking. Tokens are split on whitespace; camelCase identifiers are indexed as individual words (updateCloudClient → update, cloud, client). Results are ranked with structural boosting: Functions/Methods +10, Routes +8, Classes/Interfaces +5. Noise labels (File/Folder/Module/Variable) are filtered out. When provided, name_pattern is ignored."
      • addedInput schema / properties / semantic_limit
        Added value: +{
+  "default": 50,
+  "maximum": 500,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / semantic_offset
        Added value: +{
+  "default": 0,
+  "maximum": 99998,
+  "minimum": 0,
+  "type": "integer"
+}
      • changedInput schema / properties / semantic_query / description
        Previous value: -"MUST be an ARRAY of keyword strings (e.g. [\"send\",\"pubsub\",\"publish\"]) — NOT a single string. Each keyword is scored independently via per-keyword min-cosine; results reflect functions that score well on ALL keywords. Requires moderate/full index mode. Results appear in the 'semantic_results' field (separate from 'results')."New value: +"Not with query."
    • Changedtrace_path11 fields changed
      • changedInput schema / properties / cursor / description
        Previous value: -"Resume token from a previous response's 'next' field. Pass it back with ALL other arguments identical to get the following page with no duplicates. Cursors outlive nothing: after a reindex you get a stale_cursor error — just re-run the original query."New value: +"Pass next/next_cursor with traversal args unchanged; budget may increase."
      • addedInput schema / properties / depth / maximum
        Added value: +15
      • addedInput schema / properties / depth / minimum
        Added value: +1
      • changedInput schema / properties / format / description
        Previous value: -"Response encoding. tree (default): prefix-grouped text rows. json: the SAME tree model as structured JSON (groups + column-ordered row arrays)."New value: +"tree chooses smaller complete direct/grouped output; json uses stable grouped tables."
      • changedInput schema / properties / include_evidence / description
        Previous value: -"Add how each hop was resolved: a strategy class (lsp | language_rule | heuristic | unresolved) and the resolver's confidence. Off by default — it adds two columns per row. Use it to judge whether an edge is trustworthy, not to find edges."New value: +"Add resolver class and confidence."
      • removedInput schema / properties / include_tests / description
        Removed value: -"Include test files in results. When false (default), test files are filtered out. When true, test nodes are included with a test column/marker."
      • changedInput schema / properties / limit / description
        Previous value: -"Rows per page. callees_total/callers_total always carry the exact full counts; when a page is truncated the response carries next — see cursor."New value: +"Rows/page; gte flags the 5000-node engine ceiling."
      • addedInput schema / properties / max_output_tokens
        Added value: +{
+  "default": 3200,
+  "description": "Sizing hint; hard ceiling is 4 UTF-8 bytes/token. Evidence/args yield before nearest graph rows.",
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}
      • changedInput schema / properties / mode / description
        Previous value: -"calls: follow CALLS edges. data_flow: follow CALLS+DATA_FLOWS with arg expressions. cross_service: follow HTTP_CALLS+ASYNC_CALLS+DATA_FLOWS through Routes, plus CROSS_* cross-repo edges (CROSS_HTTP_CALLS/ASYNC_CALLS/CHANNEL/GRPC_CALLS/GRAPHQL_CALLS/TRPC_CALLS) to hop into other services."New value: +"calls, argument-aware data_flow, or service edges."
      • changedInput schema / properties / parameter_name / description
        Previous value: -"For data_flow mode: scope trace to a specific parameter name"New value: +"data_flow parameter filter."
      • changedInput schema / properties / risk_labels / description
        Previous value: -"Add risk classification (CRITICAL/HIGH/MEDIUM/LOW) based on hop distance"New value: +"Add hop-risk labels."
  2. 15 tool updatesv0.10.4
    • Changedcheck_index_coverage4 fields changed
      • removedInput schema / anyOf
        Removed value: -[
-  {
-    "required": [
-      "paths"
-    ]
-  },
-  {
-    "required": [
-      "scopes"
-    ]
-  }
-]
      • changedInput schema / properties / paths / description
        Previous value: -"Repository-relative files to check exactly."New value: +"Repository-relative files to check exactly. Required if 'scopes' is omitted."
      • changedInput schema / properties / scopes / description
        Previous value: -"Repository-relative path prefixes; use . for the project root."New value: +"Repository-relative path prefixes; use . for the project root. Required if 'paths' is omitted."
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changeddelete_project1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changeddetect_changes1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedget_architecture1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedget_code_snippet1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedget_graph_schema1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedindex_repository1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedindex_status1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedingest_traces1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedlist_projects1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedmanage_adr1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedquery_graph1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedsearch_code2 fields changed
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedsearch_graph1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
    • Changedtrace_path1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  3. 11 tool updatesv0.10.0
    • Addedcheck_index_coverage
    • Addeddelete_project
    • Addeddetect_changes
    • Changedget_architecture2 fields changed
      • changedInput schema / properties / aspects / description
        Previous value: -"Aspects to include. 'all' = everything; 'overview' = compact summary (all except file_tree); omit = all."New value: +"Aspects to include. 'all' = everything; 'overview' = compact summary (all except file_tree); omit = all. 'cycles' is opt-in ONLY (never via all/overview): it scans the whole call graph for circular CALLS dependencies (SCCs of size > 1)."
      • changedInput schema / properties / aspects / items / enum
        Previous value: -[
-  "all",
-  "overview",
-  "structure",
-  "dependencies",
-  "routes",
-  "languages",
-  "packages",
-  "entry_points",
-  "hotspots",
-  "boundaries",
-  "layers",
-  "file_tree",
-  "clusters"
-]New value: +[
+  "all",
+  "overview",
+  "structure",
+  "dependencies",
+  "routes",
+  "languages",
+  "packages",
+  "entry_points",
+  "hotspots",
+  "boundaries",
+  "layers",
+  "file_tree",
+  "clusters",
+  "cycles"
+]
    • Addedindex_status
    • Addedingest_traces
    • Addedlist_projects
    • Addedmanage_adr
    • Changedquery_graph1 field changed
      • addedInput schema / properties / graph
        Added value: +{
+  "default": "code",
+  "description": "Which graph to query: the code knowledge graph (default) or the missed graph (only files not fully indexed, laid out as their file structure).",
+  "enum": [
+    "code",
+    "missed"
+  ],
+  "type": "string"
+}
    • Changedsearch_graph4 fields changed
      • addedInput schema / properties / detail
        Added value: +{
+  "default": "default",
+  "description": "ids: bare qualified-name enumeration (one column) — cheapest form for wide sweeps where per-row metadata is noise. default: full rows.",
+  "enum": [
+    "ids",
+    "default"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / fields
        Added value: +{
+  "description": "Extra per-node property columns, e.g. complexity, cognitive, signature, docstring, return_type, is_test, lines(int). Core row columns (qn/label/file/lines/in/out) are always present — do not request them here. Missing values emit as empty cells.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "description": "Response encoding. tree (default): prefix-grouped text rows. json: the SAME tree model as structured JSON (groups + column-ordered row arrays).",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / limit / description
        Previous value: -"Max results per call. Default 200. Response carries 'total' (full match count) and 'has_more' (true if truncated) so callers can detect the limit and paginate."New value: +"Max results per call. Default 50. Response carries 'total' (full match count) and 'has_more' (true if truncated) so callers can detect the limit and paginate."
    • Changedtrace_path5 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Resume token from a previous response's 'next' field. Pass it back with ALL other arguments identical to get the following page with no duplicates. Cursors outlive nothing: after a reindex you get a stale_cursor error — just re-run the original query.",
+  "type": "string"
+}
      • addedInput schema / properties / format
        Added value: +{
+  "default": "tree",
+  "description": "Response encoding. tree (default): prefix-grouped text rows. json: the SAME tree model as structured JSON (groups + column-ordered row arrays).",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / include_evidence
        Added value: +{
+  "default": false,
+  "description": "Add how each hop was resolved: a strategy class (lsp | language_rule | heuristic | unresolved) and the resolver's confidence. Off by default — it adds two columns per row. Use it to judge whether an edge is trustworthy, not to find edges.",
+  "type": "boolean"
+}
      • changedInput schema / properties / include_tests / description
        Previous value: -"Include test files in results. When false (default), test files are filtered out. When true, test nodes are included with is_test=true marker."New value: +"Include test files in results. When false (default), test files are filtered out. When true, test nodes are included with a test column/marker."
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 100,
+  "description": "Rows per page. callees_total/callers_total always carry the exact full counts; when a page is truncated the response carries next — see cursor.",
+  "maximum": 5000,
+  "minimum": 1,
+  "type": "integer"
+}
  4. 14 tool updatesv0.9.0
    • Removeddelete_project
    • Removeddetect_changes
    • Changedget_architecture4 fields changed
      • addedInput schema / properties / aspects / description
        Added value: +"Aspects to include. 'all' = everything; 'overview' = compact summary (all except file_tree); omit = all."
      • addedInput schema / properties / aspects / items / enum
        Added value: +[
+  "all",
+  "overview",
+  "structure",
+  "dependencies",
+  "routes",
+  "languages",
+  "packages",
+  "entry_points",
+  "hotspots",
+  "boundaries",
+  "layers",
+  "file_tree",
+  "clusters"
+]
      • addedInput schema / properties / path
        Added value: +{
+  "description": "Optional directory prefix to scope architecture (e.g. apps/hoa)",
+  "type": "string"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_code_snippet1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedget_graph_schema1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedindex_repository2 fields changed
      • addedInput schema / properties / name
        Added value: +{
+  "description": "Override the derived project name. Non-ASCII bytes are encoded and unsafe path characters are normalized.",
+  "type": "string"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Removedindex_status
    • Removedingest_traces
    • Removedlist_projects
    • Removedmanage_adr
    • Changedquery_graph1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedsearch_code1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedsearch_graph1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
    • Changedtrace_path2 fields changed
      • changedInput schema / properties / mode / description
        Previous value: -"calls: follow CALLS edges. data_flow: follow CALLS+DATA_FLOWS with arg expressions. cross_service: follow HTTP_CALLS+ASYNC_CALLS+DATA_FLOWS through Routes."New value: +"calls: follow CALLS edges. data_flow: follow CALLS+DATA_FLOWS with arg expressions. cross_service: follow HTTP_CALLS+ASYNC_CALLS+DATA_FLOWS through Routes, plus CROSS_* cross-repo edges (CROSS_HTTP_CALLS/ASYNC_CALLS/CHANNEL/GRPC_CALLS/GRAPHQL_CALLS/TRPC_CALLS) to hop into other services."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  5. 14 tool updatesv1.0.0
    • First observeddelete_project
    • First observeddetect_changes
    • First observedget_architecture
    • First observedget_code_snippet
    • First observedget_graph_schema
    • First observedindex_repository
    • First observedindex_status
    • First observedingest_traces
    • First observedlist_projects
    • First observedmanage_adr
    • First observedquery_graph
    • First observedsearch_code
    • First observedsearch_graph
    • First observedtrace_path
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 17 tools

Disambiguation4/5

Most tools have clearly distinct purposes, but search_graph and search_code both perform search (symbol vs text) and query_graph vs trace_path both involve graph traversal, which could cause misselection. Descriptions help differentiate them, but a couple of pairs remain potentially confusing.

Naming Consistency4/5

Tool names mostly follow a snake_case verb_noun pattern (get_architecture, index_repository, search_graph, delete_project). Minor deviations exist: index_status is ambiguous (verb vs noun) and manage_adr is vague, but overall the pattern is predictable.

Tool Count4/5

17 tools is slightly above the ideal 3-15 range, but each tool has a specific role in codebase indexing, querying, and analysis. The count feels a bit heavy but not excessive given the domain breadth.

Completeness4/5

The surface covers core workflows: indexing, searching, querying, tracing, snippet retrieval, architecture overview, project management, and diff detection. Minor gaps exist, such as ingest_traces not implementing edge creation and no direct file listing tool, but most operations can be completed or worked around.

Maintenance

ActivityActive
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers

  • trace-mcp

    nikolai-vysotskyi
    A
    license
    A
    quality
    A
    maintenance
    Framework-aware code intelligence MCP server that builds a cross-language dependency graph from source code. 53 integrations (Laravel, Django, Rails, Spring, NestJS, Next.js, and more) across 68 languages. 100+ tools for navigation, impact analysis, refactoring, security scanning, session memory, and CI/PR reports — up to 97% token reduction.
    29
    3,198 npm
    183
    MIT

  • Orihime

    srinivasan-sundaresan95
    A
    license
    A
    quality
    C
    maintenance
    Cross-repository code knowledge graph MCP server for Java, Kotlin, JavaScript, and TypeScript. Indexes source code into embedded KuzuDB via tree-sitter and exposes 30+ tools for call-flow tracing, multi-hop taint analysis (OWASP/CWE/PCI/STIG), entry-point reachability filtering, performance hotspot detection, and license compliance — without reading source files. 95% fewer tokens vs source-read
    33
    1
    MIT

  • code-graph-mcp

    sdsrss
    A
    license
    Not graded
    quality
    A
    maintenance
    A high-performance code knowledge graph server implementing MCP, indexing codebases into a structured AST knowledge graph with semantic search, call graph traversal, and HTTP route tracing.
    1,612 npm
    77
    MIT

Appeared in Searches