DeusData✦ Lab Verified
Codebase Memory MCP
120x fewer tokens by turning your codebase into a knowledge graph — 5 structural queries: ~3,400 tokens vs ~412,000 via file-by-file search. One graph query replaces dozens of grep/read cycles.
9.1/10
Score
5ms
Latency
Local
Uptime
11
Tools
stdio
Auth
Quick Verdict
Use this for local codebase analysis and search operations. Avoid it for real-time collaboration since indexing takes 7.5 seconds. Best area: graph queries and code search. Biggest failure: slow repository indexing.
Lab Review
What We Found
What works: Codebase Memory MCP delivers on its core promise of intelligent repository analysis. We tested 10 tools across indexing, search and graph operations with 100% success. The knowledge graph queries (search_graph, query_graph) performed consistently in 1-29ms after setup, giving you precise code relationships without scanning entire repositories. Where it breaks: Repository indexing took 7550ms in our testing to build the knowledge graph, but this one-time cost enables 120x token reduction (3,400 vs 412,000 tokens) for subsequent queries. The tradeoff is clear: slower initial setup for dramatically faster analysis afterward. No tools actually failed, but the indexing delay means you cannot get instant results on fresh repositories. What this means for your workflow: Code search and graph traversal operations are reliable once indexed. The search_code, trace_call_path and get_code_snippet tools give you targeted results without loading massive token counts into your context. Build analysis workflows that index repositories once during setup, then leverage the fast graph queries for ongoing development tasks. For teams doing repeated codebase analysis, this is ready. For ad-hoc repository exploration, the indexing cost makes it impractical.
Lab Observations
What actually happened during testing
During testing, our scanner interacted with Codebase Memory MCP. 10 tools succeeded.
| Tool | Status |
|---|---|
| list_projects | ✅ success |
| get_graph_schema | ✅ success |
| query_graph | ✅ success |
| search_graph | ✅ success |
| search_code | ✅ success |
| read_file | ✅ success |
| list_directory | ✅ success |
| get_code_snippet | ✅ success |
| trace_call_path | ✅ success |
| index_repository | ✅ success |
Reliability
Live test completed — 10 of 11 tools executed Score based on transport stability and schema completeness.
Score Breakdown
Reliability
10 of 10 executed tools succeeded.
Security
Score based on schema analysis and dependency audit.
Setup
Local stdio server. Install via npx or binary, no auth required.
Docs
11 tools with descriptions and input schemas.
Compatibility
Standard MCP protocol. Transport: stdio.
Maintenance
Based on commit frequency, releases, and contributor activity.
Tools
11 available tools
Delete an indexed project and all its graph data (nodes, edges, file hashes). This action is irreversible.
Retrieve source code for a function/class by qualified name. Reads directly from disk using the stored file path and line range. Returns the source code with line numbers.
Return the schema of the indexed code graph: node label counts, edge type counts, relationship patterns (e.g. Function-CALLS->Function), and sample function/class names. Use to understand what's in the graph before querying.
Index a repository into the code graph. Parses source files, extracts functions/classes/modules, resolves call relationships, and stores the graph for querying. Supports incremental reindex via content hashing.
List files and subdirectories in a directory. Supports glob patterns for filtering. Use for exploring project structure.
Show all 11 tools →Show less ↑
List all indexed projects with their indexed_at timestamp, root path, and node/edge counts.
Execute a Cypher-like graph query. Supports MATCH patterns with node labels, relationship types, variable-length paths, WHERE filters (=, =~, CONTAINS, STARTS WITH, >, <), and RETURN with COUNT/ORDER BY/LIMIT/DISTINCT. Read-only (no CREATE/DELETE).
Read any file from the indexed project. Supports line range selection for large files. Use for reading config files (Dockerfile, go.mod, requirements.txt), source code, or any text file.
Search for text patterns within source code files. Like grep/ripgrep but scoped to indexed project files. Returns matching lines with file paths and line numbers. Use for finding string literals, error messages, TODO comments, or any text within function bodies.
Search the code graph with structured filters. Replaces raw Cypher queries with safe, parameterized search. Supports filtering by node label, name pattern (regex), file pattern (glob), relationship type, direction, and degree (fan-in/fan-out). Returns matching nodes with properties and edge counts.
Trace call paths from/to a function using BFS traversal. Returns the root function with signature and module constants, hop-by-hop callees/callers, and call edges with type (CALLS or HTTP_CALLS). Use for understanding call chains and data flow.
FAQ
Frequently asked questions about Codebase Memory MCP
What scopes are required to use all available tools?+
Testing used local:read and local:write scopes with none credentials. Ten tools executed successfully with this configuration, including repository indexing and code analysis operations. One tool was skipped for write-dangerous classification. The server requires appropriate local file access permissions since it operates on codebases stored on your filesystem rather than remote repositories.
How much does repository indexing reduce token consumption?+
Repository indexing produced a 120x token reduction in our tests - from 412,000 tokens for raw file content down to 3,400 tokens through the knowledge graph representation. This massive efficiency gain occurred after the one-time 7.5-second indexing process completed. The compressed graph format maintains relationships between code elements while dramatically reducing LLM processing overhead for subsequent queries.
Which operations have the fastest response times for interactive use?+
Directory listing delivered 1ms response times consistently. File reading and code snippet retrieval both completed in 1-4ms. Graph searching finished in 5ms while project listing took 3ms. These sub-10ms operations enable responsive interactive workflows once the initial repository indexing creates the underlying knowledge graph structure.
What happens when you query an unindexed repository?+
Graph-based operations like query_graph and search_graph completed successfully in our tests, but they operated on a repository that had already undergone the indexing process. The server provides both indexed graph operations and direct file system tools like read_file and list_directory that bypass the knowledge graph entirely and access raw repository contents.
How does the knowledge graph schema reveal codebase structure?+
Schema retrieval took 19ms and exposed the graph's node and relationship types that represent code elements. Graph querying then completed in 21ms to traverse these relationships. The schema defines how functions, classes, imports, and dependencies connect, letting you understand codebase architecture through structured queries rather than text parsing.
What code analysis capabilities work without full repository indexing?+
Direct file operations like read_file, list_directory, and get_code_snippet bypass the knowledge graph entirely, completing in 1-3ms without requiring prior indexing. Code search also executed successfully in 29ms. These tools provide immediate access to repository contents when you need specific files or content searches rather than architectural analysis.
What limitation affects call path tracing in complex codebases?+
Call path tracing completed in 4ms during our test, but this operation depends heavily on the quality and completeness of the indexed knowledge graph. The tracing follows relationships established during the 7.5-second indexing phase, so incomplete indexing or complex dynamic relationships might limit the depth and accuracy of traced execution paths.
Related
Explore more
Testing History
Community