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 disclose a meaningful behavioral fact — that the move happens without HyperEVM — and constrains source/destination desk types. But it omits that this is a propose-only action requiring subsequent approval, any fee/limit behavior, and what happens on an invalid dex id.

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, front-loaded with the core action and the key constraint, and the second sentence is a directly actionable lookup hint. The parenthetical dex enumeration ('xyz, io, para, mkts, …') is slightly noisy but reinforces the open-ended dex namespace efficiently.

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?

For a 4-required-parameter mutation with no annotations and no output schema, the description covers the domain model (desks, no-HyperEVM) but stops short of the approval/execution lifecycle an agent needs to sequence correctly. It is adequate to construct a call, not fully adequate to predict its consequences.

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 50%: sourceDex and destinationDex are documented in the schema itself, while walletId and amountUsd are bare strings with no clarification anywhere. The description's pointer to perpDesks[].dex is useful provenance for the dex parameters, but it adds nothing about walletId or the string-typed USD amount format.

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 concrete verb+resource: move USDC between Hyperliquid margin desks, and adds scope details (any perp book, spot → any perp desk, no HyperEVM) that pin down exactly what it does. It does not, however, distinguish itself from the sibling propose_hyperliquid_spot_to_perp, whose name suggests overlapping spot-to-perp movement.

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 one useful routing hint — use list_hyperliquid_balances perpDesks[].dex to get valid dex ids — which is real when-to-use guidance. It says nothing about when to prefer this over propose_hyperliquid_spot_to_perp, propose_hyperliquid_deposit, or propose_hyperliquid_withdraw, and no prerequisites or exclusions are stated.

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