Skip to main content
Glama

forget

DestructiveIdempotent

Permanently deletes a stored memory by ID, including its vectors, media, trigger history, and queued recollections. Use when a memory is wrong or the user asks to remove it; cannot be undone.

Instructions

Permanently delete one memory by id (as returned by remember, recall, sense or pending_recollections), together with its vectors, stored media, trigger history and any queued recollection of it. Use it when the user asks to forget something or a memory is wrong. Cannot be undone. Returns {"deleted": true} if the memory existed, {"deleted": false} otherwise.

Input Schema

NameRequiredDescriptionDefault
memory_idYesThe memory's id (e.g. 'mem_0189a3f2c1d4_9f3c2a7b1e').

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?

Annotations declare destructiveHint and idempotentHint, but the description goes well beyond them: it enumerates what is destroyed alongside the record (vectors, stored media, trigger history, queued recollections), states 'Cannot be undone,' and documents the return payload since no output schema exists.

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

Conciseness5/5

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

Three tight sentences: action and scope first, then trigger conditions, then irreversibility and return values. No padding or restatement of the schema.

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?

For a one-parameter destructive tool with no output schema, everything an agent needs is present: what is deleted, what cascades, that it is irreversible, when to invoke it, and what the response looks like.

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 would be 3, but the description adds meaningful provenance by naming the four sibling tools whose outputs yield a valid memory_id. That tells the agent where the value must come from rather than just its format.

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 and resource — 'Permanently delete one memory by id' — and scopes it to a single memory, which clearly separates it from the sibling read tools (remember, recall, sense, pending_recollections). An agent can identify exactly what this does without opening the schema.

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?

Gives explicit triggering conditions: 'when the user asks to forget something or a memory is wrong.' It does not spell out when NOT to use it (e.g. to correct rather than remove, or how to find the id if unknown beyond the source list), but the usage context is clear.

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

Deploy Server

Other Tools