Loading ToolBench
MCP server for memory management with storage, search, workspace organization, and embedding-based semantic search capabilities
Memorizer provides 12 well-structured tools with strong naming conventions (all verb-first: Store, Edit, Get, Search, etc.) and comprehensive descriptions. However, the server has critical gaps in parameter schema completeness and structured output documentation. While tool descriptions are clear and address WHEN/HOW to use each tool, the input schemas visible in the source code lack formal type constraints for most parameters, parameters like 'type' in Store are described as strings but not constrained via enums. Output schemas are completely undocumented across all tools, making it impossible for agents to know what fields to expect in responses. Parameter descriptions are generally good (60-150 chars average), but several parameters lack depth around constraints and dependencies. Error handling guidance is minimal, tools do not document recovery paths or suggest alternatives when operations fail.
Create a new project within a workspace. Projects are organizational units that can contain memories and inherit workspace context.
Create a semantic relationship between two memories. Relationships help organize knowledge graphs and link related content.
Create a new workspace. Workspaces are top-level organizational containers representing major business areas or domains (e.g., 'Engineering', 'Sales', 'Akka.NET'). Workspaces persist indefinitely and contain projects. Memories can belong directly to a workspace OR to a project within a workspace.
Delete a memory by ID. This operation is permanent and cannot be undone.
Edit an existing memory using find-and-replace. Ideal for checking off to-do items, updating sections, or fixing typos. IMPORTANT: The edit will FAIL if old_text is not found exactly - always use Get first to see current content and copy the exact text to replace. All changes are versioned and can be reverted.
Retrieve a memory by ID to view its full content, metadata, and version history.
Output schemas completely undocumented. No tool specifies what fields the response will contain, what types they are, or how the LLM should interpret them. This violates pattern:tool and mxe:response-shaper, agents cannot plan downstream calls or extract necessary IDs without guessing structure.
Input parameters lack enum constraints for free-form string inputs. 'type' in Store accepts 'conversation', 'document', 'reference', 'how-to', 'todo-list', etc., but is declared as a plain string with no enum constraint. This invites hallucinated values and forces LLMs to guess. Similarly, 'relationshipType' in CreateRelationship has no enum.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Get workspace information. Without an ID, lists root workspaces with hints about nested content. With an ID, shows detailed workspace info. With a query, searches all workspaces by name. Workspaces are organizational containers (e.g., 'Engineering', 'Sales') that persist indefinitely and can be nested.
List all projects in a workspace or search for projects by name. Projects are child organizational units within workspaces that can contain memories.
Revert a memory to a previous version. Reverts the text content to a specific version number while keeping metadata unchanged.
Search memories by semantic similarity using embeddings. Supports filtering by tags and workspace/project scoping. Returns memories ranked by relevance with similarity scores.
Store a new memory in the database, optionally creating a relationship to another memory. Use this to save reference material, how-to guides, coding standards, or any information you (the LLM) may want to refer to when completing tasks. Include as much context as possible, such as markdown, code samples, and detailed explanations. Create relationships to link related reference materials or examples.
Update a memory's metadata (title, type, tags, confidence) without changing the content text. Useful for re-categorizing, adding tags, or updating confidence scores.
Error handling guidance missing. Tools do not document what errors are possible, whether they are retryable, or what recovery steps the LLM should take. For example, Edit can fail if 'old_text' is not found exactly, but no guidance tells the agent to retry with Get first.
Destructive operations (Delete) lack confirmation or dry-run capability. Agents can permanently delete memories without a safety mechanism. No tool offers a confirm_before_execute pattern.
Parameter dependency documentation is sparse. Edit's 'old_text' matching is brittle and case-sensitive, but the parameter description does not highlight the risk or suggest calling Get first to verify exact text. UpdateMemoryMetadata does not clarify which fields are optional vs required or how partial updates behave.
Parameter 'cancellationToken' appears in all tools but is never described or explained. Its purpose and how the LLM should interact with it is opaque. This suggests incomplete parameter documentation.
Tool descriptions omit discovery guidance. No tool explains what information is returned so the LLM can plan chaining calls. For example, Search does not state 'Returns memory IDs that can be passed to Get()', breaking the tool chain pattern.
Pagination not documented. Search and ListProjects accept 'limit' but do not specify whether there is a next cursor, total count, or how to retrieve more results. Large result sets risk context window exhaustion.