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

With no annotations supplied, the description carries the full burden and does well: it discloses that the output is unsigned and short-expiry, that no sign/submit side effects occur, and that bounded validation gates (lot/tick, impact, mark-oracle) must all pass. It stops short of describing what happens when a gate fails (error shape) or any permission/auth requirements, so it is strong but not exhaustive.

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?

Three sentences, front-loaded with purpose and immediately followed by the usage boundary and the return contract. The long middle sentence is dense but each clause (preconditions, three named gate types) earns its place; no redundant restatement of the tool name.

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 complex (13 params, 10 required, nested builder_fee object, no annotations, no output schema), and the description covers the return payload in one line. However, it omits gate-failure behavior, defaults for optional params like expires_after_seconds and require_full_fill, and any explanation of the notional/impact cap semantics that an agent must set correctly.

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 23% across 13 parameters, so the description must compensate and largely does not. It names market, side, size, and limit price and gestures at impact and mark-oracle thresholds, but leaves max_notional_usd, reduce_only, require_full_fill, client_order_id, expires_after_seconds, and builder_fee with no added meaning, defaults, or interaction rules.

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 plus a precisely scoped resource: an 'unsigned Hyperliquid BTC/ETH/HYPE perpetual IOC order envelope for local wallet signing'. Venue, instrument set, order type, and the non-signing boundary are all stated, which cleanly separates it from siblings like prepare_swap and issue_execution_receipt.

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?

It states the exact precondition for use ('when an agent has decided on market, side, size and limit price and needs reviewed lot/tick, impact and mark-oracle checks') and explicitly excludes three adjacent actions: nonce creation, signing, and submission. Nothing about when to call or when not to call is left to inference.

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