Skip to main content
Glama
dreamor

MemVault

by dreamor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

search_memory

Read-onlyIdempotent

Search stored memories with hybrid keyword-vector retrieval, optional filters, and relevance thresholds to retrieve past decisions, preferences, and conventions across sessions.

Instructions

Search stored memories. mode defaults to 'hybrid' (keyword + vector via RRF); 'keyword' is text-only and 'semantic' is vector-only. Semantic/hybrid need an embedding provider — when embeddings are unavailable the query falls back to keyword and each result reports search_mode='keyword'. Supports namespace, type_filter, priority_filter, top_k (default 10), min_score, and optional expand_relations for one-hop relation context. Read-only; does not mutate memories.

Input Schema

NameRequiredDescriptionDefault
modeNoSearch mode: "hybrid" (default; keyword + vector via RRF), "keyword" (text-only), or "semantic" (vector-only). Semantic/hybrid fall back to keyword when embeddings are unavailable.hybrid
queryYesSearch query string
top_kNoMaximum number of results to return
api_keyNoAPI key for agent authentication (required if agent has a registered key)
agent_idNoID of the requesting agent
min_scoreNoDrop results whose final (post-rerank) relevance score is below this threshold. Unset = return the full top_k regardless of score, the pre-existing behavior. Lets callers distinguish "no confident match" (empty result) from "weak matches padded to top_k".
namespaceNoFilter by namespace
type_filterNoFilter by memory type
priority_filterNoFilter by priority
expand_relationsNoAttach each result's one-hop relation neighborhood (semantic graph expansion, C5). Default off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.10
    • changedInput schema / properties / mode / description
      Previous value: -"Search mode: \"keyword\" (default), \"semantic\" (vector), or \"hybrid\" (both)"New value: +"Search mode: \"hybrid\" (default; keyword + vector via RRF), \"keyword\"\n(text-only), or \"semantic\" (vector-only). Semantic/hybrid fall back to\nkeyword when embeddings are unavailable."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavior beyond them: hybrid/keyword/semantic fallback, search_mode reporting, min_score filtering semantics, and one-hop relation expansion. It also explicitly confirms the tool does not mutate memories.

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?

Front-loads the purpose, then explains mode behavior, fallback, supported filters, and safety in a compact sequence. It is dense but every clause is relevant for a 10-parameter search tool, with no wasted framing.

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 search tool with no output schema, the description covers the important invocation context: retrieval modes, fallback behavior, filtering options, score thresholding, relation expansion, and read-only safety. It also notes that results report search_mode, which is enough for correct use.

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 schema already documents all parameters and a baseline of 3 would be appropriate. The description adds useful context for mode defaults, embedding fallback, top_k default, min_score purpose, and expand_relations, though it does not mention api_key/agent_id because the schema covers them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search stored memories") and outlines the available modes, so the core purpose is clear. It does not explicitly distinguish this from sibling retrieval tools such as list_inbox or review_memory, but an agent can still infer that this is the query-based memory lookup tool.

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?

Explains the mode choices and the important fallback behavior when embeddings are unavailable, including that results report search_mode='keyword'. It does not explicitly say when to prefer this tool over alternatives like list_inbox or review_memory, but the retrieval context is otherwise clear.

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