# Purpose of the src Directory in DeusData codebase-memory-mcp: Core Architecture Explained

> Discover the purpose of the src directory in DeusData codebase-memory-mcp. It holds the C code for the intelligence engine, from server entry to UI, compiling into a single zero-dependency binary.

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

---

**The `src` directory contains the complete C implementation of the code-intelligence engine, housing everything from the MCP server entry point to the indexing pipeline and optional UI, compiling into a single zero-dependency static binary.**

The `src` directory serves as the core implementation hub for the **codebase-memory-mcp** project by DeusData. This self-contained C codebase encapsulates the entire code-intelligence engine, from low-level platform abstractions to the high-level graph query interface. According to the repository's architecture documentation, everything under `src/` compiles into a single static binary that powers both the MCP server and command-line interface.

## Architectural Overview of the src Directory

The `src` directory mirrors the logical architecture described in the README, organizing the codebase into distinct functional modules. Unlike repositories that scatter implementation across multiple top-level folders, this project consolidates all functional code under `src/` while reserving directories like `docs/` and `graph-ui/` for ancillary resources.

This consolidation enables the build system ([`scripts/build.sh`](https://github.com/DeusData/codebase-memory-mcp/blob/main/scripts/build.sh)) to compile every source file into a single static binary. The zero-dependency design means the resulting executable contains the MCP server, SQLite-backed graph storage, file-watching capabilities, and optional UI server without requiring external runtime dependencies.

## Core Components Within src/

### Entry Point and MCP Server Implementation

The binary's lifecycle begins in **[`src/main.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/main.c)**, which handles command-line argument parsing and JSON-RPC dispatch. This file initializes the MCP server that implements 14 distinct tools for indexing, querying, and trace analysis. When you launch `codebase-memory-mcp --port=9749`, the execution path originates here, establishing the server that handles client communication.

### Multi-Pass Indexing Pipeline

At the heart of the code-intelligence engine lies **[`src/pipeline/pipeline.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline.c)**, which orchestrates a sophisticated multi-pass indexing process. The pipeline executes syntactic parsing, definition extraction, call-graph construction, HTTP link resolution, and test configuration analysis. The companion header **[`src/pipeline/pipeline.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline.h)** exposes the public API used by the server to trigger repository indexing.

### Graph Storage and Query Engine

The knowledge graph persists through modules handling SQLite database operations and Cypher-like query execution. While the storage implementation resides in `src/store/`, the in-memory graph buffer is managed by **[`src/graph_buffer/graph_buffer.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/graph_buffer/graph_buffer.c)** before persistence. The Cypher query engine, located in `src/cypher/`, parses and executes read-only queries against this graph structure.

### File Discovery and Change Monitoring

Repository synchronization depends on **[`src/watcher/watcher.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/watcher/watcher.c)**, which monitors filesystem changes while respecting `.gitignore` and `.cbmignore` patterns. Git integration for change-detection and diff-based impact analysis is implemented in **[`src/git/git_context.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/git/git_context.c)**. Together, these ensure the knowledge graph remains synchronized with the actual codebase state.

### Semantic Analysis and Runtime Traces

Advanced code intelligence is provided by **[`src/semantic/semantic.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/semantic/semantic.c)**, which implements Hybrid LSP semantic type resolution. The engine also accepts external execution traces through modules in `src/traces/`, validating and enriching graph edges with runtime behavior data.

### Platform Foundation Layer

Cross-platform compatibility is abstracted in **`src/foundation/`**, containing critical utilities like **[`src/foundation/log.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/foundation/log.c)** for logging, **[`src/foundation/mem.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/foundation/mem.c)** for memory management, and **[`src/foundation/compat_fs.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/foundation/compat_fs.c)** for filesystem operations across POSIX and Windows environments. Every other module depends on this foundation layer.

### Optional UI Server

When launched with the `--ui` flag, the binary serves a 3-D graph visualization interface compiled from **`src/ui/`** (specifically referenced in [`src/ui/server.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/ui/server.c)). This embedded server runs alongside the MCP server, providing visual exploration of the knowledge graph without requiring separate frontend infrastructure.

## Practical Usage Examples

The following commands demonstrate how the compiled `src` components function in practice:

Launch the MCP server on port 9749:

```bash
codebase-memory-mcp --port=9749

```

Index a repository using the pipeline:

```bash
codebase-memory-mcp cli index_repository '{"repo_path":"/path/to/my/project"}'

```

Query the knowledge graph:

```bash
codebase-memory-mcp cli search_graph '{"project":"my-project","label":"Function","name_pattern":"^handle_.*"}'

```

Start with the optional UI:

```bash
codebase-memory-mcp --ui=true --port=9749

```

## Summary

- The `src` directory houses the complete C implementation of the codebase-memory-mcp engine, from [`src/main.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/main.c) entry point to `src/ui/` server components.
- It compiles into a single zero-dependency static binary via [`scripts/build.sh`](https://github.com/DeusData/codebase-memory-mcp/blob/main/scripts/build.sh), separating implementation from documentation and assets.
- Key subsystems include the multi-pass indexing pipeline ([`src/pipeline/pipeline.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline.c)), SQLite-backed graph storage, filesystem watcher ([`src/watcher/watcher.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/watcher/watcher.c)), and cross-platform foundation layer (`src/foundation/`).
- The architecture supports 14 MCP tools, Cypher-like graph queries, Hybrid LSP semantic analysis, and optional 3-D visualization.

## Frequently Asked Questions

### What programming language is used in the src directory?

The `src` directory contains a self-contained **C codebase** that compiles into a static binary. This includes the MCP server implementation, indexing pipeline, SQLite storage layer, and optional UI server, all written in C for maximum portability and zero-dependency deployment.

### How does the src directory support the zero-dependency claim?

By consolidating all implementation code—from platform abstractions in `src/foundation/` to the graph engine and UI server—under a single directory with pure C sources, the build system can statically link everything into one executable. This eliminates external runtime dependencies, as the binary contains all necessary logic including the SQLite database engine and JSON-RPC handling.

### What is the relationship between src/pipeline/pipeline.c and the MCP server?

The [`src/pipeline/pipeline.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline.c) file implements the core indexing logic that the MCP server invokes through the public API defined in [`src/pipeline/pipeline.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline.h). When the server receives an `index_repository` tool call, it delegates to this pipeline, which orchestrates syntactic parsing, definition extraction, and call-graph construction before persisting results to the SQLite store.

### Can I use components from src independently?

While the `src` directory is organized into logical modules (foundation, pipeline, watcher, etc.), the codebase is designed as an integrated system compiled into a single binary. The components are tightly coupled through the build process in [`scripts/build.sh`](https://github.com/DeusData/codebase-memory-mcp/blob/main/scripts/build.sh), though the modular structure within `src/` maintains clean separation of concerns for maintenance and testing purposes.