| name | deusdata--codebase-memory-mcp |
| description | How to install and use codebase-memory-mcp — a single-binary MCP server that indexes a codebase into a persistent tree-sitter + Hybrid-LSP knowledge graph (158 languages), answering structural queries (call graph, dead code, HTTP/gRPC/GraphQL route linking, ADRs, Cypher-like queries) in sub-millisecond time with ~10x fewer tokens than file-by-file grep/read exploration. Triggers on: 'index this codebase', 'codebase memory mcp', 'code knowledge graph', 'find callers of', 'call graph', 'dead code detection', 'trace HTTP route', 'cypher query codebase', 'architecture overview mcp', 'deusdata codebase-memory', 'install codebase-memory-mcp'. |
| origin | DeusData/codebase-memory-mcp (MIT) |
| license | MIT |
| version | 1.0.0 |
| compatibility | yana-ai >= 0.41.0 |
| allowed-tools | Bash, Read |
codebase-memory-mcp — Installable Code Knowledge Graph
Source: DeusData/codebase-memory-mcp (MIT)
Tier: TIER 3 — PRODUCTIVITY
Single static binary (C, zero runtime deps) that indexes a repo into a persistent
knowledge graph and exposes it via 14 MCP tools. This is an install-and-wire-up
skill, not a content-porting one — the skill's job is knowing when reaching for this
MCP server beats a normal grep/read exploration loop, and how to set it up safely.
Do NOT use for: general multimodal knowledge graphs over PDFs/screenshots/diagrams
— see graphify-knowledge-graph for that broader, non-code-specific tool. Do NOT use
for a one-off single-file read — the value here is structural, cross-file queries on a
codebase already indexed; indexing overhead isn't worth it for a single lookup.
When this beats grep/read
Question shape → codebase-memory-mcp tool
─────────────────────────────────────────────────────────────────
"Who calls this function?" → search_graph (CALLS edges)
"What's dead code in this module?" → dead code detection tool
"What does this git diff actually risk?"→ detect_changes (impact mapping)
"What are the HTTP routes and their → get_architecture / cross-service
handlers across services?" HTTP_CALLS edges
"Find functions semantically similar → semantic_query (bundled embeddings,
to X, no exact name match" no API key needed)
"MATCH (f:Function)-[:CALLS]->(g) → search_graph (Cypher-like query
WHERE f.name = 'main' RETURN g.name" language)
Per the project's own benchmark (arXiv:2603.27277, 31 real repos): ~10x fewer tokens
and ~2x fewer tool calls vs. file-by-file exploration, 83% answer quality. Reach for
it once a codebase is indexed and the question is structural (calls/imports/routes/
dead-code), not for content questions (what does this comment say).
Install
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash -s -- --ui
Per 44-supply-chain-vetting.md / dependency-vetting-law.md: this is a pipe-to-shell
install pattern, normally a hard-block trigger. Before running it for anh, verify
provenance first — release binaries are signed, checksummed, and VirusTotal-scanned
(per the repo's own README claims), and the repo has SLSA 3 + OpenSSF Scorecard badges.
( — this is exactly the "remote code execution"
pattern hard-blocks). Prefer the manual install path
(download the signed release archive, inspect, then run its bundled ) when
in doubt, or ask anh to run it himself via the prefix.
