Loading ToolBench
Persistent memory plugin for Kimi Code CLI. Search past observations, recall details, and get project context via semantic or full-text search.
kimi-mneme has 7 well-named, read-only memory search/recall tools with clear purposes. All tools have descriptions and visible input schemas. However, descriptions are inconsistent in depth, some lack WHEN/WHY guidance, and parameter descriptions could be more explicit about constraints, formats, and edge cases. Output schemas are not documented (critical gap for agent planning). Error handling is not evident in the visible code. The tool set is well-composed for a specialized domain (persistent memory access) but falls short of production-grade clarity.
Search observations by concept tag.
Search observations by file path.
Get full details for a specific structured observation.
Search memory index with full-text queries. Searches across BOTH structured observations (AI-compressed) and raw observations (full tool calls). Returns structured results first, then raw observations as fallback.
Semantic search over memory using embeddings (sqlite-vec). Finds observations by meaning, not just keyword matching. Great for: "find similar code patterns", "what did I do about auth?", "show me discoveries about performance". NOTE: First call loads the embedding model (~10s). Subsequent calls in the same session are fast. If model loading fails, falls back to FTS search.
Get memory statistics.
Output schemas not documented. LLMs cannot plan downstream calls or extract field names without knowing what each tool returns. Critical for agent reasoning.
Parameter descriptions lack constraint detail. 'limit' has a default but no minimum/maximum bounds. 'query' has no guidance on FTS5 syntax rules or max length. 'days' for recency filter has no explicit range (what if days=999999?).
memory_recall description is vague: 'Get full details for a specific structured observation.' Does not explain what 'full details' includes or when to call this vs memory_search. No guidance on relationship to search results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Get chronological structured observations for a session.
memory_stats description is extremely sparse (3 words). Does not explain what statistics are returned (count, size, date range, model info?). LLM cannot reason about when to call this.
memory_semantic_search has a side effect: 'First call loads the embedding model (~10s).' This is not reflected in the tool description's error handling or retry guidance. If an agent calls this without context, it may timeout or fail without understanding why. Model loading failures fall back to FTS silently, but agents don't know this happened.
No error handling guidance visible in any tool. What happens if query is empty, observation_id doesn't exist, session_id is invalid, or embedding model fails? Agents need actionable recovery steps ('try memory_search()' or 'check session_id format').
memory_by_concept and memory_by_file accept string patterns but do not document regex syntax, exact match vs substring, or case sensitivity. 'concept' and 'file_path' are too generic, agents cannot predict valid values without examples.
memory_timeline references 'session_id' but does not explain where session IDs come from, what format they have, or how to discover them. Agents cannot construct valid session_id without prior context or discovery tools.