Skip to main content
Glama

memory_search

Read-onlyIdempotent

Search current memory versions for one project using full-text queries to retrieve relevant investigation records and context.

Instructions

Project-isolated FTS search over latest memory versions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
projectYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world, non-destructive profile, so safety is covered. The description adds genuinely non-obvious behavior: matching is keyword/full-text rather than semantic, results are scoped to a single project, and only the latest version of each memory is returned (superseded versions are excluded). It omits ranking/ordering and truncation behavior.

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?

A single front-loaded sentence with no filler; every phrase (project-isolated, FTS, latest versions) carries meaning. It is efficient, though the terseness contributes to the coverage gaps elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 0% schema description coverage and no output schema, the agent is left without parameter guidance, result ordering, or pagination expectations. Annotations and the lack of an output schema relieve some burden, but the description still leaves too much unspecified for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for all three parameters, yet it explains none of them. It never clarifies that 'query' is an FTS expression (and what syntax is valid), nor what 'project' format or 'limit' semantics (default 20, max 50) mean in practice.

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 scope qualifiers ('project-isolated', 'FTS', 'latest memory versions') that tell the agent what kind of matching to expect. It does not distinguish itself from siblings like memory_context or memory_graph, which also read memory, so the agent must infer which retrieval mode applies.

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?

There is no when-to-use guidance and no named alternative, despite several memory-reading siblings (memory_context, memory_graph) in the toolset. The agent gets no signal about when keyword search is preferable to graph traversal or context assembly.

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