Loading ToolBench
Shared, persistent memory across agents, IDEs, and context windows. Exposes an MCP server over stdio with semantic + keyword recall backed by SQLite and embeddings.
Gnar demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive parameter descriptions, and well-structured schemas using jsonschema tags. All 9 tools have descriptions (194 - 250 chars, within baseline 34 - 392 range) and input parameters with type annotations. However, output schemas are not formally documented in the code, only inferred from struct definitions. Error handling is minimal; tools return raw errors without recovery guidance. Tool composition is strong: each tool has a single responsibility, and chaining is supported via returned IDs. Missing: tool annotations (readOnlyHint, destructiveHint), structured error messages, and explicit output schema documentation.
Get an at-a-glance overview of a project's memory: last handoff, pinned items, decisions, todos, and recent notes.
Archive (or permanently delete) a memory by id.
Fetch a single memory by its numeric id.
Record a context-window handoff: the current goal, state, next steps, open questions, and files in play. Call this before your context fills up or before switching tools so the next agent can resume seamlessly.
List recent memories for a project, optionally filtered by kind.
Search shared memory by meaning and keywords. Returns the most relevant memories for the current project (or all projects).
Output schemas not formally documented. Return types (memoryOut, recallOut) are inferred from Go struct definitions but not exposed in tool registration or descriptions. LLMs cannot see what fields to expect.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). gnar_forget is destructive but unmarked; gnar_recall, gnar_get, gnar_list, gnar_resume, gnar_context are read-only but unmarked. Agents cannot infer safety/retry semantics.
Error handling returns raw Go errors without recovery guidance. No categorization (retryable vs user-fixable vs fatal). Example: 'project not found' should suggest 'Call gnar_list(all_projects=true) to see available projects.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Save a memory to shared storage so other agents/IDEs/future contexts can recall it. Use for decisions (with rationale), durable facts, todos, and reusable snippets.
Load where work left off for a project: the latest handoff plus pinned facts, recent decisions, and open todos, rendered as a brief. Call this at the start of a session.
Update fields of an existing memory by id (title, content, kind, tags, pinned).
gnar_list and gnar_recall lack explicit pagination. No 'offset', 'page', or 'next_cursor' parameters; no 'total_count' in response. Large result sets could exhaust context window.
gnar_forget accepts 'hard' boolean with no default documented. Destructive operations should require explicit confirmation or default to safe (archive, not delete).