Persistent memory and code intelligence for AI coding agents
nano-brain demonstrates good definition quality overall with consistent naming conventions, comprehensive parameter documentation, and detailed descriptions. All 19 tools are verb-noun named (memory_*), follow a coherent pattern, and include descriptions longer than the 194-char baseline average. Parameters are well-described with constraints and context. However, there are significant gaps in output schema documentation, while input schemas are thorough, return types are not explicitly documented in the visible code. Error handling is minimal in the examined code. The tool set is well-composed with clear single responsibilities, though some tools (memory_query, memory_search, memory_vsearch) represent overlapping functionality that could confuse LLM selection.
Delete a document from memory by UUID or source path. Deletes all associated chunks and embeddings. Irreversible.
HTTP/request execution-flow diagram: trace route-level request handling and middleware. Returns execution order and endpoint handlers. Use for route-level questions.
Function-level control-flow graph: diagram all branches, conditionals, and decision points within a single function. Returns flowchart nodes and edges.
Retrieve the full text of a single document by UUID or source path after memory_query, memory_search, or memory_vsearch returns a result. Specify line ranges to extract subsets. Returns null if document not found.
One-hop code graph lookup: find direct callers and callees of a symbol. Requires a prior memory_symbols result. Returns call edges with file locations. Use for immediate call context before memory_trace.
Pre-change blast-radius analysis: compute downstream impact of editing a symbol. Returns all reachable callees and their fan-out depth. Call before making breaking changes.
Output schemas not documented. While input schemas are comprehensive with types and descriptions, return/output types are not visible in the examined code (tools.go shows only input schema construction via toolSchema()). LLMs cannot predict downstream field availability or plan multi-step chains without knowing what fields are returned.
Three search tools (memory_query, memory_search, memory_vsearch) provide overlapping functionality with minimal differentiation in their descriptions. The descriptions mention fallback behavior ('follow up with memory_search only when results look insufficient'), but this creates cognitive overhead for LLM tool selection. Consider consolidating search hints or providing clearer usage patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 78 | 2026-07-28+ | v2 |
DEFAULT FIRST TOOL for broad agent questions. Combines keyword BM25 search, semantic vector search, and code symbol matching in a single unified query. Returns up to max_results documents ranked by relevance. Use this first for any question; follow up with memory_search (exact keyword/error messages) or memory_vsearch (fuzzy semantic) only when results look insufficient.
Exact keyword/BM25 search for error messages, code snippets, and specific phrases. Use when memory_query results lack exact matches or you need precise keyword ranking. Falls back to semantic search if keyword results are sparse.
Check if search results look stale or embeddings are out of sync. Returns queue status, pending document count, and average embedding staleness. Call this if search results are sparse or memory_wake_up times out.
Code symbol lookup: find definitions of a function, method, or class by name. Returns symbol type, file location, and definition snippet. Use before memory_graph for deeper analysis.
List all tags in a workspace, optionally filtered by a tag prefix. Returns distinct tags with their usage counts. Does not accept workspace='all'.
Retrieve all sessions (summaries) related to a ticket ID (e.g. 'DEV-4706'). Searches across all workspaces by ticket tag. Returns session titles, content, and workspace context. Cross-workspace result aggregation.
Downstream call-chain trace: find all functions that eventually call a target symbol. Useful for understanding which execution paths eventually invoke a given function.
Modify an existing document's content, title, or tags. Automatically re-chunks and re-embeds if content changes. Does not accept workspace='all'.
Fuzzy semantic/vector search for concept-level questions where exact words may differ. Use when memory_query returns no results or you need fuzzy semantic matching across similar ideas.
Session-start workspace briefing: returns recent memory and session summaries (createdAt within last N days). Call this before deeper search to warm up context. Filters to memory and sessions collections only.
List all registered workspaces with their paths, hashes, and document counts. Call at session start to discover available memory contexts.
Resolve a workspace path to its hash, name, or list all registered workspaces. Use when you need to determine the correct workspace identifier for other tools.
Persist a durable decision, architectural choice, or context for future agents. Stores content as a new memory document with optional title, tags, and explicit source_path. Automatically splits into chunks and generates embeddings. Returns the new document ID.
No visible error handling or recovery guidance in examined tool definitions. Tools like memory_delete (DESTRUCTIVE) and memory_write (WRITE) lack explicit confirmation/dry-run patterns or error messages that guide LLMs on what to do if operations fail.
memory_status has empty input schema (no parameters required), which is correct but the description could better explain what constitutes 'stale' results or how staleness is measured. This affects actionability for the LLM.
Workspace parameter naming inconsistency: some tools require workspace='all' to be rejected (memory_get, memory_update, memory_tags), while others accept it. This conditional behavior should be made more explicit in parameter descriptions or tool names (e.g., separate tools for workspace-scoped vs cross-workspace queries).