Codebase Memory MCP Tools: Available Tools and Input Parameters Explained

TLDR: The codebase-memory-mcp binary exposes 14 built-in MCP tools through a JSON-RPC interface, with strict input schemas defined in src/mcp/mcp.c that validate parameters ranging from repository paths to graph traversal directions before executing queries against the SQLite knowledge graph.

DeusData/codebase-memory-mcp implements a zero-dependency, single-binary knowledge graph engine that exposes codebase analysis capabilities through the Model-centric Protocol (MCP). Understanding the mcp tools available and input parameters enables developers to programmatically index repositories, trace cross-package call chains across 158 languages, and query architecture metrics through a standardized JSON-RPC interface.

MCP Tool Architecture and Schema Registry

The tool registry is defined as a static TOOLS[] array within src/mcp/mcp.c【[mcp.c]】. Each tool entry contains input_schema and output_schema properties that describe valid JSON argument structures, enabling automatic CLI flag generation and IDE autocomplete functionality. When the server receives a JSON-RPC request, the cbm_mcp_handle_tool function dispatches the call by matching the tool name against this registry and validating arguments against the stored schema.

The 14 tools are divided into two functional categories: indexing (mutation) and querying (read-only). All tools return JSON envelopes via cbm_mcp_text_result for CLI display or cbm_mcp_json_result for programmatic consumption【[mcp.c]】.

Indexing Tools and Input Parameters

These four tools modify the knowledge graph by creating projects, updating indices, or removing data.

index_repository

Required parameter: repo_path (string) – Absolute or relative path to the target repository root.

Example input:

{"repo_path":"/home/user/myproject"}

This tool triggers the multi-pass pipeline in src/pipeline/pipeline.c, which executes discovery, Tree-sitter parsing, Hybrid LSP resolution, and SQLite storage【[pipeline.c]】.

list_projects

Accepts empty arguments {} to return all indexed projects stored in ~/.cache/codebase-memory-mcp/.

delete_project

Required parameter: Project identifier (string), typically the project name or ID.

Warning: Permanently removes the project's SQLite database and cache files from the local store.

index_status

Accepts empty arguments {} to return the current indexing state, including active pipelines and queue depth.

Query Tools and Input Parameters

These ten tools perform read-only operations against the SQLite graph stored in src/store/store.c【[store.c]】.

search_graph

Parameters:

• name_pattern (string): Regex pattern for node names (e.g., "Handler$").
• label (string): Node type filter such as "Function", "File", or "Package".
• limit (integer): Maximum results to return (default: 20).

Example input:

{"name_pattern":"Handler$","label":"Function","limit":20}

trace_path

Parameters:

• function_name (string): Fully qualified function name to trace (e.g., "UserService.create_user").
• direction (string): Either "inbound" (callers) or "outbound" (callees).
• depth (integer, optional): BFS traversal limit.

Example input:

{"function_name":"ProcessOrder","direction":"inbound"}

The underlying implementation uses cbm_store_bfs in src/store/store.c to traverse CALLS edges bidirectionally【[store.c]】.

detect_changes

Parameters: Accepts since (timestamp) or files (array of paths) to identify modified nodes since last indexing.

query_graph

Accepts a graph query object supporting Cypher-like or SQL-like syntax against the SQLite backend, depending on the Hybrid LSP resolution available for the target language.

get_graph_schema

Accepts empty arguments {} to return the node and edge type definitions available in the current graph (e.g., Function, Route, CALLS, IMPORTS).

get_code_snippet

Parameters: Requires node_id or file_path plus optional line_range to extract source text from indexed files.

get_architecture

Accepts empty arguments {} to return a high-level overview including language breakdowns, package counts, hot-spots, and detected Architecture Decision Records (ADRs).

search_code

Parameters:

• query (string): Raw text search pattern.
• path_pattern (string): File path filter (e.g., "*.py").

manage_adr

