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

Annotations already mark the tool as read-only and non-destructive, and the description adds substantial behavioral context beyond that: truncation semantics with *_results_truncated flags, the exact structural ranking formula, recency_window zero-weight behavior, memory_id precedence, trust-mode scoring, and lean-result rendering rules. No statement contradicts the annotations.

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?

Although long, the description is densely informative and well-structured with bullet sections, bolded section names, and clear mode/usage/format subsections. Every sentence contributes operational meaning, and the most decision-relevant facts (alternative tools, truncation, and scope precedence) are stated directly rather than buried.

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 tool's complexity — two modes, four result sections, truncation flags, filtering, output formatting, and no output schema — the description covers all necessary invocation and interpretation details. It even explains the actionable gap between uncurated and potentially_stale and tells the agent to call recall(id) for full content, leaving no critical gap.

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 only 14%, so the description carries the parameter burden, and it does so thoroughly for limit, mode, memory_id, domain, node_kind, and recency_window. It explains default limit, the trust-mode switch, scoping precedence, filtering behavior, and how recency_window affects weighting. The tags parameter is not explained in the description, which prevents a perfect score, but the overall compensation is strong.

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 opens with 'Dual-signal importance analysis' and immediately enumerates the four result sections, tying the tool to a specific analytic resource. It explicitly differentiates from siblings by naming history and audit as the correct tools for chronological listing and age-based staleness, so the agent can tell significance apart without opening other definitions.

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?

Usage guidance is explicit and actionable: 'Do not use this tool to list all memories chronologically — use history for that' and 'For age-based staleness, use audit(mode=stale)'. It also clarifies when to pass memory_id vs domain, how to paginate with limit, and that memory_id takes precedence when both are supplied.

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