Loading ToolBench
Cross-provider persistent memory system for AI coding assistants
BrainBase defines 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (memory_search, memory_add, memory_context). Descriptions are detailed (100-250 chars) and explain WHEN to use each tool. However, output schemas are entirely undocumented, no response structure is specified anywhere in the code. Parameters lack type constraints (e.g., 'mode' enum is declared but 'importance' has no min/max bounds). Error handling is absent from tool definitions. The memory_process_message tool has a problematic design: it instructs the LLM to call it with EVERY message, which violates single-responsibility and creates unnecessary overhead. Session management via session_id parameters is present but not consistently required, creating ambiguity about when sessions are active.
Store a new memory in the brain. Use this to save important information the user shares: preferences, decisions, project details, learnings, or anything worth remembering. The memory will be automatically linked to related existing memories.
Call this at the START of every conversation to load what I've told you before. Returns my identity, preferences, workflows, projects, and session history. Without this you'll ask me things I've already answered.
Call this with EVERY message I send you BEFORE you respond. This is my persistent brain — it remembers everything across our sessions. Pass my full message. Returns context from our previous conversations that you should use. Without this, you won't remember anything about me. Don't skip this.
Find memories related to a topic using spreading activation. Unlike search, this follows connections in the knowledge graph to find indirectly related memories. Good for discovering connections the user might not expect.
Create a prospective memory - a reminder that triggers when certain keywords appear in future conversations. Use this when the user says "remind me about X when Y" or wants to remember something for a future context.
No output schemas documented. Tools return ToolResult with text content, but the structure of returned data (fields, types, pagination) is invisible to LLMs. This forces agents to parse unstructured text and prevents chaining.
memory_process_message violates single-responsibility by instructing LLMs to call it with EVERY message. This creates overhead, wastes tokens, and couples the tool to agent behavior rather than letting the agent decide when context is needed.
Parameter constraints are incomplete. 'importance' (0.0-1.0) lacks min/max bounds in schema. 'limit' parameters have no documented upper bound, risking unbounded result sets. 'mode' enum is declared but other string params lack validation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Search what I've told you before INSTEAD of asking me again. If I mention a topic we discussed before, search here first. Returns my preferences, decisions, workflows, and facts from previous conversations.
Get brain statistics: total memories, connections, patterns, sessions, and memory types. Use this to check the health and size of the memory system.
No error handling guidance. Tools return ToolResult with isError flag, but no recovery instructions, categorization (retryable vs fatal), or actionable error messages are defined.
Session management is optional but inconsistently documented. session_id parameters are marked optional in all tools, but memory_process_message's description implies it should be called every turn. Unclear whether sessions are required for persistence or advisory.