Loading ToolBench
A cheap, persistent, read-only codebase memory for Claude Code — a large-context model that accumulates repo knowledge across sessions and answers via ask_live_memory instead of re-reading files.
Live Memory provides well-structured tool definitions with complete schemas and descriptions for all 7 tools. Naming follows verb_noun conventions (ask_live_memory, get_changed_files, git_search). Descriptions are detailed (100-300 chars) and explain WHAT, WHEN, and WHY. All parameters have types and descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; tools lack recovery guidance. The ask_live_memory tool is particularly strong with clear context about the persistent memory model. Read-only risk classification is correct but not formally annotated in schemas.
Find files by glob pattern (relative to the workspace root). Returns matching paths, sorted. Use find_paths instead when you need directories, a type/depth filter, or to enumerate the tree.
Search file contents with ripgrep (regex). By default returns matching 'file:line:text'; set output_mode to 'files_with_matches' for paths only, or 'count' for per-file match counts.
Read a slice of a UTF-8 text file, returned with line numbers. The path is relative to the workspace root.
Ask the Live Memory about the codebase at `cwd`. The Live Memory is a persistent, read-only companion that accumulates knowledge of *this* repository across questions and sessions. It runs a separate, cheap, large-context model and explores on its own (read, grep, glob, git history), so it can answer "where is X / how does Y work / what calls Z / what's the convention for W" without you loading files into your own context — and it often already knows the answer from earlier questions. It returns a best-effort answer within its server-configured time budget: grounded in the actual code, but terser than your own reasoning. Its working context stays private; it never edits code.
Walk the directory tree and list entries (files and/or directories) under a path, filtered like the `find` CLI — by name pattern, entry type, and depth. Use this to explore structure or list directories; use Glob when you just want files matching a glob.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Tools return truncated text but no schema describes the ToolResult format or field names.
No error handling guidance. Tools truncate output silently (MAX_TOOL_OUTPUT_BYTES) but do not tell LLMs what to do when results are incomplete. No recovery suggestions for missing files, failed git commands, or regex errors.
get_changed_files has minimal description (19 chars: 'Files changed in the working tree (git status --porcelain).'). Does not explain when to use it vs git_search, what fields are returned, or format of output.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Files changed in the working tree (git status --porcelain).
Inspect git commit history. Filter by commit-message text (query) and/or a file/dir path, and optionally include the patch (diff) for each commit. With no query and no path, returns the most recent commits.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint in schemas. All tools are read-only but this is not formally declared in the schema, LLMs must infer from descriptions.
Glob and find_paths have overlapping purpose. Descriptions explain the distinction ('Use find_paths for directories, type/depth filter; use Glob for glob patterns') but LLMs may still conflate them. Consider consolidating or renaming for clarity.