Loading ToolBench
AI-native file database and memory store for LLM agents to read, search, and remember files across any format (PDF, DOCX, PPTX, XLSX, code, images with OCR)
OpenDB provides 13 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (opendb_read, opendb_search, etc.). Descriptions are substantive (100-250 chars typical), explaining WHAT and WHEN. However, several tools lack parameter descriptions, and output schemas are not documented. Error handling guidance is absent. The memory tools (store/recall/forget) and workspace management tools are well-named but lack depth on error cases and recovery paths. Overall: solid foundation with gaps in completeness.
Add a new workspace directory to OpenDB. Workspaces are indexed separately and can be switched between.
Build compact context from indexed code symbols plus full-text hits. Use this after opendb_search finds a concept, or directly when you know a symbol/function/class name. It returns locations and small snippets instead of dumping entire files into the agent context.
Get the currently active workspace path.
Find files matching a glob pattern, sorted by modification time (newest first). Use this as the first step to discover files in a workspace before reading them with opendb_read.
Get workspace overview: file counts by status and type, recently updated files. Use this as the first step when entering a new workspace to understand what's available before searching or reading files.
List all registered workspaces.
Output schemas not documented. Tools like opendb_read, opendb_search, opendb_context return data but no schema is visible for what fields/structure the LLM should expect. This forces LLMs to guess at response structure and breaks tool chaining.
Workspace management tools (add_workspace, use_workspace, remove_workspace, current_workspace, list_workspaces) lack error handling guidance. No description of what happens on invalid paths, permission errors, or missing workspaces. LLM has no recovery path.
Memory tools (store, recall, forget) lack idempotency and confirmation semantics. opendb_memory_forget is destructive but has no dry-run or confirmation step. Agents could accidentally delete memories without recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Delete a memory from the agent's persistent memory store by ID.
Recall memories from the agent's persistent memory store. Searches by keyword or returns recent memories.
Store a memory/fact in the agent's persistent memory store. Memories are indexed and searchable across sessions.
Read any file — code with line numbers, documents as plain text, spreadsheets as structured JSON. Supports page/line filtering, in-file grep, and OCR for scanned images. Use this for all file reading: source code, PDFs, Word docs, Excel sheets, images.
Remove a workspace from the registry. Does not delete the directory.
Search across code files (regex) and documents (full-text). Two modes: grep (regex search on code files), fts (full-text keyword search on indexed documents). Auto-detects mode: path/glob present → grep, otherwise → fts.
Switch to a different workspace. All subsequent read/search operations will use this workspace.
Parameter descriptions are minimal or absent for several tools. opendb_info has empty input schema (no params), but description does not explain what 'workspace overview' includes. opendb_memory_store 'tags' param lacks guidance on format/cardinality.
No pagination or result limits documented. opendb_search accepts 'limit' and 'offset' but no guidance on max results, default behavior, or what happens when result set is huge. opendb_memory_recall similarly lacks limits.