Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DeusData/codebase-memory-mcp/llms.txt

Use this file to discover all available pages before exploring further.

Codebase Memory MCP builds a persistent SQLite knowledge graph by parsing your codebase with tree-sitter and, for 11 languages, with Hybrid LSP semantic type resolution on top. The result is a property graph where every symbol, file, package, and infrastructure resource becomes a node and every relationship — call, import, inheritance, HTTP link — becomes a typed directed edge. Understanding the schema lets you write precise Cypher queries and interpret search_graph results correctly.
Run get_graph_schema on any indexed project to see the exact node labels, edge types, property definitions, and counts present in that specific index. Schema varies by language and project structure.

Node Labels

Each node has exactly one label from the set below. The qualified_name property uniquely identifies a node within a project store.
LabelDescriptionKey Properties
ProjectRoot node representing an indexed repositoryname, path
PackagePackage manager dependency (npm, Go module, Cargo crate, etc.)name, version, ecosystem
FolderDirectory node in the file treepath, name
FileSource filepath, language, size
ModuleModule or namespace grouping (also used for Kustomize overlays)name
ClassClass or struct definitionname, file, line
FunctionTop-level function or procedurename, file, line, params, returns
MethodMethod defined on a class or structname, file, line, class
InterfaceInterface or abstract type declarationname, file
EnumEnumeration definitionname, file
TypeType alias or typedefname, file
RouteHTTP, gRPC, GraphQL, or tRPC endpointname, method, path, file
ResourceKubernetes or infrastructure resourcekind, apiVersion

Complexity properties on Function and Method

Every Function and Method node carries queryable complexity metrics extracted during indexing:
PropertyDescription
cyclomaticClassic McCabe cyclomatic complexity
cognitiveCognitive complexity (nesting-weighted)
loop_countTotal loop constructs
loop_depthMaximum nested-loop depth (polynomial-degree proxy)
transitive_loop_depthWorst-case nested-loop degree propagated along CALLS edges
linear_scan_in_loopCount of find/contains/indexOf-style scans inside a loop (hidden O(n²) signal)
alloc_in_loopAllocations or appends inside a loop
recursion_in_loopSelf-call inside a loop
unguarded_recursionRecursion with no conditionally-guarded base case
param_countNumber of parameters (structure smell)
max_access_depthMaximum member access chain depth (structure smell)

Edge Types

Edges are directed and typed. The source and target labels listed are the most common pairings; the graph engine does not enforce strict source/target constraints.

Structural edges

EdgeFromToDescription
CONTAINS_PACKAGEProjectPackageProject declares this dependency
CONTAINS_FOLDERProject / FolderFolderDirectory containment
CONTAINS_FILEFolderFileFile belongs to directory
DEFINESFile / ModuleFunction / Class / Interface / Enum / TypeFile or module defines a symbol
DEFINES_METHODClassMethodClass contains this method
MEMBER_OFFunction / VariableClass / ModuleSymbol belongs to a container
IMPORTSFile / ModuleFile / Module / PackageImport or use declaration

Semantic edges

EdgeFromToDescription
CALLSFunction / MethodFunction / MethodDirect function/method call
ASYNC_CALLSFunction / MethodFunction / RouteAsync or event-driven call
HTTP_CALLSFunction / MethodRouteStatic HTTP call-site linked to a Route node
IMPLEMENTSClassInterfaceClass implements an interface
INHERITSClassClassInheritance relationship
USES_TYPEFunction / Method / ClassType / Class / InterfaceType reference
HANDLESFunction / MethodRouteFunction is the handler for an HTTP route
USAGEanyanyGeneral usage reference
TESTSFunction / MethodFunction / ClassTest function targeting a symbol

Infrastructure and config edges

EdgeFromToDescription
CONFIGURESFileResource / ModuleConfig file configures a resource
WRITESFunction / MethodFile / ResourceCode writes to a file or resource

Data flow and analysis edges

EdgeFromToDescription
DATA_FLOWSFunction / MethodFunction / MethodData flow with arg-to-param mapping and field access chains
FILE_CHANGES_WITHFileFileFiles that frequently change together (git co-change analysis)
SIMILAR_TOFunction / MethodFunction / MethodMinHash + LSH near-clone detection, Jaccard-scored
SEMANTICALLY_RELATEDFunction / MethodFunction / MethodVocabulary-mismatch semantic similarity, score ≥ 0.80

Event / channel edges

EdgeFromToDescription
EMITSFunction / MethodModule / VariableEmits an event or publishes to a channel
LISTENS_ONFunction / MethodModule / VariableSubscribes to an event or channel

Cross-repo edges

Cross-repo edges link nodes across multiple repositories indexed under the same store. They are created by index_repository in cross-repo-intelligence mode.
EdgeDescription
CROSS_HTTP_CALLSHTTP call-site in one service linking to a Route in another
CROSS_ASYNC_CALLSAsync/event call crossing service boundaries
CROSS_CHANNELChannel EMITSLISTENS_ON pairing across services
CROSS_GRPC_CALLSgRPC call crossing service boundaries
CROSS_GRAPHQL_CALLSGraphQL operation crossing service boundaries
CROSS_TRPC_CALLStRPC call crossing service boundaries

Qualified Names

Every node has a qualified_name property that uniquely identifies it within a project store. The format is:
<project>.<path_parts>.<symbol_name>
For example, a function ProcessOrder in src/handlers/order.go in a project named myapp would have the qualified name:
myapp.src.handlers.ProcessOrder
Qualified names are used by get_code_snippet to retrieve source code, and appear in search_graph and query_graph results. Always discover the qualified name first via search_graph, then pass it to get_code_snippet.

Discovery workflow

# Step 1: find the qualified name with a regex search
codebase-memory-mcp cli search_graph '{
  "name_pattern": ".*ProcessOrder.*",
  "project": "myapp"
}'

# Step 2: get the source code using the qualified name from the results
codebase-memory-mcp cli get_code_snippet '{
  "qualified_name": "myapp.src.handlers.ProcessOrder",
  "project": "myapp"
}'
Or using a Cypher query to find qualified names:
MATCH (f:Function)
WHERE f.name =~ '.*ProcessOrder.*'
RETURN f.name, f.qualified_name, f.file

Querying the Schema at Runtime

get_graph_schema returns the live schema for any indexed project:
codebase-memory-mcp cli get_graph_schema '{"project": "myapp"}'
The response includes:
  • Node labels — all labels present, with their property names and counts
  • Edge types — all relationship types present, with example source → target patterns
  • Total counts — aggregate node and edge counts for the project
This is the authoritative source for what is indexed — use it before writing Cypher queries to avoid querying labels or edge types that don’t exist in the current index.

Infrastructure-as-Code Nodes

Dockerfiles, Kubernetes manifests, and Kustomize overlays are indexed as first-class graph nodes:
  • Dockerfile — parsed as File nodes; FROM stages and RUN commands create structured nodes
  • Kubernetes manifestsResource nodes with kind and apiVersion properties; CONFIGURES edges link them to application code
  • Kustomize overlaysModule nodes with IMPORTS edges to referenced base resources
This means you can write Cypher queries like:
MATCH (f:Function)-[:CONFIGURES]->(r:Resource {kind: 'Deployment'})
RETURN f.name, r.name

Build docs developers (and LLMs) love