Skip to main content
Glama
phillipclapham

anneal-memory

by phillipclapham
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

record

Capture decisions, tensions, and outcomes with reasoning as typed episodes so they can be compressed into a continuity file at session end.

Instructions

Record a typed episode to memory. Call this when important decisions are made, patterns are noticed, tensions are identified, questions arise, or outcomes are observed. Record the reasoning, not just the fact — 'Chose X because Y' is more valuable than 'using X'. Episodes accumulate during a session and serve as raw material for compression into the continuity file at session end.

Input Schema

NameRequiredDescriptionDefault
trustNoWhere the content came from. agent (default) = your own observation or decision; tool = a tool result you are relaying; external = a web page, document or another party. A pattern grounded only in tool/external episodes does not graduate past 1x until an agent episode also grounds it. Use tool/external whenever the content is someone else's claim.agent
sourceNoAgent or source attribution. Defaults to 'agent'.agent
contentYesThe episode content — what happened, what was observed, decided, or questioned.
metadataNoOptional JSON metadata to attach to the episode.
state_keyNoThe state slot this fact fills, e.g. 'user.home_city'. A newer episode with the same key replaces this one, and this one replaces older episodes with the key, with no word-overlap check: the shared key is your claim that the facts fill one slot. recall then hides the older episode and, for a keyword that matches it, names this one as its replacement. Case and spacing are ignored.
supersedesNoIds of older episodes this one replaces (a changed fact). Each must exist, not be newer, and share at least a quarter of the shorter text's meaningful words with this content; otherwise nothing is recorded. recall then hides the old episode by default.
derived_fromNoIds of the episodes this content was derived from, e.g. your summary of a page you recorded as external. Each must exist. For graduation it then counts at most as trusted as its most trusted source, so a summary cannot corroborate its own source.
episode_typeYesEpisode type. observation=pattern/insight, decision=committed choice, tension=conflict/tradeoff, question=open question, outcome=result of action, context=environmental/state info.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.0
    • addedInput schema / properties / derived_from
      Added value: +{
+  "description": "Ids of the episodes this content was derived from, e.g. your summary of a page you recorded as external. Each must exist. For graduation it then counts at most as trusted as its most trusted source, so a summary cannot corroborate its own source.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / state_key
      Added value: +{
+  "description": "The state slot this fact fills, e.g. 'user.home_city'. A newer episode with the same key replaces this one, and this one replaces older episodes with the key, with no word-overlap check: the shared key is your claim that the facts fill one slot. recall then hides the older episode and, for a keyword that matches it, names this one as its replacement. Case and spacing are ignored.",
+  "type": "string"
+}
    • addedInput schema / properties / trust
      Added value: +{
+  "default": "agent",
+  "description": "Where the content came from. agent (default) = your own observation or decision; tool = a tool result you are relaying; external = a web page, document or another party. A pattern grounded only in tool/external episodes does not graduate past 1x until an agent episode also grounds it. Use tool/external whenever the content is someone else's claim.",
+  "enum": [
+    "agent",
+    "tool",
+    "external"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv0.9.23
    • addedInput schema / properties / supersedes
      Added value: +{
+  "description": "Ids of older episodes this one replaces (a changed fact). Each must exist, not be newer, and share at least a quarter of the shorter text's meaningful words with this content; otherwise nothing is recorded. recall then hides the old episode by default.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  3. First observedv0.1.4

TDQS

A3.9/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does add non-schema lifecycle context (episodes accumulate within a session and feed compression into the continuity file at session end), but it omits what happens on write validation failures, what the call returns, and any persistence/permission caveats — significant gaps for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded: purpose, then trigger list, then content-quality rule, then lifecycle payoff. Every sentence either routes the agent or improves the quality of the payload; nothing is redundant with the schema.

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 8-parameter tool with nested objects and no output schema, the description covers purpose, triggers, content guidance and the accumulation lifecycle well, while the complex supersede/trust mechanics live in a thorough schema. It is only slightly short of complete because it says nothing about what the call returns or how rejected writes (invalid supersedes ids) are surfaced.

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 the 3 baseline applies and the rich per-parameter docs already handle state_key, supersedes, derived_from and trust. The description adds real guidance beyond the schema by shaping the content parameter ("Record the reasoning, not just the fact — 'Chose X because Y' is more valuable than 'using X'"), which changes how an agent fills the most important field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Record") and resource ("a typed episode to memory"), and the second/third sentences expose the salience model that separates it from siblings like recall and save_continuity. It does not explicitly name an alternative the way a 5 would, leaving the agent to infer that recall is the read counterpart.

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?

The trigger list ("when important decisions are made, patterns are noticed, tensions are identified, questions arise, or outcomes are observed") maps directly onto the episode_type enum, giving clear when-to-use context. No when-not conditions or named alternatives are given, so it stops short of a 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