# Graph Data Model Node Labels and Edge Types in codebase-memory-mcp

> Explore the graph data model in codebase-memory-mcp! Understand node labels and edge types like CALLS and IMPORTS to map codebase interactions for deep insights.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: api-reference
- Published: 2026-07-30

---

**The `codebase-memory-mcp` engine constructs a typed knowledge graph using 13 distinct node labels (from `Project` to `Resource`) and 17 relationship types (including `CALLS`, `IMPORTS`, and `HTTP_CALLS`) to map every structural and runtime interaction within your codebase.**

The `DeusData/codebase-memory-mcp` open-source tool transforms raw source code into a queryable property graph by parsing ASTs with tree-sitter and enriching them with LSP type resolution. Understanding the graph data model node labels and edge types is essential for writing effective Cypher queries against the embedded SQLite backend. This model captures everything from high-level project structure down to individual function calls and HTTP endpoints.

## Primary Node Labels

The knowledge graph assigns every entity a specific label representing its semantic role in the codebase. These labels are enumerated in the [`README.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/README.md) under the *Graph Data Model* section and consumed by the CLI entry point in [`pkg/go/cmd/codebase-memory-mcp/main.go`](https://github.com/DeusData/codebase-memory-mcp/blob/main/pkg/go/cmd/codebase-memory-mcp/main.go).

- **Project**: The root node representing the entire indexed repository.
- **Package**: Language-specific packaging units such as npm packages or Go modules.
- **Folder**: Directory containers within the file system hierarchy.
- **File**: Individual source files tracked by the indexer.
- **Module**: Logical groupings inside files, including ES-modules or Python modules.
- **Class**: Object-oriented class definitions extracted from the AST.
- **Function**: Top-level functions declared in the global or module scope.
- **Method**: Functions defined as members of classes or similar constructs.
- **Interface**: Protocol, trait, or interface definitions.
- **Enum**: Enumeration type declarations.
- **Type**: Type aliases, structs, and other composite types.
- **Route**: HTTP or RPC entry points such as web handlers and API endpoints.
- **Resource**: Kubernetes manifests, infrastructure definitions, and external resources.

## Edge Types Defining Relationships

Edges connect nodes with typed relationships that describe how code entities interact. The full enumeration appears in the repository documentation, while the runtime constants are typically defined in files like [`internal/cbm/graph/schema.go`](https://github.com/DeusData/codebase-memory-mcp/blob/main/internal/cbm/graph/schema.go) (search the codebase for `CALLS` to locate exact definitions).

- **CONTAINS_PACKAGE**: Links a `Project` to its constituent `Package` nodes.
- **CONTAINS_FOLDER**: Connects `Project` or `Package` nodes to `Folder` directories.
- **CONTAINS_FILE**: Maps `Folder` nodes to their contained `File` entities.
- **DEFINES**: Associates `File` or `Module` nodes with the symbols they declare (`Class`, `Function`, `Enum`, `Type`).
- **DEFINES_METHOD**: Links `Class` nodes to their `Method` members.
- **IMPORTS**: Tracks dependency relationships from `File` nodes to imported `Package` or `Module` entities.
- **CALLS**: Represents invocation relationships between `Function` and `Method` nodes.
- **HTTP_CALLS**: Captures when a function invokes external HTTP endpoints.
- **ASYNC_CALLS**: Marks asynchronous invocations such as goroutines or awaited promises.
- **IMPLEMENTS**: Connects `Class` nodes to `Interface` definitions they fulfill.
- **HANDLES**: Maps `Route` nodes to the `Function` implementations that process them.
- **USAGE / USES_TYPE**: Indicates when a symbol references a specific type.
- **CONFIGURES**: Links `Resource` nodes to their configuration files or parameters.
- **WRITES**: Tracks file system write operations from functions to target files.
- **MEMBER_OF**: Associates methods and fields with their parent `Class`.
- **TESTS**: Connects test files or functions to the production code they verify.
- **FILE_CHANGES_WITH**: Associates `File` nodes with commits or change sets that modified them.

## Querying the Graph with CLI Commands

Once you have indexed a project using `codebase-memory-mcp index_repository --repo-path .`, you can query these nodes and edges using the CLI. The following examples demonstrate practical usage of the graph data model.

### List All Available Node Labels

Retrieve the complete schema to verify which labels exist in your indexed project:

```bash
codebase-memory-mcp cli get_graph_schema --project my-repo | jq '.node_labels'

```

Expected output:

```json
["Project","Package","Folder","File","Module","Class","Function","Method","Interface","Enum","Type","Route","Resource"]

```

### Trace Function Call Chains

Find all functions that invoke a specific named function using the `CALLS` edge type:

```bash
codebase-memory-mcp cli query_graph \
  --project my-repo \
  --query "MATCH (f:Function)-[:CALLS]->(g:Function) WHERE g.name = 'processOrder' RETURN f.name"

```

### Discover HTTP Dependencies

Identify external HTTP endpoints invoked by your code through the `HTTP_CALLS` relationship:

```bash
codebase-memory-mcp cli query_graph \
  --project my-repo \
  --query "MATCH (f:Function)-[:HTTP_CALLS]->(e:Resource) RETURN f.name, e.url"

```

### Map Route Handlers

Retrieve the complete call graph for an HTTP route by traversing `HANDLES` and subsequent `CALLS` edges:

```bash
codebase-memory-mcp cli trace_path \
  --project my-repo \
  --function-name "GET /api/orders" \
  --direction both \
  --depth 4

```

### Analyze Import Graphs

Show all package dependencies for a specific source file using the `IMPORTS` edge:

```bash
codebase-memory-mcp cli query_graph \
  --project my-repo \
  --query "MATCH (f:File)-[:IMPORTS]->(p:Package) WHERE f.path = 'src/app/main.go' RETURN p.name"

```

## Implementation Details and Source Locations

The graph data model is formally documented in the **README.md** at the repository root, specifically within the *Graph Data Model* section. This documentation serves as the source of truth for both the node taxonomy and relationship ontology.

Runtime constants and schema definitions for these labels and edge types are implemented in the Go source tree. While [`internal/cbm/graph/schema.go`](https://github.com/DeusData/codebase-memory-mcp/blob/main/internal/cbm/graph/schema.go) contains the struct definitions (locatable by searching for constants like `CALLS` or `IMPORTS`), the CLI entry point in [`pkg/go/cmd/codebase-memory-mcp/main.go`](https://github.com/DeusData/codebase-memory-mcp/blob/main/pkg/go/cmd/codebase-memory-mcp/main.go) handles command dispatch to the graph query engine. Configuration options affecting which nodes and edges are materialized during indexing are documented in [`docs/CONFIGURATION.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/docs/CONFIGURATION.md).

