Skip to main content
Glama
Filipe-Soares-de-Almeida

MemAI

by Filipe-Soares-de-Almeida
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

forget

Idempotent

Archive a memory to soft-delete wrong, stale, or duplicate entries; it is reversible and still readable in archived lists.

Instructions

Archive a memory (soft delete -- content is kept, just excluded from default search/list).

The call for a memory that is wrong, stale or a copy. It is reversible: the dashboard's restore brings an archived memory back, and list_by_domain(status='archived') still reads it. purge_memory() is the irreversible delete, only on the user's explicit request; to correct a memory instead of retiring it, edit_memory(). Archiving an open task cancels it; its items keep their states.

Returns {"ok": True}, or {"ok": False} for an unknown uid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesthe memory.
reasonNowhy it is archived, recorded as a status-change audit entry without touching the content.
superseded_byNothe uid of the memory that replaces this one, kept on the archived record. To mark a memory that stays active as replaced, draw link_memories(new, old, 'supersedes') instead: search then flags the old one `succeeded_by`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.16.1
    • addedInput schema / properties / reason / description
      Added value: +"why it is archived, recorded as a status-change audit entry without touching the content."
    • removedInput schema / properties / reason / title
      Removed value: -"Reason"
    • addedInput schema / properties / superseded_by / description
      Added value: +"the uid of the memory that replaces this one, kept on the archived record. To mark a memory that stays active as replaced, draw link_memories(new, old, 'supersedes') instead: search then flags the old one `succeeded_by`."
    • removedInput schema / properties / superseded_by / title
      Removed value: -"Superseded By"
    • addedInput schema / properties / uid / description
      Added value: +"the memory."
    • removedInput schema / properties / uid / title
      Removed value: -"Uid"
    • removedInput schema / title
      Removed value: -"forgetArguments"
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare a non-destructive, idempotent write; the description goes well beyond that by explaining reversibility (dashboard restore, list_by_domain visibility), the side effect that archiving an open task cancels it while items keep states, and the exact return shapes {ok: True} / {ok: False} for an unknown uid. No contradiction with destructiveHint=false or idempotentHint=true.

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?

Front-loaded with the core definition in the first sentence, then routing and side-effect details. Information-dense with minimal waste, though the parenthetical-heavy, multi-clause third sentence is slightly heavier than needed.

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?

No output schema exists, yet the description supplies the return contract and error case, the reversibility model, and the task-cancellation side effect. Nothing an agent needs to call this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so uid, reason and superseded_by (including the detailed superseded_by vs link_memories guidance) are already documented in the schema. The description adds no parameter-level syntax or format detail beyond that, so the baseline of 3 is appropriate.

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+resource ('Archive a memory') and immediately defines the semantics ('soft delete -- content is kept, just excluded from default search/list'), which cleanly separates it from purge_memory and edit_memory. An agent can distinguish it from every sibling without opening a 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?

Explicitly names the trigger ('a memory that is wrong, stale or a copy') and routes to alternatives: purge_memory for irreversible deletion only on explicit user request, edit_memory to correct rather than retire. It even names the read path for archived items, list_by_domain(status='archived').

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