Loading ToolBench
Persistent, semantic memory for AI agents - mcp-native, local-first, framework-agnostic, production-ready
GroundMemory provides 7 tools with reasonable descriptions and basic schemas. Naming follows verb_noun convention (memory_read, memory_write, memory_relate). However, the dispatcher pattern (memory_tool) violates single-responsibility principle by routing 6 different actions through one tool. Parameter descriptions are present but often generic (e.g., 'Optional arguments for the action'). Output schemas are not documented, responses are JSON strings without declared structure. Error handling is minimal; the _unwrap() helper raises ValueError but provides no recovery guidance. Tool descriptions average ~150 chars, within baseline (194 chars), but lack WHEN/WHY context. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. memory_bootstrap is well-designed as a Prompt primitive, but memory_compact lacks detail on LLM integration and token savings.
Return the workspace memory context as an MCP Prompt. MCP clients that support the Prompts primitive (e.g. Cline, Claude Desktop) can invoke this prompt at session start to inject the full memory context without requiring the agent to call a tool first.
Compress memory content in a specified tier using LLM-powered summarization to reduce token usage while preserving semantic meaning
List all tracked memory files and their metadata (size, last modified, chunk count)
Search and retrieve memory entries using semantic search (vector similarity) or keyword search (BM25), with optional file and line-range filtering
Record named entity relationships in a knowledge graph (subject-predicate-object triples) with optional confidence scores and notes
Dispatcher tool that routes memory operations (bootstrap, read, write, relate, list, compact) through a single unified interface
memory_tool dispatcher violates single-responsibility principle. Routes 6 distinct actions (bootstrap, read, write, relate, list, compact) through one tool with a free-form 'action' string and optional 'args' dict. LLMs cannot infer which action to invoke without reading implementation details. Splits tool discovery and increases error surface.
Output schemas not documented. All tools return JSON strings via _unwrap(), but the structure of success/error responses is not declared. LLMs cannot plan downstream calls or extract fields reliably. E.g., memory_read returns JSON but no schema specifies whether results include 'file', 'line_number', 'content', 'score' fields.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. memory_write, memory_relate, memory_compact are marked WRITE but lack destructiveHint annotation. memory_read is READ_ONLY but lacks readOnlyHint. Agents cannot infer safety without annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Write or update memory entries in a file, with support for content replacement, line-range updates, and semantic tagging
Error handling provides no recovery guidance. _unwrap() raises ValueError on non-ok status, but error messages are opaque ('unknown error'). No guidance on retryability, user-fixable vs fatal, or next steps. Agents cannot self-correct.
Parameter descriptions lack specificity. memory_tool's 'args' is described as 'Optional arguments for the action', does not explain which args apply to which action. memory_compact's 'tier' lacks enum constraint or valid values. memory_read's 'top_k' lacks min/max bounds.