Estimate how many Claude CLI calls ingesting a repo will require.

Use this BEFORE running ingest_repo on a large codebase to understand the scope. Reports file counts by language and the total number of 'claude --print' subprocess calls that will be made.

Does not call Claude or modify anything — safe to run at any time.

Get a structured overview of the repo by traversing the vault graph.

Use this for onboarding questions: 'explain the repo', 'where do I start', 'give me an overview of the codebase', or 'what are the main components'. Starts from the vault INDEX and traverses breadth-first, returning summaries at increasing depth so you can understand the repo from the top down.

To drill into a specific node after this overview, use the Obsidian MCP vault_read tool.

GUARDRAIL: Never call the Obsidian MCP vault_write tool unless the user explicitly requests it by name.

vault_root is optional — omit to use CODELORE_VAULT_ROOT, or pass it explicitly to explore a different repo's vault without reconfiguring. Resolves against the configured target repo (see server instructions) — not necessarily the current working directory.

Find TODO/FIXME comments and recent git activity for relevant files.

Use this for project progress or task management questions: 'what's left to do', 'what needs work in the parser', 'what files are incomplete', 'show me open tasks'. Searches for the most relevant files via semantic search, then scans them for TODO/FIXME/HACK comments and shows recent git commits.

After identifying open tasks, you may use the Obsidian MCP vault_append tool to add notes or progress updates to the relevant vault files without overwriting existing content. Use vault_read (Obsidian MCP) to read the file before appending.

GUARDRAIL: Never call the Obsidian MCP vault_write tool unless the user explicitly requests it by name.

vault_root, chroma_path, and repo_root are optional — omit to use env vars, or pass them explicitly to query a different repo. Resolves against the configured target repo (see server instructions) — not necessarily the current working directory.

Report which repo this codelore server is currently scoped to — useful to sanity-check before a multi-step task, or to debug a misconfigured .mcp.json. Not required before calling other tools: they already refuse to resolve to codelore's own source on their own.

Ingest a code repository into codelore — generates the vault and search index.

Accepts either a local directory path or a GitHub URL (https://github.com/owner/repo). Runs the full pipeline:

1. Generates AI summaries for every file and directory via Claude CLI

2. Writes an Obsidian-compatible vault of markdown notes

3. Indexes code chunks as developer questions into ChromaDB

extra_frontmatter_json — optional JSON object of extra fields to add to every vault note's frontmatter, e.g. '{"project": "myapp", "status": "draft", "tags": ["backend", "python"]}'. Strings, numbers, booleans, and flat lists are all supported. These fields are merged after the built-in fields.

After ingestion, the tool prints the vault and chroma paths. Pass these as vault_root and chroma_path to the query tools, or set them as env vars.

WARNING: calls 'claude --print' once per file + directory + chunk. Run estimate_cost first on large repos.

Return the project's architectural guidelines and coding conventions.

Use this for questions about coding style, architectural patterns, conventions, how to structure new code, or what rules the project follows.

GUARDRAIL: Never call the Obsidian MCP vault_write tool unless the user explicitly requests it by name.

guidelines_path is optional — omit to use CODELORE_GUIDELINES_PATH, or pass a path directly to read any guidelines document without reconfiguring.

Rebuild the vault and search index from an existing explanations file.

Use this to re-run vault generation WITHOUT making any Claude CLI calls for file summaries. Useful when you want to re-index after code changes but already have summaries, or to iterate on vault structure without LLM cost.

extra_frontmatter_json — optional JSON object of extra fields to add to every vault note's frontmatter, e.g. '{"project": "myapp", "status": "draft", "tags": ["backend", "python"]}'. Strings, numbers, booleans, and flat lists are all supported.

Note: ChromaDB question generation still calls Claude once per chunk — only the file/directory summaries are skipped (they're loaded from JSON).

The explanations.json is saved automatically by ingest_repo.

Search the codebase using semantic similarity.

Use this for functional questions: how something works, where a function is defined, what a module does, or any vague/underspecified question about code behaviour. Searches a question-indexed vector database and returns the most relevant code chunks together with their vault summary.

Each result is labeled Confidence: high or low based on whether its cosine distance is within max_distance (default 1.35 — tune it lower for stricter matching, higher to allow more speculative results through).

FALLBACK — if this tool returns no results or all results are labeled low confidence, call the Obsidian MCP search_simple tool with the same query for a plain-text search across vault notes; do not grep the repo's source as a substitute for search — the vault is the source of truth for locating relevant code.

Once you've located relevant code via a result's file_path (an absolute path into the target repo, not the vault), reading that file directly with Read/Grep is expected and normal when you need exact/current detail the vault summary doesn't cover — the vault summarizes, it doesn't replace the source.

After finding results, use the Obsidian MCP vault_read tool to read full vault notes — try the vault-relative path first, and fall back to the absolute path if the Obsidian MCP rejects it (path format depends on how the Obsidian MCP server resolves paths against the vault root).

GUARDRAIL: Never call the Obsidian MCP vault_write tool unless the user explicitly requests it by name.

vault_root and chroma_path are optional — if omitted, the server uses the CODELORE_VAULT_ROOT and CODELORE_CHROMA_PATH environment variables. Pass them explicitly to query a different repo without reconfiguring the server. Resolves against the configured target repo (see server instructions) — not necessarily the current working directory.

Detect and apply repo changes since the last ingest.

Use this to keep the vault and search index in sync after code changes without re-processing the entire repo. Uses git diff against the commit SHA saved during the last ingest_repo run.

dry_run=True (default): reports changed, new, and deleted files — no changes made. dry_run=False: for each modified file, regenerates its summary and asks Claude whether it's a REAL conflict vs. the existing vault note (not just phrasing/ comment/formatting drift). Only real conflicts replace the note and reindex that file's ChromaDB questions — everything else is left as-is. Either way, the vault note gets a Sync Log entry noting the commit that was checked. New files are ingested for the first time; deleted files are removed.

Always run with dry_run=True first to review the change set, then call again with dry_run=False to apply. Requires the repo to be a git repository.

Find the most relevant vault note for a user's annotation query and return its path so the Obsidian MCP vault_append tool can safely append to it.

Use this when the user wants to add notes, progress updates, or observations to a vault file based on what they're currently doing — for example: 'add a note about the parser edge case', 'mark this TODO as resolved', 'append my findings on the auth module'.

WORKFLOW:

1. This tool resolves the target vault note path via semantic search.

2. Use the Obsidian MCP vault_read tool to read the current content of that file before appending.

3. Use the Obsidian MCP vault_append tool to add the new content to the end of the file. vault_append never overwrites existing content.

GUARDRAIL: Use vault_append (Obsidian MCP) for all note additions. Never call the Obsidian MCP vault_write tool unless the user explicitly requests it by name — vault_write overwrites the entire file.

Returns the resolved vault note path (both relative and absolute forms — try the relative one first, and fall back to the absolute one if the Obsidian MCP rejects it) so you can craft a contextual append. Use the Obsidian MCP vault_read tool on that path first to see the note's existing content before appending.

vault_root and chroma_path are optional — omit to use env vars.