Skip to main content
Glama

recall

Retrieve top-k agent memories from inspeximus ranked 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. Records the read-path guards quarantined (instruction-shaped text, 3.5.0) are left out unless include_quarantined is set; keyword-stuffed records never outrank clean ones. include_archive also searches the archive segments beside the store (old captured mechanics moved out by --archive); it opens every segment, so it is slower and off by default.

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: INSPEXIMUS_TRUST_SEEDS on this server) returns only memories anchored to a trusted signing key or source — a deterministic defense against injected/poisoned memories from untrusted writers. With no trust root configured the call is an error, not an empty list that reads as "nothing trusted matched". 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
include_archiveNo
resolve_conflictsNo
include_quarantinedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.16.1
    • addedInput schema / properties / include_archive
      Added value: +{
      +  "default": false,
      +  "title": "Include Archive",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changedv3.5.1
    • addedInput schema / properties / include_quarantined
      Added value: +{
      +  "default": false,
      +  "title": "Include Quarantined",
      +  "type": "boolean"
      +}
  3. 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"
      +}
  4. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: quarantined instruction-shaped text excluded by default, trust-root requirement and its error-not-empty-list behavior, hard cap on k, deterministic MMR and conflict resolution semantics, warrant tier states with explicit branching advice, and archive-scan cost. This is far beyond anything structured fields provide.

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?

Large but front-loaded: the ranking rule and purpose lead, then projections, then optional flags, then scope. Nearly every sentence carries operational detail, though the parenthetical about 'standard progressive-disclosure practice' is filler that could be cut.

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 15-parameter retrieval tool with an output schema present, the description covers the ranking model, default projection shape, safety exclusions, trust behavior, conflict resolution, and project scoping. An agent has everything needed to call it correctly without the schema or annotations filling gaps.

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 for 15 parameters, and it documents roughly ten of them with real semantics (k cap, mmr range and direction, full, snippet_chars, include_archive, trusted_only, resolve_conflicts, with_warrant, all_projects, include_quarantined). It leaves user_id, agent_id, session_id, and rerank_by entirely unexplained, keeping it out of the top band.

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 with a precise ranking rule ('top-k memories by RELEVANCE × accrued VALUE (not recency)'), and explicitly contrasts with the recency alternative. An agent can distinguish this from siblings like get, recall_iterative, and recall_followup 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 Guidelines4/5

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

Gives clear when-to-use ('load relevant prior knowledge before reasoning') and when-nots for several flags (archive is slower/off by default, snippet truncation is off by default because it can cut corrected values, full=True for complete records). It routes to get(id) for full text and to where_am_i()/projects() for scope. It does not name recall_iterative or recall_followup as alternatives for multi-step recall, 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