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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the return shape (ranked candidates with numeric IDs, text, source, type, timestamps, relevance scores), warns that results may be weak or empty, and states retrieval is bounded. It also rules out side effects such as changing memories, searching the web, reading unsaved chat history, or accessing other users' data.

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

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

The description is front-loaded with the core action and then layers use cases, return details, caveats, and boundaries in a tight sequence. Every sentence adds a distinct operational detail, and there is no repetition or filler.

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

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

Given that there is no output schema, the description compensates by explaining return fields, result quality, and retrieval bounds. It also covers authentication scope, data boundaries, and side-effect exclusions, leaving no major gap for an agent deciding whether and how to call the tool.

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

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

Schema description coverage is 100%, so the schema already explains query, type, source, and limit in detail. The description mentions returned fields such as source and type but does not add meaningful guidance about how to use those fields as filters beyond what the schema provides, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource: search previously saved memories in the authenticated user's STEM account. It clearly separates itself from mutation siblings by stating 'This read does not change memories,' but it never names or routes to a specific sibling tool such as graph or memory_status, so sibling differentiation is implied rather than explicit.

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

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

It provides clear when-to-use cases: recall preferences, past decisions, resume a project, or reuse context saved by another compatible assistant. It also sets boundaries by saying retrieval is bounded and not an exhaustive archive search, but it does not explicitly point the agent to an alternative sibling when a broader search is needed.

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