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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the description is free to add modeling semantics — and it does, disclosing the constant-rate assumption and the direction of funding flow. What it does not disclose is whether fees are charged per side or round trip, or how break-even is derived.

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?

Three short, front-loaded fragments with no filler; the funding-direction rule and the scenario caveat appear immediately. The telegraphic style is efficient but borders on cryptic.

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?

With no output schema the description at least hints at returns (net carry, linear break-even), but it never states units or shape, and 'linear break-even' is unexplained. Combined with four undocumented inputs, an agent can call it but cannot fully predict or interpret the result.

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 only 20%, so the description has to carry the load for four of five parameters, and it does not. notional_usd, side, settlements and round_trip_fee_bps are left undefined in both places, and the one helpful clarification (positive rate means longs pay shorts) merely restates the schema description.

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?

Names a specific computation (perpetual funding/fees, net carry, break-even) over explicit inputs (notional, side, rate, settlements). It is clearly distinct from siblings like exit_cost or crypto_exit_check, though it never names an alternative 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?

"Constant-rate scenario, not forecast" gives one real usage boundary — this is an approximation, not a projection. Beyond that, there is no stated when-to-use/when-not relative to siblings such as crypto_exit_check or exit_cost, so the agent must infer.

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