lflabs-memory

Overview Schema Source Related Servers Discussions Admin

forget

Remove an incorrect or obsolete memory: it is hidden immediately and permanently deleted after 24 hours unless restored beforehand.

Instructions

Forget a memory that is wrong, obsolete (replaced by something newer) or that the user asked you to forget: it is hidden at once and deleted for good after 24 hours, unless the user restores it before then. A plan or event that has passed is history, not obsolete. When asked to forget something, recall it first and forget every memory that mentions it, not just the one you were shown. When only one detail of a memory should go, or a memory mentions the forgotten thing only in passing, remember a corrected version without it, then forget the old one. Never save a note that something was forgotten, dropped or cancelled. An id starting with c (c12) is a one-fact claim: pass it as shown, "c12".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "forget"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.7Nov 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses that the memory is hidden immediately and permanently deleted after 24 hours unless restored, which communicates destructiveness, reversibility, and timing. It also mandates recalling first and forgetting every matching memory, though it omits any permission or failure behavior.

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 purpose and lifecycle, then the procedural guidance. It is dense but every sentence contributes a constraint or edge case; only the anti-pattern note about never saving a forgetting note feels slightly tangential.

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?

An output schema exists, so return values need no explanation. Given a single-parameter destructive tool with zero annotations, the description covers lifecycle, prerequisites, branching procedures, and id format — nothing an agent needs to call it correctly is missing.

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 0% and the id field is an undescribed integer-or-string union, so the description must compensate. It does, by explaining that an id beginning with c (e.g. "c12") is a one-fact claim that must be passed as shown in string form, which clarifies the otherwise puzzling anyOf typing.

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 ('Forget a memory') and immediately bounds the scope to memories that are wrong, obsolete, or user-requested. The distinction that a passed plan or event is 'history, not obsolete' sharpens the boundary against siblings like recall and remember.

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?

Explicit when-to-use triggers are given (wrong, obsolete, user asked), plus an explicit when-not case (a passed plan or event is history, not obsolete). It also prescribes an alternative workflow for the partial case: remember a corrected version first, then forget the old one.

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

Deploy Server