Skip to main content
Glama
Sign In
bantamkit

bantamkit

by Ink01101011
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Recall memories

memory_recall

Searches persistent memory for facts saved by past sessions so agents can recall earlier decisions before starting similar tasks or when users refer to prior work.

Instructions

Search persistent memory for facts a past session saved. Call it BEFORE starting a task that resembles past work, and when the user refers to something decided earlier; use memory_save to add a fact, and memory_compact or memory_dream only to tidy the store — this tool never changes what a fact says. Reads every layer in order — the project store, any read-only grants in .bantamkit/config.yaml, then the machine-wide profile — and returns the top word matches, never fewer than the store default of 3 when that many match; a query that is exactly a fact's name returns that fact alone. Pass file instead of query to see the facts linked to a file. Why it is not read-only: every hit is appended to the usage ledger (~/.bantamkit/usage/.jsonl) as a recall event — the staleness order memory_compact archives by — and a project fact file still in the 0.35.x format is rewritten once into the current one; both are best-effort and never fail a recall. A fact file that cannot be read is named in the reply, never silently skipped. Pass outcome: error to see only recorded failures.

Input Schema

NameRequiredDescriptionDefault
kNoFacts wanted, clamped to 1..5. Raised to the store default of 3 when smaller; never lowered below it.
fileNoA tracked file, or the shortest unique suffix of one (store.ts, memory/store.ts). Returns the facts linked to it and when it was last touched; query is then ignored.
queryNoWords a past-you would have used to describe the fact
outcomeNoKeep only facts saved with this outcome — `error` answers "what failed before", `success` "what worked". Facts with no outcome are dropped from the answer; omit it for the normal search.
include_archivedNoAlso search facts compaction moved to archive/. Archived matches come after the live ones, tagged [archived].

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.37.1
    • addedInput schema / properties / file
      Added value: +{
+  "description": "A tracked file, or the shortest unique suffix of one (store.ts, memory/store.ts). Returns the facts linked to it and when it was last touched; query is then ignored.",
+  "type": "string"
+}
    • addedInput schema / properties / include_archived
      Added value: +{
+  "default": false,
+  "description": "Also search facts compaction moved to archive/. Archived matches come after the live ones, tagged [archived].",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "query"
-]New value: +[]
  2. Changed1 schema field changedv0.36.2
    • addedInput schema / properties / outcome
      Added value: +{
+  "description": "Keep only facts saved with this outcome — `error` answers \"what failed before\", `success` \"what worked\". Facts with no outcome are dropped from the answer; omit it for the normal search.",
+  "enum": [
+    "error",
+    "success"
+  ],
+  "type": "string"
+}
  3. First observedv0.36.0

TDQS

A4.8/5.0
Behavior5/5

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

The annotations declare readOnlyHint=false, and the description explains why: every hit appends to the usage ledger and old-format project fact files may be rewritten once, both best-effort. It also discloses layer read order, minimum result behavior, exact-name behavior, and that unreadable fact files are named rather than silently skipped.

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?

The description is front-loaded with purpose and usage, and nearly every sentence carries useful behavioral detail. It is dense and long, with semicolon-heavy clauses, but not padded with empty filler.

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?

Given five optional parameters, an output schema, and annotations, the description covers timing, alternatives, side effects, read order, result rules, and failure handling. Nothing important for correct invocation appears to be 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 schema already documents all five parameters. The description still adds cross-parameter meaning: `file` supersedes `query`, exact fact-name queries return that fact alone, `outcome: error` filters to recorded failures, and `k` is floored by the store default.

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: search persistent memory for facts saved by a past session. It also distinguishes itself from memory_save and memory_compact/memory_dream, and explicitly says it never changes what a fact says.

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?

Gives explicit when-to-use guidance: before starting work resembling past work, and when the user refers to something decided earlier. It names alternatives for saving and tidying, and explains using `file` instead of `query`.

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