Skip to main content
Glama

search_memory

Search stored memory by project, category, tags, or free text query to retrieve relevant entries. Filter results by scope or metadata to find project context quickly.

Instructions

Search memory by project, category, tags, or free text.

Args: project: Optional project scope. category: Optional category filter. tags: JSON list of required tags (all must match). query: Free text search across key/value/tags/metadata. limit: Maximum results (default 50).

Returns: JSON: {"ok": true, "entries": [...]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo[]
limitNo
queryNo
projectNo
categoryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that tags are AND-matched ('all must match') and that query searches across key/value/tags/metadata, plus the return envelope shape. However it omits ranking, pagination, or scope constraints beyond the filter fields.

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?

Front-loaded one-line summary followed by clearly labeled Args and Returns sections. Every line is informative and there is no filler, though the Args block partially restates parameter names.

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 an output schema present, return values need not be explained (though they are), and all five parameters are covered. The remaining gap is the absence of guidance tying this tool to its siblings and any operational constraints.

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 0%, so the description must carry all parameter meaning, and it does: each of the five params is documented, adding semantics beyond the bare schema (tags is a JSON list where all must match, query spans key/value/tags/metadata, limit caps results at a default of 50).

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 (search) and resource (memory) plus the dimensions it can filter on (project, category, tags, free text). It implicitly distinguishes itself from write siblings like save_memory and delete_memory, though it never names an alternative such as get_memory for direct retrieval.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not-to-use guidance. The description never explains how this differs from get_memory (single entry) or list_memory_categories, leaving the agent to infer the appropriate context from the filter list alone.

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