Skip to main content
Glama
LiLara-AI

ShadowGraph

Official
by LiLara-AI
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

shadowgraph_recall

Read-onlyIdempotent

Retrieve scoped memories and records by fusing lexical, vector, graph-distance, and temporal ranks. Returns only matching items with clear signal availability.

Instructions

Recall scoped memory and records by fusing lexical, vector, graph-distance, and temporal ranks. shadowgraph_search is plain content matching, shadowgraph_retrieve adds graph neighbours, shadowgraph_remember writes memory. Reads only. Every response declares which signals were available, so absent ones are never renamed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asOfNoISO 8601 instant to select by valid time, returning what was true then rather than now. Also enables temporal ranking.
limitNoMaximum items to return, 1-1000; the default is 50 and completeness.limitSource reports which applied. Out of range is rejected, never silently clamped.
queryNoFree text to rank against. An empty query still returns scope-matching records ranked by the remaining signals.
scopeNoScope selector. Omitted or partial fields mean explicit nulls, not "any": identity is the exact (project, userId, agentId, runId, memoryType, key) tuple, so a run-scoped memory never leaks into a user-only read.
offsetNoItems to skip before this window. Ordering is total and deterministic, so paging cannot drop or duplicate an item.
focalIdNoEntity id to measure graph distance from. Without it the graph signal reports available:false.
projectNoProject to recall from. Defaults to "default" for memory records rather than meaning all projects.
memoryTypeNoRestrict memory candidates to this type.
preferRecentNoEnable temporal ranking against now. Ignored when asOf is supplied, which already selects a point in time.
queryEmbeddingNoCaller-supplied query vector. Omit to use the configured provider; with neither, the semantic signal reports available:false and a reason.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYesThe window actually applied to the matching items.
itemsYesThe items in this window, in deterministic order.
completenessYesDeclares exactly what this response left out, so a truncated result can never look complete.
Install Server

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'Reads only' is redundant but harmless. The unique addition is 'Every response declares which signals were available, so absent ones are never renamed', a valuable behavioral guarantee about response transparency beyond the annotations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler; the core function is front-loaded, followed by sibling differentiation and a behavioral guarantee. Every sentence earns its place.

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?

The description covers operation, scope, safety, signal-availability behavior, and sibling routing, which is complete for a read-only tool with a rich input and output schema. The schema handles parameter details and return values, so nothing essential is missing.

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 100%, with detailed documentation for all 10 parameters, so the baseline is 3. The description adds high-level context about signal fusion but does not detail specific parameters beyond what the schema already provides.

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 leading verb 'Recall' plus the explicit fusion mechanism ('lexical, vector, graph-distance, and temporal ranks') identifies the operation precisely. It then contrasts with shadowgraph_search and shadowgraph_retrieve, making the function unmistakable and differentiating it from siblings.

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?

The description explicitly names sibling tools and their distinguishing behaviors ('shadowgraph_search is plain content matching, shadowgraph_retrieve adds graph neighbours, shadowgraph_remember writes memory'), giving an agent clear routing criteria. The implication that recall is for when fused ranking is needed is sufficient guidance.

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/LiLara-AI/shadowgraph'

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