Skip to main content
Glama

remember

Store one atomic memory claim that an AI agent can recall later. Include enough context for the claim to stand alone.

Instructions

Write one durable memory the agent should be able to recall later. Mutating: persists a memory (set dry_run to validate without writing). Store exactly one atomic, self-contained fact, decision, preference, or lesson per call — include enough context that it stands alone ("the user deploys from the release branch, never main", not just "release branch"). Do not store secrets or raw transcripts. For a plausible-but-unverified inference, use candidate_submit instead so a human approves it first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoMemory kind (fact, decision, preference, lesson, action, ...). Inferred from the content prefix when omitted.
modeNoHow to resolve against existing memories sharing the same entity/claim key. Default auto.
siloNoRetention tier (e.g. short-term, durable). Omit to use the space default.
tagsNoFree-form tags for filtering and retrieval boosts.
scopeNoVisibility scope: global, workspace, project, session, or custom.
spaceNoMemory space (namespace) to write into. Omit for the default space.
pinnedNoIf true, exempt from automatic eviction. Default false.
contentYesThe memory text: one atomic, self-contained claim with enough context to stand on its own. Required.
dry_runNoIf true, validate and return what would be written without persisting. Default false.
projectNoFree-form project key this memory belongs to.
summaryNoOptional shorter summary of the content.
valid_toNoRFC 3339 timestamp the fact stops being true (past values are excluded from recall).
claim_keyNoStable key identifying the claim, used to group versions for supersession.
confidenceNoConfidence in the memory, 0.0–1.0. Default 1.0.
entity_keyNoStable key of the entity this memory is about (groups related memories in the graph).
expires_atNoRFC 3339 timestamp after which the memory is dropped from recall.
supersedesNoMemory ids this memory replaces (they become superseded).
valid_fromNoRFC 3339 timestamp the fact starts being true.
contradictsNoMemory ids this memory conflicts with.
derive_keysNoAuto-derive entity_key/claim_key from the content when not provided. Default true.
observed_atNoRFC 3339 timestamp of when this was observed. Defaults to now.
sensitivityNoMark sensitive to flag the memory for stricter handling. Default normal.
source_typeNoProvenance: assistant-inference (default) when the agent inferred it, or explicit-user when the user stated it directly.
verified_againstNoWhat this memory was checked against, if any.
Behavior4/5

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

No annotations exist, so the description carries full burden. It states persistence, dry_run behavior, and atomicity requirements. However, it does not mention error conditions, success/failure responses, or side effects like eviction.

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 a single paragraph, front-loaded with the core purpose and behavioral instructions. Compact but clear, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 24 parameters and no output schema, the description covers the primary use case and provides enough context for the agent to use it correctly. Lacks detailed return value information but that is mitigated by the schema and dry_run mention.

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 baseline is 3. The description elaborates on the content parameter's format and the dry_run parameter's purpose, but does not detail other parameters beyond what the schema provides.

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 description clearly states the tool's verb ('Write'), resource ('durable memory'), and the single action per call. It also distinguishes from the sibling tool 'candidate_submit' by noting when to use that instead.

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 provides when to use (atomic facts), what not to store (secrets, raw transcripts), and an alternative tool for unverified inferences. Also mentions dry_run for validation without persisting.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/teflon07/memkeeper'

If you have feedback or need assistance with the MCP directory API, please join our Discord server