memory_forget
Delete a stored memory by its ID to remove outdated or unwanted entries from Cortex Intelligent's long-term memory.
Instructions
Delete a memory by ID
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Delete a stored memory by its ID to remove outdated or unwanted entries from Cortex Intelligent's long-term memory.
Delete a memory by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and for a deletion tool it omits the most important facts: whether the delete is permanent or soft, whether it is reversible, and what happens if the ID does not exist. 'Delete' implies destruction, but nothing confirms irreversibility.
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?
A single front-loaded sentence with zero filler. It is efficiently written, though arguably too terse for a destructive operation where a little more text would earn its place.
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 mutation tool with no annotations, no output schema, and no parameter documentation, the definition is incomplete: an agent cannot tell whether the operation is recoverable, what the response contains, or how to recover from a bad ID.
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 description coverage is 0%, so the description must supply the meaning of the single parameter. 'By ID' does establish that the string identifies a memory, which is the essential semantic, but it gives no format, no hint about where to obtain the ID, and no error behavior for an invalid ID.
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?
States a specific verb ('Delete') and resource ('a memory') plus the identifying key ('by ID'), which cleanly separates it from memory_update, memory_get, and memory_consolidate. It stops short of explicitly naming a sibling it is not, but the action is unambiguous.
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?
There is no guidance on when to use this versus memory_update (to change content), memory_consolidate (to merge), or memory_list/memory_recall (to locate the correct ID first). No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.