Skip to main content
Glama

recall

Retrieve top-k memories by relevance and accrued value, not recency, to load relevant prior knowledge before reasoning.

Instructions

Retrieve the top-k memories by RELEVANCE × accrued VALUE (not recency). Use this to load relevant prior knowledge before reasoning.

Compact by default: each hit is a small projection — {id, text, score, value, tags} — dropping internal bookkeeping fields the model doesn't reason over, which keeps recall cheap to drop into a prompt. FULL TEXT IS KEPT (no truncation by default). Pass snippet_chars>0 to opt into snippet truncation (flags truncated; then use get(id) for full text) — note that truncation can cut off a corrected value past the boundary, so it is off by default. Set full=True to return complete records (all fields). k is hard-capped for safety.

mmr (0..1, off by default) reranks for DIVERSITY so you don't get k near-duplicate memories — 1.0 = pure relevance, lower = more diverse (deterministic Maximal Marginal Relevance, zero-LLM). trusted_only=True (needs a configured trust root) returns only memories anchored to a trusted signing key — a deterministic defense against injected/poisoned memories from untrusted writers. resolve_conflicts=True (or server-wide INSPEXIMUS_READ_RESOLVER=1) resolves near-duplicate same-subject candidates at read time by value BIRTH — an un-keyed restatement of a superseded value is demoted below the correction instead of out-ranking it; the surviving hit carries resolved_over ids. Deterministic, zero-LLM. (Standard progressive-disclosure / small-to-big retrieval practice, not a inspeximus-specific technique.)

with_warrant=True adds a warrant tier to every hit — earned (outcome credit that did not come from the record grading itself, or a memory that GRADUATED to semantic through the corroboration bar), corroborated (>=2 distinct sources, or distinct verified keys under strict_corroboration, but no outcome credit yet), or unwarranted (single self-asserted, no lineage, or retracted). BRANCH ON IT: unwarranted means no independent channel backs this memory, so it may inform your reasoning but should not by itself drive an action. It is deliberately a discrete state rather than a low score, because a low score reads downstream as a weak "yes" and gets acted on anyway. Additive: ordering, membership and every other field are identical with it on or off.

PROJECT SCOPE: when this server runs with --project <name>, recall returns only that project's memories plus any memory carrying no project stamp (memories written before you adopted a scope stay reachable — adopting one narrows what you see without hiding what you already had). all_projects=True is the escape hatch for "I know I wrote this somewhere": it searches EVERY project in the store. Each hit then carries the project it belongs to, so a cross-project answer says where it came from. Call where_am_i() to see which store and scope you are on, and projects() to list the scopes present.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNo
mmrNo
fullNo
queryYes
user_idNo
agent_idNo
rerank_byNo
session_idNo
all_projectsNo
trusted_onlyNo
with_warrantNo
snippet_charsNo
resolve_conflictsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv2.20.1
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Agent Id"
      +}
    • addedInput schema / properties / all_projects
      Added value: +{
      +  "default": false,
      +  "title": "All Projects",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / full
      Added value: +{
      +  "default": false,
      +  "title": "Full",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / mmr
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Mmr"
      +}
    • addedInput schema / properties / rerank_by
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Rerank By"
      +}
    • addedInput schema / properties / resolve_conflicts
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Resolve Conflicts"
      +}
    • addedInput schema / properties / session_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Session Id"
      +}
    • addedInput schema / properties / snippet_chars
      Added value: +{
      +  "default": 0,
      +  "title": "Snippet Chars",
      +  "type": "integer"
      +}
    • addedInput schema / properties / trusted_only
      Added value: +{
      +  "default": false,
      +  "title": "Trusted Only",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / user_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "User Id"
      +}
    • addedInput schema / properties / with_warrant
      Added value: +{
      +  "default": false,
      +  "title": "With Warrant",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so extensively. It discloses ranking behavior, truncation semantics, the effect of full=True, k hard-capping, deterministic mmr reranking, trusted_only requirements, conflict resolution behavior, warrant tiers and their interpretation, and project-scope behavior. This is far beyond what the schema alone would 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?

The description is front-loaded with the core purpose and then organizes details logically from default behavior to optional modes to project scope. It is long, but the complexity of the tool and the absence of annotations justify most of the length. A few repetitions, such as 'deterministic' and 'zero-LLM' appearing multiple times, keep it from being maximally concise.

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 a complex retrieval tool with no annotations and an output schema the description is not relying on, the definition covers most behavioral edge cases: snippet truncation, conflict resolution, warrant semantics, project scoping, and safety caps. It is incomplete mainly because four parameters (user_id, agent_id, session_id, rerank_by) are left semantically unexplained, and the 'hard-capped' k never states the actual cap.

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 description coverage is 0%, so the description must compensate, and it does for most parameters: k, mmr, full, snippet_chars, trusted_only, resolve_conflicts, with_warrant, and all_projects all receive meaningful behavioral explanations beyond their type/default. However, user_id, agent_id, session_id, and rerank_by are not explained at all, leaving a real gap for a tool with 13 parameters.

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?

The description opens with a specific verb and resource: 'Retrieve the top-k memories by RELEVANCE × accrued VALUE (not recency).' It clearly states the core purpose and the intended use case, 'load relevant prior knowledge before reasoning.' However, it does not explicitly distinguish itself from closely named siblings like recall_iterative or recall_followup, so it stops short of full sibling differentiation.

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 description gives clear usage context: 'Use this to load relevant prior knowledge before reasoning' and notes that compact hits 'keeps recall cheap to drop into a prompt.' It also provides follow-up guidance such as using get(id) for full text after snippet truncation and calling where_am_i()/projects() for scope orientation. It does not explicitly state when not to use this tool versus alternatives like recall_iterative, so exclusions are missing.

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