mcp-ariel-memory

Overview Schema Source Related Servers Discussions Admin

forget

Destructive

Archive, preview, or restore specific memory entries by key, pattern, recency, or episode IDs, with a Shadow Bin for safe undo.

Instructions

Universal Primitive: context-aware forgetting with Shadow Bin support.

Scope: exact one L4 key; fuzzy a pattern across L4, L3 and the graph; recent everything newer than minutes; episode_ids exactly those episodes.episode_id values; undo puts the archived_ids back where they came from. Every scope reports what it touched, in entries / episodes / graph_nodes / not_found.

dry_run=True matches and writes nothing — the same computation as the real pass, so the preview cannot drift from it. Refused for recent, which has no shadow bin.

undo refuses a purged row, a row whose archived kind is unknown, another owner's id, and a row whose key is already back in the table — each with its reason rather than a bare zero; dry_run=True shows what would return and refuses the same rows. An id that two archived rows share is refused too, unless memory_type names the one you want. The archive is not a backup: restored_items names the fields a restored row could not bring back.

Input Schema

Name	Required	Default
`key`	No
`layer`	No	user
`scope`	No	exact
`dry_run`	No
`minutes`	No
`user_id`	No	default
`shadow_bin`	No
`episode_ids`	No
`memory_type`	No
`archived_ids`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.12.0Oct 13, 2026

addedInput schema / properties / archived_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Archived Ids"
+}

addedInput schema / properties / dry_run

Added value: +{
+  "default": false,
+  "title": "Dry Run",
+  "type": "boolean"
+}

addedInput schema / properties / episode_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Episode Ids"
+}

addedInput schema / properties / key / default
```
Added value: +""
```

addedInput schema / properties / memory_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Memory Type"
+}

changedInput schema / properties / scope / enum

Previous value: -[
-  "exact",
-  "fuzzy",
-  "recent"
-]New value: +[
+  "exact",
+  "fuzzy",
+  "recent",
+  "episode_ids",
+  "undo"
+]

removedInput schema / required
```
Removed value: -[
-  "key"
-]
```

Addedv1.8.0Aug 26, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the destructiveHint=true annotation, the description discloses substantial behavior: dry_run performs the identical computation so the preview cannot drift, refusals are returned with reasons rather than bare zeros (purged rows, unknown kinds, foreign owner ids, already-restored keys, ambiguous shared ids), and the archive is explicitly not a backup. This is rich, non-obvious operational context an agent could not infer from annotations alone.

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 scope list is front-loaded and the paragraphs are organized by concern (scopes, dry_run, undo refusals, archive caveat), with backticked identifiers aiding scanability. It is dense and slightly jargon-heavy ('Universal Primitive', 'L4 key', 'archived kind'), but each sentence carries substantive information rather than filler.

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

Completeness4/5

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

For a 10-parameter destructive mutation with no required args and no parameter descriptions, the description covers the risky paths thoroughly: scope selection, refusal semantics, dry-run preview, and the restore side effects recorded in restored_items. An output schema exists so return-value explanation is not needed. The remaining gap is the unexplained layer/user_id inputs.

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?

With 0% schema description coverage, the description must carry the load and does so for most parameters: scope (all five modes), dry_run, minutes, episode_ids, archived_ids, memory_type, and key are all given meaning. It leaves 'layer' (user/agent) and 'user_id' unexplained and does not directly define the shadow_bin boolean, so compensation is strong but not complete.

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

Purpose4/5

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

The description opens with a clear verb+resource ('context-aware forgetting with Shadow Bin support') and enumerates the five distinct scopes (exact, fuzzy, recent, episode_ids, undo), so an agent understands what the tool does. It stops short of naming or contrasting any sibling tool, leaving the boundary with evolve/dream/wake_up implicit.

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

Usage Guidelines4/5

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

Each scope is paired with its operating condition ('exact' one L4 key; 'fuzzy' a pattern; 'recent' everything newer than minutes; 'undo' restores archived_ids), which is effectively when-to-use guidance for selecting a mode, and it warns that 'recent' is refused for dry_run. It gives no explicit when-not or sibling alternative, so it is clear context rather than full routing.

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

Deploy Server