Skip to main content
Glama
Sign In
ZenBrain

ZenBrain

Official
by zensation-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Store a memory

zenbrain_store

Save a memory to long-term storage so it survives the conversation. Content is routed automatically to a procedure, episode, core memory, or fact, and the stored memory id is returned.

Instructions

Write something into long-term memory so it survives this conversation. Routing is automatic by default, first match wins: steps, or wording such as "How to", "Steps:" or "workflow:", make a procedure; an emotional weight above 0.5 (detected, or set via emotionalWeight) an episode; a confidence above 0.9 a pinned core memory; anything else a semantic fact. Set type only when you want to override that. Every call adds a new memory, except that storing the same core memory again updates it; the content is also kept in working memory (the most recent seven) while the server runs, so once seven are held each store replaces the oldest copy there. Long-term memory is never changed by a store. Returns the id of the stored memory. If it may already be stored, check with zenbrain_recall first: storing it again adds a duplicate.

Input Schema

NameRequiredDescriptionDefault
typeNoRouting hint. 'auto' (default) decides from the content.
stepsNoOrdered steps of a procedure. Optional: without them the steps are taken from the content (numbered or bulleted lines, otherwise every line).
toolsNoTools a procedure uses.
sourceNoWhere this came from, e.g. 'user', 'ai', 'import'. Kept with facts and episodes.
contentYesThe memory to store, in plain language.
contextNoContext domain, e.g. 'work', 'personal', 'learning'. Kept with episodes only.
outcomeNoWhat the procedure achieves.
confidenceNoHow certain this is (0–1), kept with facts. Above 0.9 routes to core memory unless an earlier routing rule matched.
emotionalWeightNoEmotional significance (0–1). Detected from the content when omitted. Above 0.5 routes to episodic memory unless steps or procedural wording matched first. With type 'fact' it is not stored, but lengthens the fact's first review interval (×(1 + weight)).

Output Schema

NameRequiredDescriptionDefault
idYesIdentifier of the stored memory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / emotionalWeight / description
      Previous value: -"Emotional significance (0–1). Detected from the content when omitted. Above 0.5 routes to episodic memory unless steps or procedural wording matched first."New value: +"Emotional significance (0–1). Detected from the content when omitted. Above 0.5 routes to episodic memory unless steps or procedural wording matched first. With type 'fact' it is not stored, but lengthens the fact's first review interval (×(1 + weight))."
  2. Changed4 schema fields changedv0.5.2
    • changedInput schema / properties / confidence / description
      Previous value: -"How certain this is (0–1). Above 0.9 routes to core memory."New value: +"How certain this is (0–1), kept with facts. Above 0.9 routes to core memory unless an earlier routing rule matched."
    • changedInput schema / properties / context / description
      Previous value: -"Context domain, e.g. 'work', 'personal', 'learning'."New value: +"Context domain, e.g. 'work', 'personal', 'learning'. Kept with episodes only."
    • changedInput schema / properties / emotionalWeight / description
      Previous value: -"Emotional significance (0–1). Detected from the content when omitted. Above 0.5 routes to episodic memory."New value: +"Emotional significance (0–1). Detected from the content when omitted. Above 0.5 routes to episodic memory unless steps or procedural wording matched first."
    • changedInput schema / properties / source / description
      Previous value: -"Where this came from, e.g. 'user', 'ai', 'import'."New value: +"Where this came from, e.g. 'user', 'ai', 'import'. Kept with facts and episodes."
  3. Changed1 schema field changedv0.4.9
    • changedInput schema / properties / steps / description
      Previous value: -"Ordered steps. Required when type is 'procedure'."New value: +"Ordered steps of a procedure. Optional: without them the steps are taken from the content (numbered or bulleted lines, otherwise every line)."
  4. Changed1 schema field changedv0.1.7
    • changedInput schema / properties / emotionalWeight / description
      Previous value: -"Emotional significance (0–1). Detected from the content when omitted."New value: +"Emotional significance (0–1). Detected from the content when omitted. Above 0.5 routes to episodic memory."
  5. First observedv0.1.5

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=false), the description discloses the routing precedence ('first match wins'), that every call adds a new memory except repeated core memories which update, the working-memory seven-item replacement behavior, that long-term memory is never otherwise mutated, and that the new id is returned. These are exactly the mutation/idempotency nuances the annotations only hint at.

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?

Dense and front-loaded, leading with the purpose before the routing detail. It is long relative to most descriptions, but nearly every clause carries distinct behavioral information; only the repetition of the routing rules against the schema keeps it from a 5.

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?

For a 9-parameter mutation tool with an output schema present, the description covers what the annotations cannot: routing outcomes, duplicate risk, working-memory eviction, and return value. Nothing an agent needs to call it correctly is missing.

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 baseline would be 3, but the description adds real value: the ordered routing precedence among `steps`/procedural wording, `emotionalWeight` > 0.5, `confidence` > 0.9, and the interaction where an explicit `type` overrides auto. That precedence is not fully evident from per-parameter schema text alone.

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 and resource ('write something into long-term memory') plus the scope of persistence ('survives this conversation'), and it is trivially separable from siblings recall/forget/consolidate. An agent knows exactly what this does without opening the 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?

Explicitly routes the agent: 'If it may already be stored, check with zenbrain_recall first: storing it again adds a duplicate,' and states when to set `type` versus let auto-routing decide. Names the alternative sibling and the condition that selects it.

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