Skip to main content
Glama

remember

Stores one durable fact in persistent memory for later sessions, including decisions, pitfalls, measurements, or interfaces, then returns related entries to review and supersede.

Instructions

Stores one fact permanently in memory.

Use it for knowledge a later session needs: a decision with its reason, a pitfall, a measured number, an interface. Not for secrets, guesses or short-lived details. Search with recall first; if an entry covers the fact, supersede that one.

Returns the new id, existing entries that resemble it (candidates to supersede) and a note when the tag is new - often a misspelling.

Args: text: The fact. A text that belongs to two kinds is two entries. tags: The project, i.e. WHERE the knowledge belongs (spaces or commas between several). kind: WHICH KIND of knowledge: interface (signature, file name, command, data format), pitfall (the obvious approach is wrong because ...), decision (with rationale), measurement (a number plus its criterion), workflow (how to work with this user), history (chronicle, hidden from recall's default view). Empty = unsorted. supersedes: Ids this entry replaces, e.g. "12,34". Hidden, not deleted.

Input Schema

NameRequiredDescriptionDefault
kindNo
tagsNo
textYes
supersedesNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • removedInput schema / properties / art
      Removed value: -{
      -  "default": "",
      -  "type": "string"
      -}
    • removedInput schema / properties / ersetzt
      Removed value: -{
      -  "default": "",
      -  "type": "string"
      -}
    • addedInput schema / properties / kind
      Added value: +{
      +  "default": "",
      +  "enum": [
      +    "interface",
      +    "pitfall",
      +    "decision",
      +    "measurement",
      +    "workflow",
      +    "history"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / supersedes
      Added value: +{
      +  "default": "",
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses that storage is permanent, that superseded entries are 'Hidden, not deleted' rather than destroyed, and what the call returns (new id, resembling candidates, new-tag warning). It omits error behavior and how entries are ultimately removed, which keeps it from a 5.

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, then usage, return values, and args in a predictable order. The kind enumeration is dense but every clause is informative; only the parenthetical asides and line-wrapped kind definitions push slightly past necessary length.

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, yet the description still names the three return elements the agent must act on (new id, supersede candidates, new-tag warning). Combined with full parameter coverage and retention semantics, nothing an agent needs to invoke this correctly is missing.

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 coverage is 0%, so the description must compensate and does: it defines text (with the 'belongs to two kinds is two entries' rule), tags (project/WHERE, space or comma separated), kind (every enum value explained with concrete examples, plus what empty means), and supersedes (format '12,34'). This adds substantial meaning beyond the bare enum list.

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 with scope qualifiers: 'Stores one fact permanently in memory.' The 'one fact' constraint and 'permanently' distinguish it from siblings like forget, consolidate and recall without needing to open any 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 when-to-use ('knowledge a later session needs: a decision with its reason, a pitfall, a measured number, an interface'), explicit when-not ('Not for secrets, guesses or short-lived details'), and an alternative workflow ('Search with recall first; if an entry covers the fact, supersede that one').

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