Parameters:

• action (string): "create", "update", or "list".
• content (object): ADR metadata including title, context, and decision.

ingest_traces

Parameters: Accepts trace data objects (likely from OpenTelemetry) to link runtime behavior with static code nodes via HTTP_CALLS or EMITS edges.

JSON-RPC Request Format

All tools are invoked via the tools/call method over stdio or HTTP. The src/main.c entry point starts the server loop that reads JSON-RPC from stdin【[main.c]】.

Request structure:

{"jsonrpc":"2.0","method":"tools/call","params":{"tool":"trace_path","args":{"function_name":"ProcessOrder","direction":"inbound"}},"id":1}

The cbm_mcp_get_tool_name and cbm_mcp_get_tool_args functions extract the tool identifier and argument object from the request payload【[mcp.c]】.

Practical Usage Examples

CLI Invocation

The cli command parses JSON arguments and routes to the MCP dispatcher:

# Index current directory

codebase-memory-mcp cli index_repository '{"repo_path":"$(pwd)"}'

# Search for handler functions

codebase-memory-mcp cli search_graph '{"name_pattern":"Handler$","label":"Function","limit":20}'

Programmatic Python Client

import json, subprocess

def mcp_call(tool, args):
    req = json.dumps({
        "jsonrpc":"2.0",
        "method":"tools/call",
        "params":{"tool":tool,"args":args},
        "id":1
    })
    proc = subprocess.run(
        ["codebase-memory-mcp", "cli"], 
        input=req.encode(),
        stdout=subprocess.PIPE, 
        check=True
    )
    return json.loads(proc.stdout)

# Trace callers

result = mcp_call("trace_path", {
    "function_name":"UserService.create_user",
    "direction":"inbound"
})

Accessing Tool Schemas

Clients can retrieve the full schema list via the standard tools/list MCP method, which reads from the TOOLS[] array to populate available tools and their parameter definitions dynamically.

Summary

• 14 tools are defined in src/mcp/mcp.c within the static TOOLS[] array, each specifying input_schema and output_schema for validation.
• Indexing tools (index_repository, list_projects, delete_project, index_status) accept parameters like repo_path and modify the SQLite graph stored in ~/.cache/codebase-memory-mcp/.
• Query tools (trace_path, search_graph, get_architecture, etc.) accept parameters such as function_name, direction, and name_pattern to perform BFS traversal and pattern matching via src/store/store.c.
• Validation occurs in cbm_mcp_handle_tool, which dispatches requests after checking arguments against the JSON schemas defined in the tool registry.
• Invocation works via JSON-RPC over stdio or HTTP, with the entry point in src/main.c handling both CLI and server modes.

Frequently Asked Questions

What are the required parameters for the index_repository tool?

The index_repository tool requires a single string parameter repo_path specifying the absolute or relative path to the repository root. Optional configuration parameters may include ignore patterns or cache directories, but only repo_path is mandatory for the indexing pipeline to execute in src/pipeline/pipeline.c.

How does the trace_path tool handle direction parameters?

The trace_path tool accepts a direction parameter with two valid values: "inbound" to find callers of the specified function, or "outbound" to find callees. This parameter is case-sensitive and must be provided alongside function_name to trigger the BFS traversal implemented in cbm_store_bfs within src/store/store.c.

Where are the input schemas for MCP tools defined?

Input schemas are defined as static JSON objects within the TOOLS[] array in src/mcp/mcp.c. These schemas are exposed to clients via the tools/list MCP method and are used by cbm_mcp_handle_tool to validate incoming request arguments before dispatching to the underlying store or pipeline functions.

Can I query the knowledge graph without indexing first?

No, query tools such as search_graph, trace_path, and get_architecture require a pre-existing SQLite database created by index_repository. These tools operate against the compressed graph stored in ~/.cache/codebase-memory-mcp/ and will return empty results or errors if the specified project has not been indexed.

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