Skip to main content
Glama

remember

DestructiveIdempotent

Save decisions, conventions, and preferences to persistent memory; reusing a key updates the entry, while unsafe content is refused with a reason.

Instructions

Save knowledge to persistent memory. Use for decisions, conventions, preferences. UPSERT by key — calling with same key updates the existing entry. Content is screened on write and REFUSED with a named reason (never silently stripped or stored) if it contains invisible/bidi characters, an LLM role tag, an instruction to ignore previous/system instructions, a PEM private key, a prefixed API token (sk-/ghp_/xox*/AKIA), or a literal assignment to a *_PASSWORD/_SECRET/_TOKEN/_API_KEY name. LIMITATION — this screen is partial and must not be relied on as a secret filter: it CANNOT see a secret that has no recognisable prefix and no field name next to it (a bare value pasted on its own line), nor names it does not know. Do not paste credentials here on the assumption they will be caught; record where a secret lives, never its value.

Input Schema

NameRequiredDescriptionDefault
keyYesSlug key for UPSERT (e.g. 'api-convention', 'license-decision'). ENFORCED server-side as ^[a-z0-9][a-z0-9-]*[a-z0-9]$ — lowercase alphanumeric and hyphens only, at least two characters, no leading or trailing hyphen. Hyphens, NEVER colons: a colon-delimited key such as 'episode:alice:2026-09-07' is REFUSED with a validation error — it is not normalised or accepted with a warning.
tagsNoTags for categorization and filtering. A kind: tag also SETS importance_score, which is what decides whether recall returns this entry at its default threshold of 0.3 — so the tag you choose is a retrieval decision, not a label. Base score by kind: kind:pinned 1.0, kind:incident 0.85, kind:decision 0.80, kind:preference 0.80, kind:learning 0.70, kind:fact 0.60, no kind: tag 0.50, kind:session-checkpoint 0.30. kind:session-checkpoint is a DOWNGRADE that overrides every other kind: tag on the same entry — tagging it alongside kind:decision yields 0.30, not 0.80. Any kind: value not in that list (e.g. kind:canonical-decision) is unrecognised and scores 0.50. Two boosts of +0.10 each, capped at 1.0: content mentioning icp / architecture / license / security / money, and a relevance:<n> tag whose n is >= 0.8.
scopeNoworkspace | project | agent (default: project).
reasonNoWhy this memory is worth writing — what a future thread should be able to do with it, or what changed if you are correcting an existing key. Recorded on the revision alongside the content, so a later reader can judge whether the entry still applies instead of guessing from the text alone. Optional today and about to become required; write it now.
contentYesWhat to remember (markdown).
relevanceNoRelevance score 0-1 (default 1.0 when omitted). NOT the same field as importance_score: relevance is a caller-set ranking hint, importance_score is computed from tags (see tags) and is the field min_importance filters on. A relevance:<n> TAG with n >= 0.8 does feed importance_score by +0.10; this numeric parameter does not.
thread_idNoThread identifier for same-session memory grouping. Auto-populated from the runner state file when omitted.
expires_atNoRFC3339 timestamp or Go duration (e.g. '72h') when this memory should expire.
project_idNoProject ID (required for project scope).
source_urlNoOptional URL/path to the source of this knowledge (task ID, PR, file path).
attach_contextNoWhen false, disables auto-injection of thread_id and source_task_id. Use for cross-cutting records not tied to the active task.
source_task_idNoUUID of the Mesh task that produced this memory. Auto-populated from the runner state file (FIDDLER_STATE_FILE) or the active checkout. Enables Amendment 2/3 KG edge hooks.
expected_versionNoMake the write conditional: it succeeds only if the stored version still matches this number, and is REFUSED with both version numbers if someone else wrote to the key in between. Pass the version returned by your previous remember/recall of this key. Omit for last-write-wins.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that content is screened and REFUSED with a named reason (never silently stripped), enumerates the refusal triggers, and explicitly documents the screen's LIMITATION (no prefix, no field name = not caught). It also describes UPSERT-on-existing-key, the expected_version conditional-write path, and the session-checkpoint downgrade, none of which the annotations convey.

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 purpose, usage, and the write/refusal contract before the long screening enumeration and the limitation caveat. It is dense and long, but for a write tool with security and concurrency semantics most sentences carry unique, decision-relevant information; the screening list is verbose even so.

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 13 params fully covered by schema, annotations for the safety profile, and no output schema to explain, the description closes the remaining gaps: refusal behavior, screen limitations, idempotent UPSERT, and optimistic-locking via expected_version. An agent has everything needed to invoke it correctly and safely.

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 all 13 parameters, including the key regex and tag-scoring rules. The description reinforces the UPSERT-by-key contract but adds no syntax or format detail beyond what the schema fields already state, so the 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 (persistent memory), then pins down the exact write semantics: 'UPSERT by key — calling with same key updates the existing entry.' That UPSERT behavior cleanly separates it from sibling readers like recall/get_memory and from a pure-creator, so an agent can pick it without opening a 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 concrete when-to-use guidance ('Use for decisions, conventions, preferences') and an explicit prohibition ('Do not paste credentials here... record where a secret lives, never its value'). It does not route the agent to alternatives such as forget (for removal) or set_project_knowledge, so it stops short of full when/when-not/alternatives coverage.

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