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

With no annotations and no output schema, the description carries the burden and largely meets it: it explains the returned fields, the meaning of aggression above/below an open, the override condition (day and 60 disagreeing with week/month), and the profit-taking caveat (only when the 60 is red). It does not state what happens if a timeframe in the group is missing from 'opens' or that the operation is a pure read-only computation.

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?

Content is front-loaded with the core question and every sentence conveys return-value meaning rather than filler. It is, however, dense with undefined in-house jargon ('FTFC, Truth #2') and nested parentheticals that slow first-pass parsing.

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 side-effect-free computation tool with a fully described 3-parameter schema and no output schema, the description gives enough on the return shape and semantics to call it correctly. The gap is edge behavior — missing timeframe keys in 'opens' or mismatched group membership — which an agent would want spelled out.

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 defines group presets, the opens map with an example, and price as the last sale. The description adds only the interpretive gloss on what 'above an open' means behaviorally, not syntax or constraint detail beyond the schema. Baseline 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 states a specific evaluation: whether the last sale sits above, below, or mixed relative to the open of every timeframe in a group, and enumerates what it returns (side, color, aggression, state, override, profit-taking note). That is a concrete verb-plus-resource, not a restatement of the name. It only lightly differentiates from siblings ('a state, not a signal'), without naming find_signals or signals_in_force.

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 implied rather than stated: 'FTFC is a state, not a signal' hints that this is a contextual read used alongside signal tools, but no explicit when-to-use/when-not rule or named alternative is given. An agent must infer that this is a diagnostic rather than a scan like find_signals.

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