Skip to main content
Glama

recall_iterative

Performs multi-hop memory recall: retrieves round-one results and outputs an ask prompt plus prior_ids so a follow-up call can retrieve the answer through a bridging entity.

Instructions

MULTI-HOP recall, PHASE 1 of 2 — use this instead of recall when the answer needs a fact that is reachable only THROUGH another one ("who manages the person who signed off on X", "what did the vendor we switched to in March charge us"). One-shot top-k systematically misses that second hop: the record holding it is similar to the BRIDGE entity, not to your question, so no amount of ranking brings it back.

HOW THIS WORKS, AND WHY YOU ARE IN THE LOOP. The fix is to read round-1, name what is missing, and search again — which needs a model. inspeximus does not have one and will not grow one: no LLM on the write path and none inside the read path either. You ARE the model. So this returns round-1 hits plus ask (the instruction) and prior_ids (the continuation token), you decide what the bridge is, and you hand it back to recall_followup. Your model stays yours; the retrieval, dedup and merge stay deterministic and ours.

Returns {k, max_followups, round, hits, prior_ids, ask, next_call, bounds} — your query is not echoed back (you sent it, and a memory server should not reflect caller text into a model's context). If hits already answer the question, stop here — the second call is optional and costs a retrieval.

BOUND: exactly ONE recall() and at most k records back (k hard-capped at INSPEXIMUS_MAX_K). The response size is a function of k alone and does NOT grow with the store — unlike this server's contradictions surface, whose all-pairs output reached ~150 MB at n=2,000.

Honours the active project scope, like recall; all_projects=True searches every project. A multi-hop walk must not be a side door out of the scope its first hop respected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNo
fullNo
queryYes
user_idNo
agent_idNo
session_idNo
all_projectsNo
trusted_onlyNo
max_followupsNo
snippet_charsNo
Install Server

TDQS

A4.5/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 it delivers: it reveals that the tool performs exactly one underlying recall(), caps at `k`, returns `ask` and `prior_ids` as a continuation token, does not echo the query, keeps response size a function of `k`, and honors project scope. This goes well beyond a generic 'recall with followups' statement and gives the agent real operational expectations.

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 long but front-loaded with the core purpose and examples before the deeper mechanics. Every paragraph adds useful operational context, and the capitalization and paragraph breaks improve scannability. It is slightly verbose in places, such as the extended reasoning about why the model is in the loop and the ~150 MB comparison, but each detail supports correct use.

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?

Given the complexity of the multi-hop, two-phase protocol, no annotations, and no output schema, the description is remarkably complete: it explains the return fields, the continuation flow, the bound on recalls, the scope behavior, and when to stop. The main gap is that it never defines the remaining parameters' semantics, so the tool is not fully self-contained for every invocation scenario.

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 description coverage is 0%, so the description must compensate. It does add meaning for important parameters: `k` is hard-capped, `all_projects=True` searches every project, and the query is intentionally not echoed. However, several parameters remain unexplained (`full`, `trusted_only`, `snippet_chars`, `user_id`, `agent_id`, `session_id`), leaving noticeable gaps in parameter understanding.

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?

The description opens with a specific, distinguishing purpose: 'MULTI-HOP recall, PHASE 1 of 2 — use this instead of `recall` when the answer needs a fact reachable only THROUGH another one.' It names the exact operation, the phase, and the sibling it differs from, with concrete examples. This is not a tautology and would let an agent immediately understand what the tool does.

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?

It gives explicit when-to-use guidance: use instead of recall for multi-hop facts; stop if round-1 hits already answer; hand results to `recall_followup` when a bridge is needed. It also conditions behavior on `all_projects` and warns against using multi-hop as a scope escape. This clearly routes the agent between recall, recall_iterative, and recall_followup.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DanceNitra/inspeximus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server