Skip to main content
Glama
zensation-ai

ZenBrain

Official
by zensation-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Recall memories

zenbrain_recall
Read-only

Search long-term memory across episodic, semantic, procedural and core layers to retrieve relevant past context before answering questions about earlier sessions.

Instructions

Search long-term memory for anything relevant to a query. By default it searches the episodic, semantic, procedural and core layers; working memory (a handful of recently stored items, held only while the server runs) is searched only when named in layers. Returns results ranked by relevance, each tagged with the layer it came from. Use this before answering when the user refers to something from an earlier session. To see how much is stored rather than what, use zenbrain_health; to save something, use zenbrain_store.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many results to return at most, after ranking (default 10).
queryYesWhat to look for, in plain language.
layersNoRestrict the search to these layers. Defaults to episodic, semantic, procedural and core; add 'working' to include recently stored items held in memory.
minConfidenceNoLeave out results whose confidence is below this value. Applied before the final ranking, so fewer than `limit` results may come back. Facts use their stored confidence, procedures their success rate; core blocks, episodes and working-memory items count as 1 and are kept.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesHow many memories were returned.
resultsYesMatching memories, most relevant first.
skippedYesRows that carried no readable content and were left out of `results`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.10
    • changedInput schema / properties / minConfidence / description
      Previous value: -"Leave out results whose stored confidence is below this value; results stored without a confidence count as 1 and are kept."New value: +"Leave out results whose confidence is below this value. Applied before the final ranking, so fewer than `limit` results may come back. Facts use their stored confidence, procedures their success rate; core blocks, episodes and working-memory items count as 1 and are kept."
  2. Changed4 schema fields changedv0.4.9
    • removedInput schema / properties / includeContext
      Removed value: -{
-  "description": "Boost results whose stored context (time of day, weekday, task type) matches the current one.",
-  "type": "boolean"
-}
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum results (default 10)."New value: +"How many results to return at most, after ranking (default 10)."
    • changedInput schema / properties / minConfidence / description
      Previous value: -"Drop results below this confidence."New value: +"Leave out results whose stored confidence is below this value; results stored without a confidence count as 1 and are kept."
    • removedInput schema / properties / taskType
      Removed value: -{
-  "description": "Current task, e.g. 'coding', 'writing'. Only has an effect together with `includeContext: true`.",
-  "type": "string"
-}
  3. Changed3 schema fields changedv0.1.7
    • changedInput schema / properties / includeContext / description
      Previous value: -"Boost results matching the current context."New value: +"Boost results whose stored context (time of day, weekday, task type) matches the current one."
    • changedInput schema / properties / layers / description
      Previous value: -"Restrict the search to these layers. Defaults to all but working."New value: +"Restrict the search to these layers. Defaults to episodic, semantic, procedural and core; add 'working' to include recently stored items held in memory."
    • changedInput schema / properties / taskType / description
      Previous value: -"Current task, e.g. 'coding', 'writing' — used for context matching."New value: +"Current task, e.g. 'coding', 'writing'. Only has an effect together with `includeContext: true`."
  4. First observedv0.1.5

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real context beyond that: working memory is volatile and only lives while the server runs, default layers searched, results are ranked and layer-tagged. It stops short of describing pagination or result shape, but the output schema handles that.

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, each earning its place: capability, default layer behavior, return characteristics, then usage and alternatives. Front-loaded with the core verb and scope with no throat-clearing.

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 read-only search tool with an output schema and full parameter coverage, the description covers purpose, default behavior, volatility caveat, and sibling routing. Nothing needed 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all four parameters are documented in the schema itself, and the description largely echoes the layers default. Baseline 3 is appropriate; the description adds minimal meaning beyond what the schema already states about layers and limit.

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 (search) and resource (long-term memory) with clear scope: relevance-ranked recall across named layers. An agent can tell it apart from zenbrain_store and zenbrain_health 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 Guidelines5/5

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

Explicitly says when to use it ('before answering when the user refers to something from an earlier session') and names both alternatives with their own purposes ('zenbrain_health' for how much is stored, 'zenbrain_store' to save). Routing is fully determined.

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