Skip to main content
Glama

remember

Save important user preferences, decisions, and project details locally so future sessions can retrieve them by meaning instead of keywords.

Instructions

Save something worth remembering for future sessions. Use this when you learn something important about the user — their preferences, decisions, client details, project context, or anything they would not want to repeat. Your future self will find it by meaning, not keywords. Signal more than you think you should — storage is free, forgetting is expensive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gistYesA one-line summary for finding this later. Format: 'category: key insight'. Example: 'client: Maria — Q2 retention focus, $40K budget'
threadNoOptional. Short UUID of a previous memory to thread this to. Builds chains — prospect to client, draft to final, problem to solution.
contentYesThe full detail. Write for a future you that knows nothing about this session. Include names, numbers, decisions, reasoning, context.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.1

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses that retrieval is by meaning rather than keywords and that storage is cheap, but says nothing about deduplication, whether repeated saves create duplicate memories, persistence lifetime, or any permissions constraints — meaningful gaps for an unannotated write tool.

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?

Four short sentences, front-loaded with the action and trigger, with no redundancy. The closing aphorism ('storage is free, forgetting is expensive') is motivational rather than instructional, which costs it the top score.

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?

With no output schema and no annotations, the description covers what to store and why, which is most of what an agent needs for a 3-param write tool. It stops short of explaining duplicate handling or persistence guarantees, leaving some behavioral questions open.

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 the schema already documents content, gist, and thread in depth. The description's 'found by meaning, not keywords' reinforces why gist matters but adds no syntax or format detail beyond the schema's own example, so baseline 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 (save) and resource (something worth remembering) scoped to future sessions, which cleanly separates it from the retrieval siblings recall and recall_recent. An agent can tell this is the write-side counterpart without opening 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions — 'when you learn something important about the user' with concrete categories (preferences, decisions, client details, project context) and a threshold ('anything they would not want to repeat'). It lacks an explicit when-not clause (e.g., don't store trivia or transient state), so it falls short of 5.

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