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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: voice selection costs, that Gemini is the default and included with Pro, that grok and claude are metered second voices, and that second voices remain metered even for Pro. 'Read-only public chain data; informational only' reinforces the annotation profile without contradicting it.

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 appropriately sized and front-loaded: it opens with the core report contents, then covers voice/cost details, then the recommended usage trigger. Sentences are information-dense with little waste. The closing 'Read-only public chain data; informational only' is slightly redundant with the annotations but does not hurt clarity.

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 read-only, parameter-light tool with no output schema, the description covers the essentials: what the report contains, which address format is expected, voice choices and costs, and when to call it relative to sibling tools. It does not describe output shape or error behavior, but the listed report contents and read-only nature make the callable contract sufficiently complete.

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 for this dimension is 3. The description adds real meaning to the voice parameter by explaining the default (gemini), pricing, and stylistic differences between voice options ('crypto tape take' vs 'TradFi desk memo'), which the enum alone does not convey. It also clarifies that address is a public Hyperliquid wallet address, consistent with the schema pattern.

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 clear, specific deliverable: a 'risk and track-record report for one public Hyperliquid wallet' with an explicit content list (equity, positions, leverage, liquidation distance, realised history, plain-English read). It distinguishes itself from sibling tools by targeting a single wallet and explicitly positioning itself after tape_leaderboard or tape_whale_prints, which are broader discovery 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 a concrete trigger: 'Use after tape_leaderboard or tape_whale_prints hands you an address.' This provides clear context on when to invoke the tool. It does not explicitly state when not to use it or name alternative tools, though the sibling list and the address handoff framing make the intended workflow reasonably clear.

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