Search code AND documents in the project's local index — your FIRST tool to find, explore or investigate anything here, before broad file reads or grep.

Runs a semantic hybrid search (vector + BM25, fused via RRF) over pre-indexed chunks of source code (classes/functions/methods) and documents (Markdown, text, JSON/YAML/ TOML). Pass natural language or exact symbols. For a structural overview instead, use atlas_map.

Token-efficient two-pass pattern: by default this returns metadata only (file_path, lines, symbol, type, score). Locate first, then read the exact lines with Read, or re-call with include_content=true for the few results whose content you actually need.

Call directly — do NOT call atlas_status first "just to check". If the index does not exist yet, this raises an actionable error explaining how to build it (see atlas_index).

Query the derived knowledge graph for hubs, paths, or neighborhood explanations.

Call this directly when the question is about connectivity, rationale, or centrality in the indexed workspace. It reads the derived graph.json produced by atlas_index; it does not rebuild the graph itself.

Retrieve a structured hierarchical tree map of classes, methods, and functions in the workspace.

Provides a compact, token-efficient overview of the codebase's architecture and logical structure. Use this to understand how the project is organized, list classes/functions/methods within folders, or find entrypoints without retrieving full file contents. To find a specific implementation, concept, or document instead — or to explore/investigate any area of the project — use atlas_search.

If the index does not exist yet, this raises an actionable error explaining how to build it (see atlas_index).

Get diagnostic metadata and health status of the local vector index.

Use this only for explicit diagnostics (e.g. the user asks about index health, staleness, or which repos/languages are indexed) or to decide whether atlas_index should be run. It is NOT a precondition for atlas_search/atlas_map — call those directly; they raise an actionable error themselves if the index is missing. Never indexes anything itself.

Returns: JSON string with index_exists, total_chunks, repos_indexed, languages_indexed, embedding_model, embedding_backend, storage_backend, index_path, index_resolution (how the index directory was resolved: "cli-arg" | "env" | "discovery" | "editor-project-dir" | "roots" | "roots-fallback" | "editor-project-dir-fallback" | "cwd-fallback" — useful to diagnose client misconfiguration when index_exists is unexpectedly false), last_indexed_at, git_head_sha, is_stale (true when the indexed git HEAD differs from the workspace's current HEAD), and reindexing (true when another process currently holds the reindex lock for this index).

Index (or re-index) source code and documents into the local search index.

Use to build the index the first time, or to refresh it after atlas_status reports is_stale: true or large changes.

IMPORTANT: unless the user already said what to index, call with dry_run=true first, show the candidate folders, and ASK whether to index everything or specific folders. Then call again with the chosen 'paths' (or none for the whole workspace).

Incremental by default: unchanged files (by content hash) are skipped, so re-runs are fast. full=true forces a complete rebuild.

full=true or empty/omitted 'paths' (whole-workspace) run asynchronously in a background subprocess and return immediately — poll atlas_status (reindexing: true while running). A non-empty 'paths' with full=false runs synchronously and returns stats directly.