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

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.

/* 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, the parser discovers entities and immediately assigns labels:

/* 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) 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. 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.
• The watcher (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. 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}