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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine context beyond that: the sign convention ('positive amounts go into the account') and a retention cutoff for two event classes, which tells the agent the results may be incomplete for a time range. It still omits ordering and what happens when the window exceeds the cap, but it clears the lower bar set by annotations.

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 short sentences, zero filler, and the resource identification is front-loaded followed by the two caveats that matter most. The first sentence is a verbless fragment, which slightly blunts the opening, but nothing is padded or repeated.

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?

The tool is read-only with a fully described input schema and an output schema, so the description need not explain return shapes. What it must add – what the ledger contains, how to read the amounts, and where the data is truncated – is present. Ordering of entries and any implication of the limit cap are the only notable omissions, and those are minor given the rich schema.

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% – every parameter, including the event_types enum values and the timestamp formats, is already documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies. The one extra hint is implicit: the mention of deposits/withdrawals/transfers hints at the event_types space already spelled out in 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?

The description names the specific resource (a Hyperliquid wallet's vault deposits, withdrawals and transfers) with the sign convention, so an agent knows what data comes back. It does not differentiate from close siblings such as get_vault_operations or get_user_state, which also sound ledger-like, so an agent still has to infer whether this is the right tool for plain account cash flows.

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?

There is no explicit when-to-use or when-not-to-use statement and no sibling is named as an alternative. The one usage-relevant constraint given is a data-coverage caveat (account deposits and withdrawals only recorded up to 2026-06-06), which helps an agent decide whether the tool can answer a recent-activity question, but alternatives for that case are left unnamed.

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