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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context beyond them: omitted fees mean zero fees with no exchange lookup, direction is derived from entry/stop, no lot rounding, no inverse/liquidation support, and a do-not-invent policy for prices and risk. This is rich disclosure of scope limits and input defaults.

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?

Front-loaded with what is calculated and from what inputs, then usage, then exclusions. Every sentence carries a distinct constraint; no filler or redundancy across purposes.

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?

An output schema exists, so return values needn't be explained, and the schema fully documents inputs. Combined with the description's scope limits, usage trigger, and input policy, an agent has everything needed to invoke it correctly.

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 documents all 8 parameters, including fee percentages, defaults, and 'never infer a risk preference'. The description mainly restates those same facts ('direction is derived', 'do not invent' risk), adding little semantics beyond the structured fields, so 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?

States a specific verb and resource: computing position quantity and notional for a linear futures trade from balance, risk %, entry and stop. The trigger 'how much to buy or sell for a specified risk budget' is clear. However, it never names or contrasts with the sibling calculate_net_risk_reward, and it advertises a 'net R' output that could be conflated with that sibling.

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 when ('asked how much to buy or sell for a specified risk budget') and an explicit when-not list (no liquidation, leverage, inverse contracts, lot rounding, signals, order execution). It also directs the agent to ask for missing inputs rather than infer them. Alternatives are not routed to explicitly, so sibling differentiation is missing.

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