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

No annotations are supplied, so the description carries the full burden, and it does disclose a lot: refusal-on-unparseable behavior, that the response echoes how the condition was interpreted, that a run of qualifying bars counts once at the first bar, that only closed bars are used, and the cost model ('one answer for every ten moments'). What it omits is the concrete shape of the returned moments — 'what was knowable then and the path that followed' is evocative but not specific about fields, and there is no output schema to fall back on.

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?

Purpose and the alternative are front-loaded, and the condition taxonomy earns its length because it defines the accepted grammar. Minor waste: the cost note appears both in the prose ('one answer for every ten moments') and again in the `limit` schema description, and the middle sentence is a dense run-on that takes effort to parse.

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 three-parameter tool with no annotations and no output schema, the description covers invocation, refusal semantics, interpretation echo, counting rules, and cost — enough to call it correctly. The remaining gap is the return payload: without an output schema, an agent still cannot predict the fields of each returned moment beyond 'knowable then' and 'path that followed'.

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 baseline would be 3, but the description adds real meaning: `q` is constrained to a closed set of expressible facts with worked examples and a stated refusal path, `asset` is tied to list_coverage as the source of valid symbols, and `limit` is framed in terms of cost ('one answer per ten'). That is meaningfully more than the schema's one-line examples.

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?

States a specific verb and resource ('Find every past moment a condition was true') and immediately qualifies the output ordering and payload ('newest first, each with what was knowable then and the path that followed'). It explicitly distinguishes itself from the sibling find_analogs, so an agent can route without opening either schema.

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?

Gives an explicit selection rule: use this when the condition can be stated, use find_analogs when searching by the shape of the move. It then defines what counts as a valid condition (price level, move over a window, distance from 7-day high, volatility vs. month) and states the negative case — anything else is refused rather than guessed.

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