XMemo

Forget XMemo memory or TODO

forget

Destructive

Delete one memory, TODO, or Ledger transaction by natural target ('latest', 'current', an exact memory ID (with memory_id accepted as an equivalent exact-reference alias), an exact TODO ID from the current TODO listing, or an exact Ledger transaction ID from ledger(action='list')). Defaults to a recoverable soft delete (restore later with restore_memory); pass mode='hard' only after the user has explicitly confirmed a permanent, unrecoverable deletion in this conversation. Call this only when the user explicitly asks to delete a specific memory, TODO, or expense/income record; list/search or check activity first if the target is ambiguous.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Deletion mode: soft or soft_delete is the recoverable default; hard or hard_delete is permanent and unrecoverable and may be used only after explicit user confirmation.	soft
`reason`	No	Optional user-facing reason for the deletion.
`target`	No	The memory to forget: current or an exact memory ID shown by search.	current
`memory_id`	No	Exact XMemo memory reference shown by search or recall.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed8 schema fields changedJul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / memory_id

Added value: +{
+  "default": "",
+  "description": "Exact XMemo memory reference shown by search or recall.",
+  "title": "Memory Id",
+  "type": "string"
+}

removedInput schema / properties / metadata_json

Removed value: -{
-  "default": "{}",
-  "description": "Optional JSON object string with extra metadata for the operation.",
-  "title": "Metadata Json",
-  "type": "string"
-}

changedInput schema / properties / mode / default
```
Previous value: -"hard"New value: +"soft"
```

changedInput schema / properties / mode / description

Previous value: -"Deletion mode for forget_memory, such as soft_delete, hard_delete, or redact when supported."New value: +"Deletion mode: soft or soft_delete is the recoverable default; hard or hard_delete is permanent and unrecoverable and may be used only after explicit user confirmation."

addedInput schema / properties / mode / enum

Added value: +[
+  "soft",
+  "soft_delete",
+  "hard",
+  "hard_delete"
+]

removedInput schema / properties / query_hint

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Input value for the Forget tool.",
-  "title": "Query Hint"
-}

removedInput schema / properties / replacement_content

Removed value: -{
-  "default": "",
-  "description": "Replacement text to store when redacting or replacing deleted memory content.",
-  "title": "Replacement Content",
-  "type": "string"
-}

Changed1 schema field changedJul 16, 2026
- changedInput schema / properties / mode / default
```
Previous value: -"soft"New value: +"hard"
```

Changed4 schema fields changedJul 7, 2026

addedInput schema / properties / metadata_json

Added value: +{
+  "default": "{}",
+  "description": "Optional JSON object string with extra metadata for the operation.",
+  "title": "Metadata Json",
+  "type": "string"
+}

addedInput schema / properties / mode

Added value: +{
+  "default": "soft",
+  "description": "Deletion mode for forget_memory, such as soft_delete, hard_delete, or redact when supported.",
+  "title": "Mode",
+  "type": "string"
+}

addedInput schema / properties / query_hint

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Input value for the Forget tool.",
+  "title": "Query Hint"
+}

addedInput schema / properties / replacement_content

Added value: +{
+  "default": "",
+  "description": "Replacement text to store when redacting or replacing deleted memory content.",
+  "title": "Replacement Content",
+  "type": "string"
+}

First observedJun 9, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses important behavioral details: it defaults to a recoverable soft delete, mentions restore_memory as a recovery path, and warns that hard delete is permanent and unrecoverable, requiring explicit user confirmation. This adds significant value and aligns with the destructiveHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph, dense but not bloated. Every sentence contributes value: the action, the target types, the default behavior, the hard-delete caution, and the usage rule. It could be slightly more scannable with a list, but it remains efficient for the complexity involved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's destructive nature and multiple targets/modes, the description covers all essential aspects: what it deletes, how targets are specified, the soft/hard mode distinction, recovery via restore_memory, and the prerequisite of explicit user confirmation for permanent deletion. Combined with the detailed schema and annotations, it is complete for an AI agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% description coverage for all 4 parameters. The description adds context by explaining valid target formats (exact memory ID, TODO ID from current listing, Ledger transaction ID) and clarifying the mode aliases (soft/soft_delete, hard/hard_delete). It enriches rather than merely repeats the schema, though the schema already does a good job.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Delete one memory, TODO, or Ledger transaction by natural target'. It specifies the verb (delete) and the resources (memory, TODO, Ledger transaction), and distinguishes itself from sibling tools like restore_memory and update_memory by focusing on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Call this only when the user explicitly asks to delete a specific memory, TODO, or expense/income record'. It also provides guidance for ambiguous targets ('list/search or check activity first') and warns against using hard delete without explicit confirmation. This is clear and actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All XMemo tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

Multiple memory-retrieval tools (recall, search_memory, recall_context, read_memory, memory_overview) have overlapping purposes; detailed descriptions help but an agent could easily pick the wrong one. Similarly, ledger/open_ledger and todo/open_todo_board split text vs UI interaction, and forget overlaps with todo delete_all and ledger deletion.

Naming Consistency3/5

Most tools follow a verb_noun snake_case pattern (read_memory, update_memory, search_memory, open_ledger). However, several tools use bare nouns or verbs (forget, ledger, project, todo, recall, remember) and memory_overview is noun_noun, creating inconsistent conventions.

Tool Count3/5

19 tools is on the heavy side for the apparent scope, and the surface includes several pairs that duplicate the same domain in text vs UI form (ledger/open_ledger, todo/open_todo_board). Still, the count is defensible given the combined memory, project, TODO, and ledger coverage.

Completeness4/5

Memory has full lifecycle coverage (remember, read, search/recall, update, forget, restore), and TODO and Ledger workflows are largely complete. Minor gaps exist—no explicit project deletion and no pure text list-projects tool—but core workflows do not dead-end.

Forget XMemo memory or TODO

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources