Skip to main content
Glama

memory_remember

Stores one fact in an existing memory space as subject, attribute, and value, with valid dates and source document IDs, so agents can recall what was learned and who can see it.

Instructions

Store one fact in a memory space: a subject ("Halcyon"), an attribute ("database") and a value ("PostgreSQL 15"), with the date it became true and the documents you learned it from. Name a space that exists: memory_spaces lists yours, and memory_space_create makes one if none fits. No space is made for you. Save to a personal space if it is about the user, their preferences or their own work; to a team space if it would be true and useful for others. If unsure, ask. Cite the document IDs that search_knowledge or get_document gave you: a fact citing sources is shown only to people who can read all of them. The answer says who can see what you saved. When a value you stored before has changed, call memory_correct instead.

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": {
      "subject": "<subject>",
      "attribute": "<attribute>",
      "value": "<value>"
    },
    "name": "memory_remember"
  }
}

Input Schema

NameRequiredDescriptionDefault
spaceNoSpace ID or name to save to (required). memory_spaces lists yours; make one with memory_space_create
valueYesThe value
reasonNoWhy or how it was learned, e.g. the ticket that made the change
sourcesNoSources: document IDs, or link node IDs as "node:<id>"
subjectYesWhat the fact is about, e.g. a project, person or service
validToNoDate it stopped being true, if it already has
attributeYesWhich property of the subject, e.g. "database" or "tech lead"
validFromNoDate it became true (YYYY-MM-DD or ISO 8601). Omit if unknown.
containerIdNoOlder name for the space to save to; use `space` instead. A fact citing no sources saved this way goes to your own `<space>-personal` space

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare destructiveHint=false, so most of the burden falls on the description, and it delivers: it discloses the access-control consequence of citing sources (a cited fact is visible only to people who can read every source), that no space is created implicitly, and that the response reports visibility. That is real behavioral context an agent could not infer from structured fields.

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 core definition is front-loaded in sentence one, and the remaining sentences are all load-bearing (space routing, source citation, visibility, the memory_correct redirect). It is dense but a few clauses, such as the aside about asking when unsure, could be tightened.

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?

With nine parameters, no output schema, and only a single weak annotation, the definition still covers the decision points an agent needs: where to save, how to cite, what happens on changed facts, and what the response reveals. Nothing essential for a correct call 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 100%, so baseline is 3, but the description adds practical meaning: `sources` should be document IDs obtained from search_knowledge or get_document, `space` must be an existing space chosen by personal-vs-team criteria, and validFrom is the date a fact became true. It does not cover `reason`, validTo or the legacy containerId.

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?

The first sentence names a specific verb (store) and resource (one fact in a memory space) and enumerates the triple-plus-metadata it takes, with concrete examples ("Halcyon", "database", "PostgreSQL 15"). The final sentence explicitly distinguishes it from the sibling memory_correct, which handles changed values.

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?

It states prerequisites (the space must already exist; memory_spaces lists yours, memory_space_create makes one, none is auto-created), the routing rule between personal and team spaces, what to do when unsure (ask), and the exact alternative to use when a prior value changed (memory_correct).

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