# Node Labels in the Codebase-Memory-MCP Graph Schema: Complete Reference

> Explore the 11 node labels in the codebase-memory-mcp graph schema: file, function, class, struct, enum, typedef, variable, namespace, module, token, and embedding. Understand your codebase structure.

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

---

**The codebase-memory-mcp graph schema defines 11 canonical node labels—`file`, `function`, `class`, `struct`, `enum`, `typedef`, `variable`, `namespace`, `module`, `token`, and `embedding`—that categorize source-code entities within the `cbm_gbuf_node_t` structure.**

The graph schema in `DeusData/codebase-memory-mcp` organizes source code into a navigable knowledge graph where every entity is represented as a node with a specific type identifier. These node labels are stored as heap-owned strings in the `label` field of the `cbm_gbuf_node_t` structure, allowing the indexing pipeline to distinguish between files, functions, classes, and other semantic elements during the code analysis process.

## The 11 Canonical Node Labels

The indexing pipeline assigns specific string identifiers to nodes based on the source entity they represent. Each label is passed as a literal string to the graph buffer API and stored in the node's metadata.

### Source File Containers

- **`file`**: Represents a source file itself—the top-level container for all other entities in that file. Created when the watcher first discovers a file.

### Type Definitions

- **`class`**: Identifies class declarations and definitions (C++/Java-style).
- **`struct`**: Marks `struct` definitions in C/C++ code.
- **`enum`**: Denotes enumeration type definitions.
- **`typedef`**: Captures type aliases created via `typedef` or `using` statements.

### Functions and Variables

- **`function`**: Assigned to function definitions, including free functions and class methods. Created when the parser discovers a function body.
- **`variable`**: Labels global or file-scope variable declarations.

### Namespaces and Modules

- **`namespace`**: Tracks namespace blocks in C++ code.
- **`module`**: Represents language-level modules, such as Python modules or Go packages.

### Semantic Search Vectors

- **`token`**: Identifies lexical tokens stored for semantic-search purposes within the semantic-vectors subsystem.
- **`embedding`**: Marks vector embeddings attached to nodes for similarity search, typically stored via the vector storage API.

## Data Structure and Storage

All node labels are stored in the **`label`** member of the `cbm_gbuf_node_t` structure defined in the core graph-buffer header. This structure manages heap-owned strings for entity metadata.

```c
/* src/graph_buffer/graph_buffer.h */
typedef struct {
    int64_t id;               /* temporary sequential ID */
    char *label;              /* heap-owned string – one of the labels above */
    char *name;
    char *qualified_name;
    char *file_path;
    int start_line;
    int end_line;
    char *properties_json;    /* JSON payload – “{}” by default */
} cbm_gbuf_node_t;

```

The label field accepts any valid string, making the schema extensible, though the built-in pipeline uses only the canonical set defined above.

## How Labels Are Assigned at Runtime

Node labels are assigned during the indexing pipeline through explicit calls to `cbm_gbuf_upsert_node`. The **watcher** stage parses source files and creates nodes with appropriate labels, while the **pass** stages handle semantic vectors.

### File and Function Creation

In [`src/watcher/watcher.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/watcher/watcher.c), the parser discovers entities and immediately assigns labels:

```c
/* Example: creating a function node */
int64_t fn_id = cbm_gbuf_upsert_node(
    gb,
    "function",               /* ← label */
    "myFunc",                 /* name */
    "myPkg.myFunc",           /* qualified name */
    "src/myPkg/file.c",       /* file path */
    12,                       /* start line */
    20,                       /* end line */
    "{}");                    /* empty properties */

/* Example: creating a file node */
int64_t file_id = cbm_gbuf_upsert_node(
    gb,
    "file",
    "file.c",
    "myPkg.file.c",
    "src/myPkg/file.c",
    1,
    0,
    "{}");

```

### Semantic Vector Labels

The semantic analysis passes in `src/passes/*` (e.g., [`pass_semantic.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/pass_semantic.c)) handle specialized labels:

- **Token nodes** are created by the helper `cbm_gbuf_store_token_vector`, which internally assigns the `token` label to lexical elements.
- **Embedding nodes** are stored via `cbm_gbuf_store_vector` and attached to existing nodes while carrying the `embedding` label to distinguish vector data from source entities.

## Extending the Schema

Because the `label` field is a plain heap-allocated string passed directly to `cbm_gbuf_upsert_node`, the schema is deliberately extensible. New labels can be introduced in custom passes or watchers without modifying the core `cbm_gbuf_node_t` structure in [`src/graph_buffer/graph_buffer.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/graph_buffer/graph_buffer.h). However, the eleven labels listed above represent the complete built-in vocabulary used by the current codebase-memory-mcp implementation.

## Summary

- **codebase-memory-mcp** uses 11 canonical node labels: `file`, `function`, `class`, `struct`, `enum`, `typedef`, `variable`, `namespace`, `module`, `token`, and `embedding`.
- Labels are stored as heap-owned strings in the **`label`** field of `cbm_gbuf_node_t` defined in [`src/graph_buffer/graph_buffer.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/graph_buffer/graph_buffer.h).
- The **watcher** ([`src/watcher/watcher.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/watcher/watcher.c)) creates entity nodes for files, functions, and types.
- The **passes** (`src/passes/*`) create `token` and `embedding` nodes for semantic search.
- The string-based label system allows for schema extension without core structural changes.

## Frequently Asked Questions

### What data structure holds node labels in codebase-memory-mcp?

Node labels are stored in the **`cbm_gbuf_node_t`** structure defined in [`src/graph_buffer/graph_buffer.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/graph_buffer/graph_buffer.h). This struct contains a `char *label` field that holds a heap-owned string identifying the entity type, alongside fields for name, qualified name, file path, and line numbers.

### How are node labels assigned to source entities during indexing?

Labels are assigned via the **`cbm_gbuf_upsert_node`** function. When the watcher in [`src/watcher/watcher.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/watcher/watcher.c) parses source code, it discovers entities like functions or classes and calls `cbm_gbuf_upsert_node` with the appropriate label string (e.g., `"function"` or `"class"`), which creates or updates the node in the graph buffer.

### Can I add custom node labels to the codebase-memory-mcp graph schema?

Yes. Because the label is a plain string passed to `cbm_gbuf_upsert_node`, you can introduce new labels in custom passes or watchers without modifying the core graph buffer implementation. The schema is designed to be extensible, though the built-in pipeline uses only the eleven canonical labels.

### What is the difference between `token` and `embedding` node labels?

**`token`** nodes represent lexical tokens extracted from source code for semantic search, created by `cbm_gbuf_store_token_vector`. **`embedding`** nodes represent vector embeddings (numerical vectors) attached to existing nodes for similarity search, stored via `cbm_gbuf_store_vector`. While `token` nodes contain raw lexical data, `embedding` nodes contain computed vector representations.