Skip to main content
Glama

WingmanProtocol Agent Gateway

search_memory

Read-onlyIdempotent

[stores] Full-text search over YOUR memory values using FTS5. Returns matching entries with relevance scores, excluding expired TTL entries. Scoped to memory you own — registered handle + secret required. Omit namespace to search all of your own memory.

Input Schema

NameRequiredDescriptionDefault
limitNomax results (default 20, max 100)
queryYesFTS5 search terms (porter stemmer, unicode61 tokenizer)
handleYes
secretNo
namespaceNonamespace to search within (omit to search all of yours)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / handle
      Added value: +{
      +  "type": "string"
      +}
    • changedInput schema / properties / namespace / description
      Previous value: -"namespace to search within (omit to search all)"New value: +"namespace to search within (omit to search all of yours)"
    • addedInput schema / properties / secret
      Added value: +{
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "query"
      -]New value: +[
      +  "handle",
      +  "query"
      +]
  2. Changed2 schema fields changed
    • changedInput schema / properties / namespace / description
      Previous value: -"namespace to search within"New value: +"namespace to search within (omit to search all)"
    • changedInput schema / required
      Previous value: -[
      -  "namespace",
      -  "query"
      -]New value: +[
      +  "query"
      +]
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds genuinely new behavior: relevance scores are returned, expired TTL entries are excluded, and a registered handle + secret are mandatory. That is real context beyond the structured fields, though rate limits and result shape beyond 'matching entries' remain unspecified.

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

Conciseness4/5

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

Four tight sentences, front-loaded with what the tool does and its FTS5 basis, then returning behavior, then auth, then scoping. The bracketed '[stores]' tag is mildly noisy but the rest earns its place.

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?

With no output schema and no annotations covering authentication, the description correctly supplies return content (entries with relevance scores), TTL filtering, and credential requirements. Only the exact result structure and failure modes are left open, which is minor for a read-only search.

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 coverage is 60%: limit, query and namespace are documented inline, while handle and secret have no schema description. The description partially compensates by tying handle+secret to registration and clarifying namespace omission, but adds no syntax or format detail for query beyond what the schema says about FTS5/porter stemmer.

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+resource ('Full-text search over YOUR memory values using FTS5') and bounds scope to memory the caller owns. It implicitly separates itself from fact-oriented siblings by emphasizing 'values', but never names a sibling like search_memory_facts or memory_recall, so an agent must infer the distinction.

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?

Gives one usable rule ('Omit namespace to search all of your own memory') and notes the auth requirement, which is enough to invoke it. It offers no guidance on when this is preferable to the many adjacent recall/search/list memory tools in the sibling set.

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.