Skip to main content
Glama

forget_memory

DestructiveIdempotent

Permanently erase one memory by ID or bulk criteria, purging history snapshots and orphaned compliance rows; preview first with dry_run because execution is irreversible.

Instructions

Permanently erase (GDPR-style) one memory by id or a bulk set matched by criteria (namespace/namespace_prefix/source_agent_id/tag/memory_type/before_days). Unlike delete_memory, this also purges memory_history snapshots and any orphaned compliance rows, leaving only a content-hash audit entry in the forgotten-log — irreversible. dry_run defaults to true: call once to preview, then again with dry_run=false to execute. Priority::Must memories are excluded unless allow_must=true. Gated by the same per-agent API-key auth as delete_memory — there is no separate admin tier at the MCP layer.

Input Schema

NameRequiredDescriptionDefault
tagNoBulk: memories carrying this tag
reasonNoAudit-trail reason recorded in the forgotten-log
api_keyNoAPI key for agent authentication (required if agent has a registered key)
dry_runNoPreview matches without purging anything (default: true — forgetting is irreversible, so a caller must explicitly set this to false to execute)
agent_idNoID of the requesting agentunknown
memory_idNoID of a single memory to permanently erase. Mutually exclusive with the criteria fields below — when set, every criteria field is ignored.
namespaceNoBulk: exact namespace match
allow_mustNoExplicit override to include Priority::Must memories (otherwise excluded by default)
before_daysNoBulk: not updated in this many days
memory_typeNoBulk: memory type (preference, fact, episode, entity, skill)
source_agent_idNoBulk: source agent id
namespace_prefixNoBulk: namespace starts with this (e.g. "archived:")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond annotations: discloses that history snapshots and orphaned compliance rows are purged, that only a content-hash audit entry remains, that the operation is irreversible, that Must-priority memories are excluded unless allow_must=true, and that auth is per-agent API key with no admin tier at the MCP layer.

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?

Dense but front-loaded: scope, sibling contrast, destructive effects, workflow, and auth in a tight block. Slightly long with some redundancy against schema descriptions (dry_run default, allow_must) but every sentence carries operational weight.

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?

Covers the critical concerns for a destructive, 12-param, irreversible tool with no output schema: what gets destroyed, irreversibility, preview workflow, exclusion of Must memories, and auth. Return-value shape is not explained, but for a preview/execute purge tool the key facts are present.

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?

Schema coverage is 100% so the baseline is 3; the description adds value by grouping bulk criteria (namespace/namespace_prefix/source_agent_id/tag/memory_type/before_days), flagging memory_id as mutually exclusive with the criteria, and explaining the dry_run default and allow_must override. Marginal gain over schema because these details are largely restated.

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?

States a specific verb (permanently erase / purge), the resource (one memory by id or a bulk set), and explicitly contrasts with the sibling delete_memory. An agent can distinguish it from delete_memory without opening either schema.

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?

Gives explicit selection criteria (single id vs bulk criteria fields), names the alternative (delete_memory) and how this differs, and prescribes a two-step workflow (preview with dry_run, then execute). No inference required.

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