search_memory

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

With no annotations, the description carries the full behavioral burden. It usefully characterizes the data domain as 'durable project knowledge' and implies a read-only search, but it does not explicitly state side-effect safety, permission requirements, or result behavior. The scope information adds some value, but the safety and return profile remain implicit.

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 two sentences with no filler. The core action and object are front-loaded ('Search durable project knowledge and previous important decisions'), followed by concrete usage scenarios and an explicit alternative, so every sentence earns its place.

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 the moderate complexity (4 parameters, no output schema), the description covers what the tool searches, when to use it, and how it relates to get_context. The main omissions are the result shape and any memory_types value semantics, but for selecting and invoking a search tool the provided context is nearly sufficient.

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 coverage is 100%, so the baseline is 3. The description adds semantic guidance for the query parameter by specifying the kinds of questions it should address, such as 'why a previous architectural or implementation decision was made' and long-term facts, conventions, and preferences. It does not add detail for limit or memory_types, but the core query intent is meaningfully enriched.

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 states a specific verb and resource: 'Search durable project knowledge and previous important decisions.' It further clarifies scope with concrete use cases (reasons behind decisions, long-term facts, conventions, user preferences) and positions itself against the get_context sibling, making it easy to distinguish.

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?

The description provides explicit when-to-use conditions: 'Use when reasoning depends on why a previous architectural or implementation decision was made, or to find long-term project facts, conventions, and user preferences.' It also names an alternative and a routing rule: 'Call this when get_context() does not contain the needed information.'

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