Skip to main content
Glama

remember

Persist decisions, caveats, and learnings across sessions and AI tools so context survives handoffs, and optionally turn a memory into an enforced guard rule that blocks contradicting edits.

Instructions

Persist knowledge across sessions and AI tools (Claude, GPT, Cursor, Codex, Gemini). The only cross-agent memory that survives session boundaries.

WHEN TO CALL: • The moment an error or failure occurs → layer: "caveat" (auto-protected, never forgotten) • When a decision is made or approved → content + anchor: {} (remembered AND enforced in one call) • When a goal is set or updated → layer: "goal" • When something new is learned → layer: "learning" • When the user says "remember this" / "覚えておいて" • After completing a task or receiving user approval

MODES: • Create (default): content is the only required field. entity defaults to the project you are in; layer defaults to "context" (or "learning" when anchor is set). • Create + enforce: add anchor: {} — the memory also becomes a decision the guard re-injects before Edit/Write/Bash and on session start. Give anchor.violation_signal (forbidden strings) to make contradictions detectable; anchor.affects (path globs) to scope it. • Update: memory_id (+ optional content, layer, importance) • Delete: memory_id + forget: true

Importance ≥ 0.9 pins the memory (protected from auto-forgetting). Supports Japanese (日本語) and English.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
forceNoBypass paste-back quality check.
layerNoOne of: goal / context / emotion / implementation / caveat / learning. Aliases accepted (why→goal, warnings→caveat, decisions→learning, how→implementation). Optional — defaults to "context", or "learning" when anchor is set.
anchorNoAlso declare this as an enforceable decision. Pass {} for defaults, or an object: { kind?: "decision"|"prohibition"|"constraint", violation_signal?: string[] (forbidden strings — needed for the gate to detect a contradiction), affects?: string[] (path globs that scope it), detect_terms?: string[], domain?: string, rationale?: string }. Without violation_signal the anchor is a constraint: re-injected on session start and when its scope is touched, but no contradiction can be detected.
forgetNoSet true + memory_id to delete a memory. Caveat-layer and pinned memories cannot be deleted.
contentNoThe memory content (plain text or structured JSON with altitude/type/state/what/why). The only required field for create.
memory_idNoSet to update an existing memory instead of creating. Only content/layer/importance are changed.
thread_idNoOptional thread ID to group related memories (decision chains, session groups).
entity_keyNoOptional canonical key (email, domain, file path)
importanceNo0.0-1.0. Set ≥0.9 to pin (protects from forgetting).
entity_kindNoOptional — defaults to "project".
entity_nameNoWhat this memory is about. Optional — defaults to the project you are working in (from workspace roots, else the files edited recently).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.17.0
    • addedInput schema / properties / anchor
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "properties": {
      +        "affects": {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        },
      +        "detect_terms": {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        },
      +        "domain": {
      +          "type": "string"
      +        },
      +        "kind": {
      +          "enum": [
      +            "decision",
      +            "prohibition",
      +            "constraint"
      +          ],
      +          "type": "string"
      +        },
      +        "rationale": {
      +          "type": "string"
      +        },
      +        "violation_signal": {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        }
      +      },
      +      "type": "object"
      +    }
      +  ],
      +  "description": "Also declare this as an enforceable decision. Pass {} for defaults, or an object: { kind?: \"decision\"|\"prohibition\"|\"constraint\", violation_signal?: string[] (forbidden strings — needed for the gate to detect a contradiction), affects?: string[] (path globs that scope it), detect_terms?: string[], domain?: string, rationale?: string }. Without violation_signal the anchor is a constraint: re-injected on session start and when its scope is touched, but no contradiction can be detected."
      +}
    • changedInput schema / properties / content / description
      Previous value: -"The memory content (plain text or JSON)"New value: +"The memory content (plain text or structured JSON with altitude/type/state/what/why). The only required field for create."
    • addedInput schema / properties / entity_kind / description
      Added value: +"Optional — defaults to \"project\"."
    • changedInput schema / properties / entity_name / description
      Previous value: -"Name of the entity this memory is about"New value: +"What this memory is about. Optional — defaults to the project you are working in (from workspace roots, else the files edited recently)."
    • changedInput schema / properties / force / description
      Previous value: -"Bypass the paste-back/CI-log quality check. Only set when you are sure the content is original user or agent thought."New value: +"Bypass paste-back quality check."
    • addedInput schema / properties / forget
      Added value: +{
      +  "default": false,
      +  "description": "Set true + memory_id to delete a memory. Caveat-layer and pinned memories cannot be deleted.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / importance / description
      Previous value: -"0.0-1.0. Set to 0.9 or higher to \"pin\" a memory (protects from forgetting even outside caveat layer)."New value: +"0.0-1.0. Set ≥0.9 to pin (protects from forgetting)."
    • changedInput schema / properties / layer / description
      Previous value: -"One of: goal / context / emotion / implementation / caveat / learning. Common aliases (why, decisions, warnings, how, ...) are accepted."New value: +"One of: goal / context / emotion / implementation / caveat / learning. Aliases accepted (why→goal, warnings→caveat, decisions→learning, how→implementation). Optional — defaults to \"context\", or \"learning\" when anchor is set."
    • addedInput schema / properties / memory_id
      Added value: +{
      +  "description": "Set to update an existing memory instead of creating. Only content/layer/importance are changed.",
      +  "type": "number"
      +}
    • addedInput schema / properties / thread_id
      Added value: +{
      +  "description": "Optional thread ID to group related memories (decision chains, session groups).",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "entity_name",
      -  "entity_kind",
      -  "layer",
      -  "content"
      -]
  2. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/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: caveat-layer memories are auto-protected and never forgotten, anchored memories are re-injected before Edit/Write/Bash and at session start, importance ≥0.9 pins, and pinned/caveat memories cannot be deleted. These are non-obvious side effects an agent must know before calling.

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 cleanly sectioned into WHEN TO CALL and MODES so an agent can scan to the decision it needs. Slightly overlong in places — the 'only cross-agent memory' claim and the Japanese phrasing example add words without adding decision value.

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 an 11-parameter mutation tool with zero annotations and no output schema, the description covers triggers, modes, layer semantics, protection rules and enforcement behavior thoroughly. The one omission is the return value — an agent is never told that create yields a memory_id it needs for later update or delete.

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 already 100%, so the baseline is 3. The description adds combination-level meaning the schema cannot express: memory_id alone means update, memory_id + forget:true means delete, and anchor:{} upgrades a plain create into an enforced decision. It stops short of explaining entity_key, thread_id, or entity_name beyond what the schema already says.

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 (persist) and resource (knowledge/memories) with explicit scope: across sessions and AI tools. It also implicitly positions itself against the sibling 'recall' as the write-side counterpart of the pair, so an agent can choose without inspecting either 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?

The WHEN TO CALL block gives concrete triggering events (error occurs, decision made, goal set, user says 'remember this') and maps each to a specific layer. The MODES section then routes create vs update vs delete explicitly by parameter combination, leaving nothing to inference.

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