Skip to main content
Glama

forget

Permanently delete specified memories or text matches, with optional dry-run preview and full audit logging for erasure requests.

Instructions

TRULY DELETE memories — the one op that removes content (everything else is append-only: supersession only demotes). Use for an erasure / right-to-be-forgotten request, a poisoned or false memory, or a hard correction. Pass ids (memory ids to drop) and/or where_contains (delete every memory whose text contains this substring, case-insensitive). Verified forgetting: the records are deleted AND their ids are scrubbed from every survivor's links + supersession pointers + the caches, so a forgotten memory cannot resurface via recall or a later consolidation pass. dry_run=True PREVIEWS the match (returns {would_forget, ids, sample, dry_run:True} with a few matched texts) and deletes NOTHING — always dry-run a bulk where_contains first. Returns {forgotten, ids, scrubbed_links}.

basis (the decision reason), request_id (the DSAR/ticket this belongs to), authorized_by (the authorising principal's public key) and authorization (their signature) are recorded with the erasure as the Art.30 account of WHY and on WHOSE authority. None of them was on this surface, so an erasure performed over MCP left a record that it happened and nothing about who ordered it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNo
basisNo
dry_runNo
request_idNo
authorizationNo
authorized_byNo
where_containsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.20.1
    • addedInput schema / properties / authorization
      Added value: +{
      +  "default": "",
      +  "title": "Authorization",
      +  "type": "string"
      +}
    • addedInput schema / properties / authorized_by
      Added value: +{
      +  "default": "",
      +  "title": "Authorized By",
      +  "type": "string"
      +}
    • addedInput schema / properties / basis
      Added value: +{
      +  "default": "",
      +  "title": "Basis",
      +  "type": "string"
      +}
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "default": false,
      +  "title": "Dry Run",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / request_id
      Added value: +{
      +  "default": "",
      +  "title": "Request Id",
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and handles it excellently. It discloses that records are truly deleted, ids are scrubbed from links, supersession pointers, and caches, and that forgotten memories cannot resurface. It also transparently explains dry_run behavior and the audit-record gap when authorization fields are absent.

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 front-loaded with the core destructive purpose and packs in substantial safety and audit context. It is long, but the length is largely justified for a destructive 7-parameter tool with no annotations or output schema. Minor redundancy, such as repeated emphasis on deletion and dry-run caution, keeps it from being perfectly concise.

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?

The description covers use cases, deletion and scrubbing semantics, dry-run returns, the actual return shape, and the audit/authorization context, all without relying on an output schema or annotations. An agent has enough detail to invoke the tool safely and understand the consequences. The only notable gap is explicit differentiation from forget_subject, already reflected in the usage and purpose scores.

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

Parameters5/5

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

Schema description coverage is 0%, but the description defines all seven parameters: ids, where_contains, dry_run, basis, request_id, authorized_by, and authorization. It adds meaningful semantics like case-insensitive substring matching, preview behavior, and the role of each audit/authorization field, fully compensating for the empty schema descriptions.

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 clearly identifies the verb and resource: delete memories by ids or matching substring, and it contrasts deletion with append-only/supersession behavior. However, it overclaims 'the one op that removes content' while a sibling tool named forget_subject exists, and it never explains how forget relates to that sibling or to forget_pii.

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?

The description gives explicit use cases: erasure/right-to-be-forgotten requests, poisoned or false memories, and hard corrections. It also provides critical operational guidance to dry-run bulk where_contains deletes first. It does not explicitly name alternatives like forget_subject or state when to choose them instead, so the when-not guidance is incomplete for an agent choosing among the forget-family tools.

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