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

Annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds substantial behavioral detail beyond annotations: ordinary tokens are a fast stored-history read, native and wrapped coins use a slower coarser portfolio scan, and timing can be tens of seconds.

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?

The description is dense but well-structured: it starts with the core endpoint result, then explains the native/wrapped exception, parameter identification, range semantics, and performance. Every sentence carries useful information for correctly invoking this relatively complex tool.

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?

Given five parameters, low schema description coverage, and an output schema, the description covers the missing invocation context thoroughly. It explains how to identify the holding, chain/token edge cases, time ranges, performance differences, and even return-value semantics where they differ by token type.

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 only 20%, but the description compensates by explaining address as the wallet, chain as a numeric EVM chain id or sui_mainnet, symbol as token symbol, and token as contract address with special native-coin and Sui rules. It also explains range as 24h with 13 two-hour points or 7d with 15 twelve-hour points.

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 states a specific metric and scope: how the USD value of one wallet token changed over 24h or 7d, with hourly points valued at each instant's price. It also distinguishes ordinary tokens from native/wrapped coins and tells the agent this is for one holding at a time, which is enough to separate it from sibling balance and price tools.

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 description gives clear usage context: identify the holding from a get_wallet_balances row, use it for one holding at a time, omit token for an EVM native coin, and require token on Sui. It does not explicitly name when to prefer siblings such as get_token_history_price, so it falls short of full when/when-not routing guidance.

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