How to Contribute to Codebase Memory MCP: A Guide to the C Knowledge Graph Engine

To contribute to Codebase Memory MCP, fork the repository, compile using scripts/build.sh, validate changes against ~2,040 ASAN-enabled tests via scripts/test.sh, and submit a signed-off pull request after passing the lint checks in scripts/lint.sh.

Codebase Memory MCP is a pure-C knowledge-graph engine maintained by DeusData that indexes repository source code in milliseconds and exposes 15 MCP tools over JSON-RPC. Before you contribute to codebase memory MCP, you should understand its four-layer architecture, which separates AST extraction, graph construction, storage, and server interfaces into distinct components with well-defined boundaries.

Understanding the Four-Layer Architecture

The project organizes functionality into four layered components, each with specific source files you can extend or modify.

AST Extraction Layer

The extraction layer uses bundled tree-sitter grammars supporting 158 languages to produce language-agnostic syntax trees. The registration of grammars and mapping to internal language IDs happens in internal/cbm/lang_specs.c. Language-specific AST walkers, such as internal/cbm/extract_k8s.c and other internal/cbm/extract_*.c files, process these trees and emit CBMFileResult structs for downstream consumption.

Multi-Pass Pipeline

Located under src/pipeline/, this component walks the extracted ASTs and resolves symbols, imports, type relationships, and HTTP routes. Each analysis pass is implemented as a separate C file following the pass_*.c naming convention—for example, src/pipeline/pass_infrascan.c handles infrastructure detection. The generic driver in src/pipeline/pipeline.c orchestrates these passes, which emit graph nodes and edges with labels like CALLS, IMPORTS, and HTTP_CALLS.

Graph Store

The storage layer persists the knowledge graph in an in-memory SQLite database running in WAL mode, featuring custom tokenizers for camelCase and snake_case identifiers. All graph persistence logic resides in src/store/store.c, which provides the backing store for the MCP server's 15 tools.

MCP Server and Visualization UI

The application layer exposes graph capabilities via JSON-RPC through src/mcp/server.c, which handles tool registration and request routing. The tool implementations themselves—covering search, trace, and architecture analysis—live in src/mcp/tools.c. An optional React-based 3D visualization UI is available in graph-ui/src/App.tsx and requires Node.js 22+ to build.

Setting Up Your Development Environment

Ensure your system has a C compiler, make, and zlib installed. For UI development, Node.js 22 or higher is required. Clone the repository and build the static binary:

git clone https://github.com/DeusData/codebase-memory-mcp.git
cd codebase-memory-mcp
scripts/build.sh

The build script produces the binary at build/c/codebase-memory-mcp.

Contribution Workflow

Follow these steps when preparing changes:

1. Fork and clone the repository from DeusData/codebase-memory-mcp.
2. Build the project using scripts/build.sh to verify compilation succeeds.
3. Run tests with scripts/test.sh, which executes approximately 2,040 test cases with AddressSanitizer (ASAN) and UndefinedBehaviorSanitizer (UBSAN) enabled.
4. Add regression tests for new functionality under tests/, particularly in tests/test_extraction.c for language support.
5. Execute linting via scripts/lint.sh to ensure compliance with clang-tidy, cppcheck, and clang-format.
6. Commit with sign-off using git commit -s following conventional commit format.
7. Submit a pull request with a detailed description of architectural changes.

Extending Language Support

When adding or fixing language support, modify internal/cbm/lang_specs.c to register tree-sitter grammars, then implement the corresponding internal/cbm/extract_*.c file to handle AST walking. Always add regression tests in tests/test_extraction.c.

For infrastructure languages such as Dockerfile or Kubernetes YAML, you do not need new tree-sitter grammars. Instead, add detection logic to src/pipeline/pass_infrascan.c, define a new enum value in internal/cbm/cbm.h, and implement a custom extractor following existing patterns.

Testing Your Changes Locally

Validate your build by indexing a local repository and querying the graph:

# Index using absolute paths

./build/c/codebase-memory-mcp cli index_repository --repo-path /absolute/path/to/project

# Query the graph

./build/c/codebase-memory-mcp cli query_graph --project my-project \
  --query "MATCH (f:Function) RETURN f.name LIMIT 5"

To test the UI component:

./build/c/codebase-memory-mcp --ui=true --port=9749

# Navigate to http://localhost:9749

Summary

• Codebase Memory MCP consists of four architectural layers: AST extraction (internal/cbm/), multi-pass pipeline (src/pipeline/), graph store (src/store/), and MCP server/UI (src/mcp/, graph-ui/).
• Key files for language support include internal/cbm/lang_specs.c and internal/cbm/extract_*.c, while pipeline passes reside in src/pipeline/pass_*.c.
• The contribution workflow requires building with scripts/build.sh, testing with scripts/test.sh (~2,040 ASAN/UBSAN cases), and linting with scripts/lint.sh.
• Infrastructure languages (Dockerfile, K8s) require only pass_infrascan.c and cbm.h changes, whereas full languages need tree-sitter integration.
• All commits must be signed off (git commit -s) and follow conventional commit standards.

Frequently Asked Questions

What programming languages do I need to know to contribute?

The core engine is written in C (C99/C11), requiring proficiency in manual memory management and systems programming. The optional visualization UI requires TypeScript/React (Node.js 22+). Understanding of tree-sitter grammar concepts is helpful but not mandatory for most contributions.

How do I add support for a new programming language?

Edit internal/cbm/lang_specs.c to register the tree-sitter grammar and assign a language ID. Create the corresponding internal/cbm/extract_*.c file to implement AST walking logic that emits CBMFileResult structs. Add regression tests in tests/test_extraction.c and ensure scripts/test.sh passes with ASAN/UBSAN validation.

What is the difference between standard and infrastructure language support?

Standard languages (Python, Go, Rust, etc.) require full tree-sitter grammar integration and dedicated extractors. Infrastructure languages (Dockerfile, Kubernetes, Terraform) do not need new grammars; instead, you modify src/pipeline/pass_infrascan.c, add an enum to internal/cbm/cbm.h, and implement a lightweight custom extractor.

How do I verify my changes meet quality standards?

Run scripts/build.sh to compile without errors, then execute scripts/test.sh to verify against approximately 2,040 test cases running under AddressSanitizer and UndefinedBehaviorSanitizer. Finally, run scripts/lint.sh to ensure compliance with clang-tidy, cppcheck, and clang-format. All three steps must pass before submitting a signed-off PR.

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