manage_memoryManage an existing memory item. Currently supports deleting a memory by id (soft delete — recoverable for 30 days). Use search_memory to find the id first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The memory item id to act on. | |
| action | Yes | The management action to perform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint=true) and not read-only. The description adds valuable context by specifying 'soft delete — recoverable for 30 days', which goes beyond the mere destructive flag and informs the user about recovery options. This is meaningful additional behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does, the second provides the necessary precondition and usage hint. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool with no output schema, the description covers the essential context: what it does, how to use it (search first), and key behavior (soft delete). The annotations handle safety, and the schema handles parameter details. The description is fully sufficient for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters (action, id). The description adds semantic value by stating deletion is by id and clarifying that 'Currently supports deleting' means action is limited to delete. It also explains the effect of the delete (soft delete with 30-day recovery), which is beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Manage an existing memory item' with the current capability of 'deleting a memory by id'. It specifies the action (delete), the resource (memory item), and distinguishes from sibling tools like capture_memory and save_memory by noting this is for existing items and supports only deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to 'Use search_memory to find the id first', which is a direct usage guideline. It also implies the tool is for deletion only ('Currently supports deleting'), so users are directed away from using it for creation or searching. This is clear when/what/why guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct primary purpose: capture for automated extraction, save for explicit storing, search for retrieval, and manage for deletion. However, capture_memory and save_memory both write to memory and could be confused, though their descriptions clarify the different use cases.
All tool names follow a consistent verb_noun pattern with 'memory' as the object (capture_memory, manage_memory, save_memory, search_memory). This makes the API predictable and easy to navigate.
Four tools is well-scoped for a working memory server. Each tool covers a necessary operation (write, search, manage) without bloat or redundancy.
The core memory lifecycle is covered: saving, searching, and deleting. A notable gap is the lack of an update/edit operation, but users can work around it by saving a new memory and deleting the old one.