Loading ToolBench
MCP-compatible memory server backed by SQLite with semantic search, embeddings, and knowledge graph visualization
Memora provides 31 tools with consistent naming (all memory_* prefix), descriptions, and JSON Schema input definitions. However, critical gaps exist: (1) Output schemas are NOT documented anywhere, the rubric requires documented return types for 100% of A+ tools, yet none of the 31 tools show what fields they return; (2) Parameter descriptions are present but minimal (15-40 chars typically), below the 72-char baseline; (3) Error handling is absent, no tool describes recovery guidance, retryable vs fatal classification, or actionable error messages; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in the metadata; (5) Many tools accept numeric parameters (top_k, threshold, limit, boost_factor) with NO stated min/max ranges, 'top_k: integer' is unbounded and will allow absurd values like top_k=999999. (6) Destructive tools (memory_delete) have NO confirmation pattern or dry-run support. The naming is solid and schemas are present, but the lack of output documentation and parameter constraints represents a significant gap from production baselines.
Absorb external content (URLs, files, or raw text) into memories with semantic understanding
Automatically infer and backfill tags for untagged memories
Temporarily boost a memory's relevance in search results
Create a new memory with content, tags, and metadata
Create a memory specifically formatted as an issue/bug report
Create a document section memory within a hierarchy
Create a memory specifically formatted as a TODO/task
Output schemas are completely undocumented. The rubric requires 100% of A+ tools to have documented return types. None of the 31 tools show what fields they return, what structure clients should expect, or how to chain results into downstream tool calls. This violates the critical check in D. SCHEMAS & OUTPUT: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Delete a memory by ID (irreversible)
Detect clusters of related memories using graph analysis
Detect memories that supersede or replace other memories
Generate a digest/summary of memories matching criteria
Export memories to JSON or Markdown format
Find potential duplicate memories based on similarity
Retrieve a single memory by ID with all metadata and relationships
Get cross-references and relationships for a memory
Retrieve a complete document with all its sections
Search memories using both semantic and keyword-based search combined
Import memories from JSON or Markdown file
Generate insights from memory database using LLM analysis
Create a directed link/relationship between two memories
List all memories with full details including metadata and relationships
List all memories in compact format (IDs, summaries, tags) for efficient querying
Migrate embedded images to cloud storage (R2/S3)
Rebuild memory cross-reference links
Rebuild semantic embeddings for all memories (expensive operation)
Find memories semantically related to a given memory ID
Search memories using semantic similarity based on embeddings
Get statistics about the memory database (counts, dates, tags)
Store a complete document as a memory hierarchy with sections
List all available tags and their usage counts
Update an existing memory's content, tags, or metadata
Numeric parameters lack min/max bounds. Tools like memory_semantic_search (top_k: integer), memory_list_compact (limit, offset: integer), memory_boost (boost_factor: number 1.0-10.0, duration_hours: integer), and memory_find_duplicates (threshold: number) are unbounded or only partially bounded. An LLM can pass top_k=999999, causing memory exhaustion or API failures. The rubric critical check states: 'Specify minimum and maximum for numeric parameters (e.g. page_size 1 - 100, days 1 - 365). Unbounded numbers let LLMs pass absurd values that break APIs or cause timeouts.'
Error handling is absent across all tools. No tool describes what errors can occur, how to recover, whether failures are retryable, or what the LLM should do next. The rubric critical check states: 'Error responses must tell the LLM what to do next: "User not found. Try search_users() with a partial name." A raw error code or stack trace gives the agent nothing to act on.' Additionally, destructive operations (memory_delete, memory_migrate_images, memory_backfill_tags) lack recovery guidance and confirmation patterns.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. The tools declare Risk: READ_ONLY, WRITE, DESTRUCTIVE, but these are not reflected in JSON Schema or MCP tool annotations. The MCP spec supports tool annotations to let clients display warnings, disable destructive operations, or allow read-only replay. Tools like memory_delete (DESTRUCTIVE), memory_import (WRITE), and memory_rebuild_embeddings (WRITE) should carry destructiveHint or idempotentHint annotations.
Parameter descriptions are uniformly minimal (15-40 chars), well below the 72-char baseline. Examples: 'Search query text' (17 chars), 'Number of results to return' (28 chars), 'Memory ID to retrieve' (21 chars). The rubric states: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites. LLMs do not infer, they need explicit, complete descriptions.' These terse descriptions do not explain when to use each search variant (semantic vs hybrid), what format the query should take, or what happens if a parameter is omitted.
Destructive operation (memory_delete) lacks confirmation or dry-run pattern. The tool deletes memories irreversibly with no warning, pre-check, or undo mechanism. The rubric critical check states: 'Irreversible operations (delete, send, publish) should support a dry-run or confirmation step. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.'
Pagination parameters (limit, offset) are poorly designed. Tools like memory_list_compact and memory_list offer limit and offset but do NOT return a total_count or next_cursor, making it impossible for an LLM to know whether more results exist or what offset to use next. The rubric states: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor. Without pagination, large results blow the context window.'
Tools that modify state (create, update, delete, absorb) do not document idempotency. The rubric states: 'Make tools produce the same result on repeated calls with the same input. Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects (double charges, duplicate records).' If memory_create is called twice with identical content, does it create a duplicate or return the existing ID?
Parameter relationships are undocumented. For example, memory_semantic_search has top_k and min_score, but the descriptions do not explain whether both must be provided, whether min_score filters before or after top_k ranking, or what happens if min_score threshold exceeds all results. The rubric states: 'When one parameter's valid values depend on another... document this in both parameter descriptions.'