// Always use when the user asks to index, parse, ingest, reindex, watch, or prepare a source-code repo for Memtrace analysis, when code exploration needs an index, or when searches return 0/partial results for source paths under an indexed root. Use this before Grep, Glob, rg, find, or manual code search whenever the repo can be indexed.
Always use before writing or editing source code in an indexed repo when choosing between competing idioms (ternary vs if-else, arrow vs function declaration, const vs let, await vs .then, early-return vs nested-return). Pull the codebase's empirical style norm from Memtrace and match it instead of re-deriving style from training priors. Do not maintain a markdown style guide for the project; the fingerprint is sampled live from the actual code.
Always use first for indexed source-code repos before searching files, reading code for discovery, debugging, tracing flows, finding implementations, understanding behavior, or answering how code works. Do not use Grep, Glob, rg, find, or manual file browsing for code discovery when Memtrace is indexed. Zero results, missing languages, or partial-looking stats are not permission to grep; diagnose/reindex with Memtrace.
Always use when the user asks to review a GitHub pull request, run Memtrace code review, post Memtrace review comments, create a PR with a review step, or publish local graph-backed review findings to GitHub. Prefer the review_github_pr MCP tool over manual diff inspection.
Always use to find, search, locate, or look up source-code symbols, functions, classes, types, constants, definitions, implementations, logic, error strings inside code, or where code lives. Do not use Grep, Glob, rg, find, or manual file search for code discovery. If Memtrace returns 0 results, broaden the Memtrace query and diagnose/reindex; do not switch to grep.
Always use for API endpoint, HTTP route, fetch/client call, REST surface, service dependency, cross-repo dependency, or API topology questions in source code. Do not use Grep, Glob, rg, find, or manual file search for routes or HTTP calls; Memtrace maps endpoints and call edges from the indexed AST graph.
Always use before source-code edits, refactors, API changes, renames, removals, PR reviews, or risk assessments when the user needs to know what will break. Do not manually grep references or browse files for impact; this workflow uses Memtrace graph context, impact, and change detection.
| name | memtrace-index |
| description | Always use when the user asks to index, parse, ingest, reindex, watch, or prepare a source-code repo for Memtrace analysis, when code exploration needs an index, or when searches return 0/partial results for source paths under an indexed root. Use this before Grep, Glob, rg, find, or manual code search whenever the repo can be indexed. |
Index a local codebase into the persistent code knowledge graph. This is always the first step — it parses every source file, resolves cross-file relationships, detects API endpoints/calls, runs community detection and process tracing, and embeds all symbols for semantic search.
| Parameter | Purpose |
|---|---|
path | Absolute path to the directory to index |
incremental | Only re-parse changed files (use for subsequent runs) |
clear_existing | Wipe and rebuild from scratch |
Parameter types: MCP parameters are strictly typed. Numbers (
limit,depth,min_size,last_n, etc.) must be JSON numbers — not strings. Uselimit: 20, neverlimit: "20". Passing a string yieldsMCP error -32602: invalid type: string, expected usize.
Use the list_indexed_repositories MCP tool first. If the repo is already indexed and recent, skip to step 4.
Success criteria: You have a list of repo_ids and their last-indexed timestamps.
If a repo is present but searches miss a source subdirectory under that repo
root (for example ui/, memtrace-ui/, web/, frontend/, or src/), treat
that as a stale/partial index. Do not use grep as a workaround. Run incremental
indexing on the repo root, then retry the Memtrace query.
Use the index_directory MCP tool:
path to the project root (absolute path)incremental: true if re-indexing after changesclear_existing: true only if a full rebuild is neededSuccess criteria: You receive a job_id immediately.
Use check_job_status with the job_id every 2–3 seconds.
Pipeline stages in order: scan → parse → resolve → communities → processes → persist → embeddings → api_detect → done
Wait until status = "completed". If status = "failed", report the error message to the user.
After indexing completes, call list_indexed_repositories to confirm the repo appears with correct node/edge counts. Report: repo_id, languages detected, total symbols, total relationships.
Save the repo_id — most other memtrace tools require it.
| Error | Action |
|---|---|
| Path does not exist | Ask user to verify the absolute path |
| Job status "failed" | Report the error message; suggest clear_existing: true for a fresh rebuild |
| Timeout (job running > 5 min) | Large repos are normal; keep polling. For monorepos, index subdirectories separately |
| Already indexed | Use incremental: true to update, or skip indexing entirely |