Skip to main content
Glama

memra_recall

Search memories in Memra by semantic similarity. Returns ranked results by relevance. Replaces memra_search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoFilter by tags
typeNoFilter by memory type
limitNoMax results to return
queryYesSearch query for semantic matching
sinceNoOnly memories created at or after this ISO-8601 date.
untilNoOnly memories created at or before this ISO-8601 date.
not_tagsNoExclude memories carrying any of these tags.
used_idsNoFeedback: memory IDs from your PREVIOUS recall that you actually used. They gain a small permanent ranking boost — pass these every time to make recall learn.
namespaceYesTenant namespace to search within
max_tokensNoToken budget: return the best-scoring results that fit within this many tokens (chars/4 heuristic). Combine with a higher limit to fill the budget.
project_idNoFilter by project ID
min_confidenceNoMinimum confidence score
wait_for_revisionNoRead-your-writes: pass the revision returned by memra_remember to block (max 5s) until that write is indexed and searchable. Use when recalling something you just stored.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYes
estimated_tokensNo
total_candidatesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses notable behaviors: used_ids cause a permanent ranking boost, wait_for_revision blocks up to 5s, and max_tokens uses a chars/4 heuristic. Does not mention error conditions or side effects beyond these, but the key behavioral nuances are exposed.

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?

The description is a single, compact sentence that conveys purpose and key differentiator without redundant filler. All supplementary information is placed in parameter descriptions where it belongs.

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?

Output schema is present, so return values are covered. The description explains critical behavioral parameters (used_ids, wait_for_revision) and mentions replacement of memra_search. It does not explicitly discuss error handling or contrast with memra_list/memra_get, but given the schema and output schema, it is reasonably complete.

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% and parameter descriptions are detailed, including examples and heuristics (chars/4). The tool description itself adds little beyond the schema, but the schema is rich enough to fully explain parameters.

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?

Clear verb 'Search', specific object 'memories', method 'semantic similarity', and expected result 'ranked results by relevance'. Explicitly states it replaces memra_search, which differentiates it from that sibling.

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?

Mentions replacement of memra_search, giving clear direction on when to use. Parameter descriptions add usage context (e.g., used_ids as feedback, wait_for_revision for read-your-writes). Does not contrast with all sibling tools but enough guidance is provided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.