## Summary

- **codebase-memory-mcp** builds a typed knowledge graph from AST and LSP data, storing it in an in-memory SQLite database.
- The graph recognizes **13 primary node labels** ranging from `Project` down to `Resource` and `Route`.
- **17 distinct edge types** capture relationships including containment (`CONTAINS_FILE`), invocation (`CALLS`, `ASYNC_CALLS`), dependency (`IMPORTS`), and testing (`TESTS`).
- You query this model using Cypher-like syntax via the CLI, with schema definitions residing in the README and implementation code in the Go package tree.

## Frequently Asked Questions

### What query language does codebase-memory-mcp use?

The tool supports **Cypher-like syntax** for graph traversal, allowing you to write `MATCH` statements using the node labels and edge types defined in the schema. This is executed against the embedded SQLite graph store via the `query_graph` CLI command.

### Where are the node labels and edge types defined in the source code?

The formal specification lives in the [`README.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/README.md) under the *Graph Data Model* section. The runtime constants are implemented in Go files such as [`internal/cbm/graph/schema.go`](https://github.com/DeusData/codebase-memory-mcp/blob/main/internal/cbm/graph/schema.go), which you can locate by searching for edge type strings like `CALLS` or `IMPORTS` in the repository.

### Can I extend the graph data model with custom labels or edges?

Currently, the set of node labels and edge types is **fixed** and defined by the parser and indexer implementation. However, configuration options in [`docs/CONFIGURATION.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/docs/CONFIGURATION.md) allow you to control which types of entities are indexed and which relationships are materialized, effectively filtering the graph without modifying the underlying schema.

### How does the graph handle asynchronous operations?

Asynchronous calls are explicitly modeled using the **`ASYNC_CALLS`** edge type, which connects `Function` or `Method` nodes to targets invoked via constructs like `await`, `async` blocks, or goroutines. This distinguishes concurrent invocation paths from standard synchronous `CALLS` relationships.