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

Annotations already declare this a read-only, non-destructive, closed-world computation, so the bar is lower. The description does add behavioral substance — how received funding is split by reinvestPct, that paid funding drains capital in full, and that capital floors at 0 — but says nothing about error conditions, invalid-rate handling, or performance/limits.

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-loads the core purpose in the first clause, then the trigger examples, then mechanics. The trailing return-field list is dense but arguably earns its place given there is no output schema; still, it reads as a bolted-on enumeration rather than integrated prose.

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 usefully enumerates the returned fields (finalCapital, totalEarnedPct, annualizedAPY, snapshots, etc.), which an agent otherwise couldn't know. What's missing is treatment of negative/zero funding edge cases beyond the capital floor and any note on unit assumptions across intervalHours choices.

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 all five parameters are already documented in the schema, establishing a baseline of 3. The description reinforces reinvestPct semantics (the non-reinvested portion is withdrawn but counts as earned) and the compounding-vs-non-compounding distinction, but adds only marginal meaning over the schema.

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 verb-and-resource combination — projecting capital growth from compounding funding income — which is more precise than the sibling funding tools. However, it never explicitly contrasts itself with close siblings like run_funding_breakeven, run_funding_cost, or run_carry_trade, so an agent must infer the distinction from the mechanics alone.

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?

Provides concrete trigger phrasing ('how much will I make compounding 0.01% funding for 90 days?', 'what's my APY on this carry position?'), which gives the agent clear use-case signals. It stops short of stating when NOT to use it or naming an alternative tool for adjacent questions (e.g., single-period funding cost), so it falls 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.