Loading ToolBench
Shared memory layer for AI coding agents — self-hosted, sovereign, zero-instrumentation. Provides memory management, consultation, and dream pipeline tools via FastMCP.
Mori provides 9 well-intentioned tools with complete input schemas and generally clear descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and composition clarity. Tool naming is verb-based and appropriate (brief, consult, dream, add, update, remove, search, check_freshness, list_memories). Descriptions range from adequate to good (80-250 chars), explaining the core purpose and some context. Input parameters are well-typed with enums where appropriate (focus, tier, depth). The main weaknesses: (1) NO documented output schemas for any tool, LLMs cannot plan downstream calls or know what fields to expect; (2) error handling lacks actionable recovery guidance; (3) destructive operations (remove, update, dream with force) lack confirmation/dry-run patterns; (4) some descriptions missing parameter relationships (e.g., how focus interacts with other filters in brief). The 'consult' tool with LLM integration is sophisticated but underdocumented in terms of API failures, token limits, and model selection. Scores range per-tool: brief (68), consult (58), dream (55), add (65), update (62), remove (60), search (70), check_freshness (60), list_memories (65).
Write a new memory to working tier. Returns the memory ID and write disposition (deduplicated, inserted, etc.).
Retrieve structured memory briefs scoped to a focus area (e.g., 'architecture', 'security'). Returns the agent's working memory snapshot with optional freshness scoring.
Run an LLM freshness check on a memory (bounded, single-memory operation). Flags whether the memory's content is still accurate and applicable.
Synchronous LLM consultation: pose a question, attach source code/context, and receive expert technical advice with mandatory evidence labeling ([QUOTED], [CONTEXT], [INFERRED], [ASSUMED]) and a 'COULD NOT VERIFY' section.
Asynchronous background task: distill and promote memories from working → canonical tier. Runs periodically; can be invoked on-demand to trigger immediate distillation.
List all memories with optional filtering by tier or tags.
NO OUTPUT SCHEMAS DOCUMENTED for any of the 9 tools. LLMs cannot plan downstream calls, extract required fields for chaining, or validate responses. This violates pattern:tool and mxe:include-chaining-ids.
DESTRUCTIVE OPERATIONS (remove, update, dream force=true) lack confirmation/dry-run pattern. An agent could irreversibly delete memories without safeguards.
Error handling guidance absent across all tools. No recovery patterns, no categorization of retryable vs. fatal errors, no guidance on what to do if a memory ID is not found or API fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Delete a memory by ID.
Full-text and semantic search over memories. Returns ranked results matching the query across all tiers.
Modify the content or tags of an existing memory by ID.
consult tool integrates LLM without documenting failure modes: model unavailability, token limits, cost, latency, or invalid evidence labeling. No guidance on what to do if LLM response is unhelpful.
Parameter relationships undocumented. E.g., does focus in brief interact with filters in list_memories? If tags are passed to update, are existing tags replaced or merged? These dependencies must be explicit.
Pagination support unclear or missing. search and list_memories accept limit but no cursor/offset or total_count. Agents cannot iterate safely over large result sets without risking context explosion.
Idempotence guarantees absent. Can add be called twice with identical content? Will it deduplicate? Can remove be safely retried? Agents need idempotence to recover from network failures.