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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description goes well beyond that by explaining the exact semantics of key outputs: margin_added is cash/margin at this leverage rather than full notional, risk_penalty_pct is measured against the fresh-entry alternative, and liquidation_before_stop means the exchange force-closes before the stop fires. That is exactly the extra behavioral context the annotations cannot supply.

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?

It is front-loaded correctly, opening with the purpose and closing with usage triggers, and every clause carries information. But the output-explanation passage is a single sprawling multi-clause sentence dense with em-dashes that is harder to parse than necessary; it would read better as a short bulleted field list.

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?

There is no output schema, so the description rightly carries the full burden of explaining return values, and it names every notable returned field (blended average, liquidation, breakeven before/after, margin_added, the three risk figures, risk_penalty_pct, liquidation_before_stop) with meaning attached. For a computation tool with 11 documented parameters this is sufficient for correct invocation.

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 parameter contract is fully documented in the structured data and the baseline is 3. The narrative adds interpretive meaning (e.g. add_price doubles as today's price, margin_added is not notional, inverse denomination in base coin), but most of this concerns outputs rather than the 11 input parameters themselves.

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: it is a 'should-I-average-down check' that compares adding at a worse price against buying the same total size fresh. That is a concrete, agent-readable purpose. It does not, however, differentiate itself from the close siblings workflow.run_average_entry, primitive.average_entry, or run_dca_entry, which an agent could easily confuse with this one.

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?

It gives explicit user-facing triggers ('should I add to this losing position?' / 'what does averaging down actually cost me here?') and frames the internal alternative it weighs (fresh entry at add_price). No when-NOT-to-use guidance or tool-level alternative (e.g. use run_average_entry for the plain blended price) is offered, so it stops short of a 5.

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