rsi_memory_health

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

With no annotations, the description carries the full burden and does well: it discloses what scan writes (a finding against every retrieved id), the exact conditions that open incorrect and stale_source findings, and the important safety fact that 'scan never archives by itself.' It still omits whether resolve actions like archive are reversible and what side effects resolve has on the underlying memory.

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 content is front-loaded with the action list and dense with useful rules, but the entire description is duplicated verbatim in English and Chinese, roughly doubling the length without adding new information for most readers.

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?

For a 5-parameter, no-annotation, no-output-schema tool, the description covers the action semantics, the finding-opening rules, and the key safety boundary. It stops short of describing finding shape or resolve side effects, which are the remaining gaps an agent must infer from the schema.

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% with enums and inline descriptions for action, status, finding_id and resolution, so the schema already does the heavy lifting. The description reinforces the resolution enum and the resolve workflow but adds no format or constraint detail beyond what the schema provides, making baseline 3 appropriate.

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 resource (memory health findings) and enumerates its four action modes, with concrete behavioral detail for scan (attributing rejected/low-rated recalls, opening incorrect and stale_source findings). It distinguishes this tool from generic recall/review siblings by framing it around health findings, though it never names an alternative tool directly.

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 is only implied: the action list plus notes like 'resolve is archive, revise, keep, or snooze' and 'Scan never archives by itself' hint at the workflow (scan → list/explain → resolve), but the description states no explicit when-to-use, when-not-to-use, or alternative-sibling guidance.

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