Skip to main content
Glama

memory_search

Read-onlyIdempotent

Search stored key-value memory entries using full-text queries across keys, values, and tags. Returns relevant matches with snippets, supports partial words and accent-insensitive matching.

Instructions

Full-text search across keys, values AND tags. Uses an FTS5 index with bm25 relevance ranking (key-weighted), word-stemming, diacritic folding and prefix matching — so multi-word, partial and accent-insensitive queries all hit, ranked by relevance. Falls back to a LIKE substring scan if the SQLite build lacks FTS5. Returns top N matches with a snippet. Case-insensitive. privacy_mode=summary omits snippets.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitYesMax matches to return.
queryYesKeyword query. Matched against keys and values.
privacy_modeNosummary = keys/meta without full values; structured/raw = full entries (local store parity).structured

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / required
      Previous value: -[
      -  "query"
      -]New value: +[
      +  "query",
      +  "limit"
      +]
  2. Changed1 schema field changedv0.2.4
    • addedInput schema / properties / privacy_mode
      Added value: +{
      +  "default": "structured",
      +  "description": "summary = keys/meta without full values; structured/raw = full entries (local store parity).",
      +  "enum": [
      +    "summary",
      +    "structured",
      +    "raw"
      +  ],
      +  "type": "string"
      +}
  3. First observedv0.2.2

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint/idempotentHint annotations by disclosing bm25 ranking, key weighting, stemming, diacritic folding, prefix matching, case-insensitivity, LIKE fallback, snippet return, and privacy_mode snippet omission. This gives the agent an unusually complete behavioral model.

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 information-dense sentences, front-loaded with the core action and then expanding into matching behavior, fallback, return shape, and privacy behavior. Every clause adds operational value; no filler or redundancy.

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 query semantics, ranking, matching edge cases, fallback behavior, result truncation, snippet presence, and privacy-mode effects. An agent has everything it needs to select and invoke the tool correctly.

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 coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: key-weighted relevance, prefix/diacritic matching, top-N snippet return, and privacy_mode=summary omitting snippets. It also clarifies how query text is interpreted beyond the schema's simple 'matched against keys and values' note.

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 opens with 'Full-text search across keys, values AND tags', naming the specific verb, resource, and scope. This clearly distinguishes it from siblings like memory_get (exact retrieval) and memory_list (enumeration).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fuzzy, partial, or accent-insensitive search queries through its matching details, but it never explicitly states when to choose this over memory_get, memory_list, or memory_get_many. It provides clear context but no exclusions or alternative routing.

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