Skip to main content
Glama

recall_fused

Retrieve memories using fused vector-graph recall: walks graph from top vector hit, folds connected facts into ranking; supports multi-hop reasoning, optional filters, and temporal timelines.

Instructions

Fused vector + graph recall: like recall, but also walks the graph from the top vector hit and folds any connected fact into the ranking — the tri-engine ranking (vector similarity + ColumnStore filter + graph reach) measured on multi-hop and temporal benchmarks. Reach for this when an answer needs a fact the query doesn't mention directly but a stored relate/extracted link connects (multi-hop reasoning, temporal chains). hops/graph_boost tune the graph reach; omit them for the proven defaults. Optionally narrow with an exact-match filter. Set date_field (the metadata key holding a YYYYMMDD date) to also get a dated_context timeline and a now anchor for temporal questions. Most relevant first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hopsNoGraph hops walked from the top vector hit (default 2). Higher reaches further but adds noise; capped at the `why` hop ceiling.
limitNoMaximum number of memories to return (default 10). Multi-hop reasoning benefits from a larger budget (~32-64); simple and temporal recall saturate early, where a larger budget only adds tokens.
queryYesNatural-language query to match semantically.
filterNoOptional exact-match metadata filter (e.g. `{"project": "veles", "status": "resolved"}`).
date_fieldNoName of the metadata field holding each fact's date as a `YYYYMMDD` integer (e.g. `"ts"`, `"occurred_at"`). When set, the result adds a `dated_context` timeline (facts date-prefixed and ordered oldest-first) plus a `now` anchor — the representation that lifts temporal reasoning. Omit for plain results.
graph_boostNoWeight added to a graph-reached fact's normalised vector score (default 0.15). Raise to trust the graph more, lower to trust vector similarity more.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowNoThe most recent date across `memories` (`YYYY-MM-DD`), the "now" anchor. Present only when `date_field` was set and at least one fact is dated.
memoriesYesRecalled memories, most relevant first.
dated_contextNoChronological, date-prefixed rendering of `memories` (`- [YYYY-MM-DD] content` per line, oldest first, undated facts last). Present only when `date_field` was set.
Behavior5/5

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

No annotations provided, so the description fully discloses the behavior: tri-engine ranking, graph walk from top vector hit, folding connected facts into ranking, default values for hops and graph_boost, and the effect of setting date_field (adds dated_context and now anchor). It is comprehensive and does not contradict any annotations.

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 a single paragraph that packs a lot of detail. It is front-loaded with the main purpose, but the length could be reduced for better conciseness. Nonetheless, every sentence adds value and the structure is logical.

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 the tool's complexity (6 parameters, output schema exists, multiple use cases), the description covers all needed aspects: algorithm, parameter tuning, default behaviors, and special features like timed recall. It is complete and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Schema coverage is 100%, but the description adds significant value beyond schema by explaining the purpose of hops and graph_boost in context of graph reach, recommending limit sizes for different recall types, and detailing the functionality of date_field. This enables correct parameter selection.

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 clearly states the tool's function as a fused vector+graph recall, distinguishes it from sibling `recall` by noting the graph walk, and specifies use cases like multi-hop reasoning and temporal chains. The verb+resource is specific and the purpose is unambiguous.

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?

Explicit guidance is provided: 'Reach for this when an answer needs a fact the query doesn't mention directly but a stored relate/extracted link connects (multi-hop reasoning, temporal chains).' It also advises to omit hops and graph_boost for defaults and explains when to use date_field. This clearly tells the agent when to use this tool over alternatives.

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

Install Server

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/cyberlife-coder/VelesDB'

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