Skip to main content
Glama
Sign In
Helios

Helios

by brazaoo4
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

recall_memories

Read-onlyIdempotent

Search active and stale Helios memories with BM25 ranking and category priority to retrieve current task context; inspect flagged stale records before acting.

Instructions

Search active and stale memories in Helios using SQLite FTS5 BM25 ranking and category priority (rule > fact > preference > episodic). Read-only: resolves scope aliases, merges 'global' rules when include_global=True, returns top priority records when query is empty, and emits a warning if directive_version lags the server. If any returned memory is flagged [STALE], inspect its anchor_files before acting and resolve via revalidate_memories or save_memory. Use recall_memories at task start for current state; use recall_history instead to inspect superseded or archived records.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "recall_memories"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of memories to return (clamped between 1 and 50).
queryNoNatural language search query or keywords to match via FTS5 BM25.
scopeNoProject, repository, or directory name (e.g., 'homelab', 'ticketera', 'global').global
categoryNoOptional filter to retrieve only a specific category (e.g., 'rule' for coding guardrails).
status_filterNoFilter by drift status: 'all' (default), 'active' only, or 'stale' only (to audit drifted memories).all
include_globalNoWhether to include global guardrails and rules alongside scope-specific memories.
directive_versionNoClient directive version from the local <!-- HELIOS:START --> header (e.g., '1.5.0'). Leave empty if unversioned/legacy.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.3

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds real behavioral context: scope alias resolution, global-rule merging when include_global=True, empty-query fallback to top priority records, and a directive_version lag warning. These are behaviors an agent could not infer from the annotations or schema.

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?

Four short sentences, front-loaded with purpose and ranking model, then behavior, then the stale-result workflow, then sibling routing. Every sentence carries actionable content and none restates the tool name or schema.

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 7-parameter read tool with an output schema, the description covers what the annotations do not: ranking order, scope/global merging, empty-query behavior, version-drift warnings, and the stale-anchor workflow. Return value shape is correctly left to the output schema.

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 100%, so the baseline is 3; the description earns a bump by explaining runtime semantics the schema does not, notably include_global's merging behavior, the empty-query fallback, and what directive_version is compared against. It stops short of covering status_filter or limit interaction, so it is not a full 5.

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 ('Search active and stale memories in Helios') plus the mechanism (FTS5 BM25 ranking, category priority rule > fact > preference > episodic). It explicitly distinguishes itself from the sibling recall_history, so an agent can pick between them without opening either schema.

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?

Gives explicit when-to-use ('at task start for current state'), when-not/alternative ('use recall_history instead to inspect superseded or archived records'), and a follow-up routing rule for stale results ('resolve via revalidate_memories or save_memory'). Nothing about tool selection is left to inference.

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