# What Kind of Data Does Codebase Memory MCP Process? A Complete Guide to CBM's Input Types

> Discover the diverse input data for Codebase Memory MCP. Learn how it processes text files like source code, configs, and docs into a knowledge graph without LLMs.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: how-to-guide
- Published: 2026-07-26

---

**Codebase Memory MCP processes any textual file that can be parsed by its 158 vendored Tree-sitter grammars—transforming source code, infrastructure definitions, configuration files, and documentation into a persistent SQLite knowledge graph with zero LLM dependencies.**

Codebase Memory MCP (CBM) is a structural code-intelligence engine developed by [DeusData/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp) that converts repository contents into a queryable knowledge graph. Unlike AI-dependent tools, CBM operates entirely offline, processing local files ranging from Python functions to Kubernetes manifests. This article examines exactly what kind of data codebase memory mcp processes and how that information is stored in the underlying graph database.

## Source Code Analysis via Tree-sitter

CBM extracts **Abstract Syntax Tree (AST) nodes** from source code files using 158 vendored Tree-sitter grammars. The system identifies functions, classes, methods, enums, and other structural elements, then maps relationships including calls, imports, inheritance, and implementation edges.

When you run the indexing pipeline, CBM creates nodes for **Project**, **Package**, **File**, **Class**, and **Function** entities. These connect via typed edges such as `CALLS`, `IMPORTS`, and `INHERITS`. The processing happens entirely locally in `internal/cbm/` components, requiring no external API calls or model inference.

## Infrastructure-as-Code and Configuration Files

Beyond application code, CBM processes **Infrastructure-as-Code (IaC)** artifacts. Dockerfiles, Kubernetes manifests, and Kustomize overlays become `Resource` and `Module` nodes with cross-references to the application code they support.

Configuration control files also feed into the system:

- **`.cbmignore`** and **`.gitignore`** determine exclusion patterns during indexing
- **[`.codebase-memory.json`](https://github.com/DeusData/codebase-memory-mcp/blob/main/.codebase-memory.json)** stores project-level configuration that affects graph generation

These rules are parsed according to the specifications in [`docs/cbmignore.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/docs/cbmignore.md) and directly influence what data enters the knowledge graph.

## Documentation and Runtime Traces

CBM ingests **Architecture Decision Records (ADRs)** as first-class nodes. These textual documents are parsed into `ADR` entities and linked to the specific code components they describe, creating bidirectional traceability between design decisions and implementation.

Optional **runtime traces** can be imported to validate `HTTP_CALLS` edges in the graph. While static analysis identifies potential call relationships, runtime data confirms actual execution paths between services.

## The Persistent Storage Layer

All processed data compiles into a **compressed SQLite database** stored at `~/.cache/codebase-memory-mcp/`. The implementation in [`internal/cbm/zstd_store.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/internal/cbm/zstd_store.c) handles **Zstandard compression** of the graph payload, producing a portable binary artifact (`.codebase-memory/graph.db.zst`) that teams can share without re-indexing.

This compiled graph contains:

- **Nodes**: Project, Package, File, Class, Function, Route, Resource, ADR
- **Edges**: `CALLS`, `IMPORTS`, `HTTP_CALLS`, `EMITS`, `IMPLEMENTS`

The storage format supports full-text search and directional graph traversal through the CLI interface implemented in [`pkg/pypi/src/codebase_memory_mcp/_cli.py`](https://github.com/DeusData/codebase-memory-mcp/blob/main/pkg/pypi/src/codebase_memory_mcp/_cli.py).

## Querying the Processed Data

Once indexed, the knowledge graph supports semantic queries through the CLI. Below are practical examples demonstrating how CBM interacts with the processed data:

```bash

# 1. Index the current repository (processes all supported files)

codebase-memory-mcp cli index_repository --repo-path "$(pwd)"

# 2. List projects that have been indexed

codebase-memory-mcp cli list_projects

# 3. Retrieve a high-level architecture overview (languages, packages, routes)

codebase-memory-mcp cli get_architecture --project my-repo

# 4. Search for all functions whose name contains "Handler"

codebase-memory-mcp cli search_graph \
    --project my-repo \
    --label Function \
    --name-pattern ".*Handler.*"

# 5. Follow the call chain inbound to a specific function

codebase-memory-mcp cli trace_path \
    --project my-repo \
    --function-name "process_order" \
    --direction inbound

```

## Summary

- **Codebase Memory MCP** processes source code across 158 Tree-sitter grammars, converting AST nodes into a structural knowledge graph.
- **IaC and configuration** files including Dockerfiles, Kubernetes manifests, and `.cbmignore` rules are parsed as graph nodes and filtering directives.
- **ADRs and runtime traces** integrate documentation and observability data with static code analysis.
- **Zstandard-compressed SQLite** in [`internal/cbm/zstd_store.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/internal/cbm/zstd_store.c) provides portable, team-shareable graph artifacts without external dependencies.
- The **CLI** in [`pkg/pypi/src/codebase_memory_mcp/_cli.py`](https://github.com/DeusData/codebase-memory-mcp/blob/main/pkg/pypi/src/codebase_memory_mcp/_cli.py) enables querying the processed data via `search_graph`, `trace_path`, and architecture commands.

## Frequently Asked Questions

### Does Codebase Memory MCP require an internet connection to process data?

No. CBM is designed as a fully offline, local-first tool. All parsing, graph construction, and storage happens on your machine using vendored grammars. No LLM APIs or external services are involved in the indexing pipeline.

### What programming languages are supported by the Tree-sitter grammars?

CBM supports **158 vendored Tree-sitter grammars** covering mainstream languages including Python, JavaScript, TypeScript, Go, Rust, Java, and C/C++. The system extracts language-agnostic AST nodes (functions, classes, methods) regardless of the specific syntax, creating unified `Function` and `Class` entities in the graph.

### How does CBM handle files that should be excluded from indexing?

CBM respects `.cbmignore` and `.gitignore` patterns according to [`docs/cbmignore.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/docs/cbmignore.md). These configuration files are themselves parsed during the indexing phase to determine which paths should be excluded from the knowledge graph. You can also specify additional ignore patterns in the project-level [`.codebase-memory.json`](https://github.com/DeusData/codebase-memory-mcp/blob/main/.codebase-memory.json) configuration.

### Can runtime traces be integrated with the static code analysis?

Yes. While CBM primarily performs static analysis, it can import optional runtime traces to validate `HTTP_CALLS` edges between services. This allows the graph to distinguish between statically-identified potential call paths and empirically observed HTTP traffic, improving the accuracy of service dependency mapping.