Loading ToolBench
A persistent memory system for storing and retrieving context across conversations using semantic search with PostgreSQL+pgvector or SQLite+FAISS backends
Server implements 6 tools with reasonable descriptions and parameters, but suffers from critical duplication issues and incomplete schema visibility. Three distinct tool responsibilities (store_memory, update_memory, search_memories) are registered twice with nearly identical definitions, indicating poor composition and maintenance. Parameter schemas are present in the provided input descriptions but vary in completeness. Descriptions are moderately detailed (150-400 chars) and include examples, but lack explicit output schema documentation in the source code. No error handling guidance is visible. Tool naming follows verb_noun conventions appropriately.
Search for memories within a specific domain or the default domain. This tool provides semantic search (if Ollama is available) or text search across memories in the specified domain. Domain segmentation ensures queries return contextually relevant results. Parameters: - query (str): The search query to find relevant memories. Examples: * "What does the user like for breakfast?" * "programming projects and preferences" * "work meetings this week" * "personal goals and aspirations" - domain (str, optional): The domain to search within. If not specified, searches the default domain. Examples: * "startup" - business memories * "health" - health information * "personal" - personal data - limit (int, optional): Maximum number of memories to return (default: 5). Range: 1-20. Higher values may include less relevant results. Returns: List[Dict[str, Any]]: A list of memory objects with search metadata: - id (str): Unique memory identifier - content (str): The stored memory content - metadata (dict): Memory metadata (source, importance, timestamps) - score (float): Relevance/similarity score - query (str): The original search query (for reference)
Search for memories using advanced semantic search with optional fallback. This tool provides more control over the search process compared to the resource. It allows you to choose between semantic vector search and traditional text search, and returns additional metadata about the search process. Parameters: - query (str): The search query to find relevant memories. Examples: * "What does the user like for breakfast?" * "programming projects and preferences" * "work meetings this week" * "personal goals and aspirations" - limit (int, optional): Maximum number of memories to return (default: 5). Range: 1-20. Higher values may include less relevant results. - use_vector (bool, optional): Whether to use semantic vector search (default: True). * True: Uses AI embeddings for semantic understanding * False: Uses traditional keyword-based text search If vector search fails, automatically falls back to text search. Returns: List[Dict[str, Any]]: A list of memory objects with search metadata: - id (str): Unique memory identifier - content (str): The stored memory content - metadata (dict): Memory metadata (source, importance, timestamps) - score (float): Relevance/similarity score - query (str): The original search query (for reference)
Critical duplication: store_memory, update_memory, and search_memories are each registered twice with nearly identical signatures and descriptions. This violates the single-tool-per-responsibility pattern and confuses LLMs deciding between near-duplicate options.
No visible output schema documentation in source code. Descriptions claim to return structured objects (List[Dict[str, Any]] for searches, str/bool for mutations) but formal JSON Schema output definitions are not present. LLMs cannot infer downstream field names without schema documentation.
Missing error handling guidance. No descriptions of what happens on failure (e.g., 'memory_id not found', 'Ollama service unavailable'). LLMs have no recovery strategy when these tools fail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Store a new memory chunk in the persistent memory system. This tool allows you to save important information that should be remembered across conversations. The content will be automatically indexed for semantic search (if Ollama is available) or text search. Parameters: - content (str): The text content to remember. This can be facts, preferences, context, or any information that should persist. Examples: * "User prefers Python over JavaScript for backend development" * "Meeting scheduled for Tuesday at 3pm about project planning" * "User's favorite color is blue and they work in San Francisco" - domain (str, optional): The domain/context for this memory. Memories are segmented by domain for better retrieval accuracy. Defaults to 'default'. Examples: * "startup" - for business-related memories * "health" - for health-related information * "personal" - for personal preferences - source (str, optional): Where this memory originated from. Examples: * "conversation" * "document" * "email" * "meeting_notes" - importance (float, optional): Importance score from 0.0 to 1.0 where: * 0.0-0.3 = Low importance (casual mentions) * 0.4-0.7 = Medium importance (useful context) * 0.8-1.0 = High importance (critical information) Returns: str: A unique memory ID that can be used to update or reference this memory later.
Store a new memory chunk in the persistent memory system. This tool allows you to save important information that should be remembered across conversations. The content will be automatically chunked and indexed for semantic search. Parameters: - content (str): The text content to remember. This can be facts, preferences, context, or any information that should persist. Examples: * "User prefers Python over JavaScript for backend development" * "Meeting scheduled for Tuesday at 3pm about project planning" * "User's favorite color is blue and they work in San Francisco" - source (str, optional): Where this memory originated from. Examples: * "conversation" * "document" * "email" * "meeting_notes" - importance (float, optional): Importance score from 0.0 to 1.0 where: * 0.0-0.3 = Low importance (casual mentions) * 0.4-0.7 = Medium importance (useful context) * 0.8-1.0 = High importance (critical information) Returns: str: A unique memory ID that can be used to update or reference this memory later.
Update an existing memory chunk with new information. This tool allows you to modify previously stored memories. You can update the content, change the importance level. If updating content, the memory will be re-indexed for search. Parameters: - memory_id (str): The unique ID of the memory to update (returned from store_memory). Example: "mem_1234567890123" - content (str, optional): New content to replace the existing memory content. If provided, this completely replaces the old content. Example: "User prefers React over Vue for frontend projects" - importance (float, optional): New importance score from 0.0 to 1.0. * 0.0-0.3 = Low importance * 0.4-0.7 = Medium importance * 0.8-1.0 = High importance - domain (str, optional): The domain where this memory is stored. If not specified, uses the default domain. Returns: bool: True if the update was successful, False if the memory_id was not found.
Update an existing memory chunk with new information. This tool allows you to modify previously stored memories. You can update the content, change the importance level. If updating content, the memory will be re-indexed for semantic search. Parameters: - memory_id (str): The unique ID of the memory to update (returned from store_memory). Example: "mem_1234567890123" - content (str, optional): New content to replace the existing memory content. If provided, this completely replaces the old content. Example: "User prefers React over Vue for frontend projects" - importance (float, optional): New importance score from 0.0 to 1.0. * 0.0-0.3 = Low importance * 0.4-0.7 = Medium importance * 0.8-1.0 = High importance Returns: bool: True if the update was successful, False if the memory_id was not found.
Inconsistent parameter naming between variants: variant 1 of store_memory includes 'domain' parameter; variant 2 omits it. This inconsistency will cause LLM confusion when selecting between duplicate tools.
search_memories variants differ: variant 1 is resource-backed (memory://{domain}/{query}); variant 2 is a direct tool with use_vector parameter. This creates ambiguity about which to call and how search behavior differs.
No pagination support visible. search_memories accepts 'limit' but no offset/cursor mechanism for iterating beyond the initial result set. Large memory stores could be impossible to fully traverse.