Loading ToolBench
MCP server exposing agent-memory-daemon to Kiro, Claude Desktop, Cursor, and any MCP-compatible client.
This server exposes 4 memory management tools with clear naming (verb-noun pattern) and explicit descriptions. All tools have input schemas with type definitions and parameter descriptions. However, there are significant gaps in output schema documentation, error guidance, and parameter validation. The tools are relatively simple and well-intentioned, but lack the rigor expected of production-grade tools: no enum constraints, no documented return types, minimal error recovery guidance, and generic validation. Schema quality is moderate, all params have descriptions, but schemas lack depth (no minLength, maxLength, pattern constraints). Output schemas are not documented anywhere, forcing LLMs to infer structure. Error handling is minimal, tools throw generic errors without actionable guidance.
Append a session summary to the sessions directory. The daemon will later extract durable memories from it. Call this at the end of meaningful exchanges. Keep summaries focused on durable findings and decisions (target 300-800 tokens), not play-by-play — longer summaries cost more during consolidation.
Check whether the memory consolidation daemon is running. Reports if the daemon is not installed or not available on this platform.
Read the agent memory index (MEMORY.md) and optionally specific topic files. Call with no arguments to load only the lightweight index (cheap). Pass `topics` only when you need the full content of a specific topic file.
Search memory files for a substring. Use this to recall specific facts without loading everything.
No documented output schemas. Tools return {content: [{type: 'text', text: string}]} but LLMs cannot see this structure in tool definitions. The return type for each tool (index vs. search results vs. status) is undocumented.
memory_append_session: 'source' parameter is optional and unvalidated. Description says 'e.g. kiro, claude-desktop' but no enum constraint. LLM could pass arbitrary strings; sanitization is basic (regex replace). Should validate against known sources or document the constraint.
memory_read: 'topics' parameter lacks validation. No minLength, maxLength, pattern, or enum. Code sanitizes filenames (removes special chars) but the parameter description should document this constraint and explain why. LLM cannot predict valid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
memory_search: 'query' parameter is a free-form string with no constraints or length guidance. No mention of case-sensitivity (code uses toLowerCase). Error messages are minimal, if search fails or returns nothing, guidance is vague.
Error handling is minimal. All tools throw generic Error() with messages like 'content is required' or 'Unknown tool'. No recovery guidance. E.g., if topics don't exist, should return '(no matching topic files)', this works but doesn't guide the LLM on what to do next.
memory_append_session: No documented return value. Code returns 'Wrote session: {filename}' but LLM cannot tell if this is structured (e.g., {filename, path, timestamp}) or plaintext. Should document expected response format.
memory_daemon_status: Only available on macOS (LaunchAgent). Description mentions platform limitation but tool registration doesn't include a conditional availability marker or clear scope declaration. LLM may call this on Linux/Windows and get a degraded response.