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

With no annotations, the description carries the full behavioral burden. It does useful work by disclosing the default exclusion of stopped strategies and the fields surfaced per strategy, but it says nothing about read-only safety, pagination/result size, or auth scope.

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?

Two sentences, zero filler: the returned-field list comes first and the filtering caveat second. Nothing is repeated or padded.

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?

No output schema exists, so enumerating return fields in the description is necessary and done well; the tool is simple with two optional params. Only pagination and volume expectations are left unaddressed.

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 100%, so the baseline is 3. The description restates includeStopped's effect slightly more explicitly than the schema (hidden by default), but adds no meaning for walletId beyond the schema's "only this hyperliquid-mainnet wallet".

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 gives a specific verb and resource ("List strategies running on your Hyperliquid accounts") and narrows scope with "(presets and copy trades)", then enumerates the returned fields. It implicitly separates itself from list_strategy_presets (templates) and get_strategy (single), but never names those siblings outright.

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?

The only usage rule is the filtering default: stopped strategies are hidden unless includeStopped is true. There is no guidance on when to call this versus get_strategy or list_strategy_presets, and no prerequisites or exclusions are stated, leaving the choice to inference.

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