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

With no annotations, the description carries the full behavioral burden. It strongly signals a read-only, non-mutating operation via 'Read' and discloses a meaningful ownership/authorization boundary (address is always the bound wallet, never a supplied one). It omits rate limits, data freshness, and any note on large result sets from fills/portfolio history.

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 resource and the returned data types, followed by the scope constraint. No filler and nothing buried.

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 single-enum, read-only tool with no output schema and no annotations, the description covers what to query and the ownership scope. It stops short of describing return shape or pagination behavior for potentially large reads like userFills and portfolio, which the missing output schema leaves unaddressed.

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 baseline is 3, but the description goes further by translating the enum values into user intent: perp positions/margin, spot balances, open orders, recent fills, portfolio history. Only 'userFees' lacks a plain-language mapping, so the mapping is strong but not exhaustive.

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 specific verb (Read) and resource (this agent's own Hyperliquid account) and enumerates the concrete data types retrievable: perp positions/margin, spot balances, open orders, fills, portfolio history. It implicitly separates itself from hl_market_data (account vs market), but offers no differentiation from the sibling hl_account_status, which is the closest competing tool.

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?

Clear context for when to reach for it (fetching the agent's own account reads) and an explicit when-not constraint: 'it cannot be pointed at another account.' No guidance is given on when to prefer hl_account_status over this tool, so the alternative-selection surface is incomplete.

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

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

With no annotations, the description carries the full burden and does most of it: it enumerates the four readiness signals returned, effectively substituting for a missing output schema, and frames the tool as a diagnostic read. It stops short of stating permissions, auth prerequisites, or that it has no side effects.

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, both earning their place. The returned signals are front-loaded, and the second sentence adds the usage rationale without padding.

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?

No parameters, no annotations, and no output schema, so the description must convey both scope and return content, which it does by listing the four checks. An agent has everything needed to call it correctly and interpret the result.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the lack of input is appropriate for a self-account status check. Baseline 4 applies.

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 specific resource (this agent's own account) and enumerates exactly what is checked: Hyperliquid enabled, Trading Key present, approval still honoured, approval expiry. The 'own account' scoping cleanly separates it from siblings like hl_account or hl_market_data.

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 an explicit condition for use: call it to explain WHY an order might be refused rather than waiting for the refusal. It does not name a sibling as the alternative or state when not to use it, but the intended context is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds the useful constraint that the target must be a resting (open) order, but says nothing about required permissions, irreversibility, what happens to partially filled orders, or what the call returns on success/failure.

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?

A single sentence with the action front-loaded and zero filler; the descriptive clause about oid source earns its place by resolving the required input.

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 simple two-parameter cancel tool with fully documented schema and no output schema, the description supplies what an agent needs to call it: the action, its single-order scope, and the source of the oid. Only the mutation's side effects and failure behavior are left unaddressed.

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 both parameters are already documented in the schema, and the annotation-free description adds only the provenance of oid (openOrders) on top of that. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb (cancel) and resource (one resting order), plus scopes it to a single order rather than a bulk operation, which cleanly separates it from hl_place_order. The reference to the oid's origin further pins down exactly what entity it operates on.

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 tells the agent where the required oid comes from (hl_account with kind=openOrders), which is real usage guidance for invoking it correctly. It stops short of naming when not to use it or any alternative route, so it is clear context rather than full when/when-not guidance.

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

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

With no annotations, the description carries the full burden and does disclose two meaningful traits: read-only nature and no auth/signing required. However, it says nothing about rate limits, pagination, defaults, or the shape of the returned data, so behavioral coverage is partial.

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?

A single front-loaded sentence lists the reads, and the trailing clause captures the read-only constraint. Every phrase earns its place with no filler.

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, no-output-schema tool the description covers the essential kinds and the safety profile, which is enough to invoke it correctly. Minor gaps remain around return format and per-kind parameter defaults, but these are lower-stakes here.

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 100%, so every parameter (coin, kind, startTime, endTime, interval) is already documented in the schema. The description's data-kind enumeration loosely maps to the `kind` enum but adds no syntax or format detail beyond what the schema provides — the baseline 3 for high coverage.

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 specific verb ("Read") plus resource ("Hyperliquid market data") and enumerates the concrete reads available: mid prices, order book, candles, perp metadata. This clearly distinguishes it from the account/trading siblings (hl_place_order, hl_account, hl_transfer), which an agent can tell apart at a glance.

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?

"No account access, no signing" establishes a scope boundary that separates this from account and order tools, so the agent knows this is the read-only market surface. It stops short of naming explicit alternatives (e.g. "use hl_account for balances"), so it's clear context rather than full when/when-not routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the owner-set constraint regime (per-order and daily notional caps, max leverage, allowlist) and the exact failure semantics (403 + cap_* code, no retry). It omits auth requirements and what a successful response contains, keeping it short of 5.

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, all load-bearing: the core action, the constraint/failure behavior, and the market-order workaround. Front-loaded with no filler.

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 write tool with no annotations and no output schema, it covers the critical traps (limits, error code, no-retry, no market orders). The main remaining gap is the success response shape and any auth prerequisite, which the agent would have to discover empirically.

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 100%, so all six parameters including the tif enum and reduceOnly are already documented inline. The description adds only the conceptual point that an aggressive px crosses the spread, which is marginal beyond the schema baseline of 3.

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?

Opens with a specific verb+resource ('Place a limit order on Hyperliquid') and implicitly distinguishes itself from siblings like hl_cancel_order and hl_swap. An agent immediately knows this is the order-entry tool.

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 strong operational guidance: exceeding owner limits returns 403 with a cap_* code and must not be retried, and it explains how to emulate a market order since none exists. It does not explicitly route to sibling tools, but the when/when-not for this tool is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses the owner-set maximum constraint, the specific 403 leverage_exceeded failure mode, and the consequence that raising leverage increases liquidation risk on open positions. It stops short of stating auth requirements or whether existing positions are immediately re-margined.

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 short sentences, front-loaded with purpose, then constraint/error, then risk. Every sentence carries distinct information and there is no padding or redundancy.

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 mutation tool with no annotations and no output schema, the description supplies the key risk and error context an agent needs. It leaves minor gaps around authentication/prerequisites and the effect on already-open positions, but the core contract is covered.

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 100%, so the schema already documents coin, isCross, and leverage, making 3 the baseline. The description adds only indirect meaning ('for one asset', 'higher value' raising liquidation risk) and does not explain the cross/isolated choice or valid leverage granularity beyond 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?

States a specific verb and resource ('Set leverage for one asset'), which is unambiguous against siblings like hl_place_order or hl_cancel_order that operate on orders rather than leverage settings. It never explicitly contrasts itself with a sibling, so it falls short of the top tier, but no sibling overlaps this resource.

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?

'Bounded by the owner-set maximum; a higher value returns 403 leverage_exceeded' gives a precondition and failure boundary, which implies usable ranges. However, there is no guidance on when to call this versus hl_place_order, whether leverage can be changed while a position is open, or whether it applies per-asset or per-symbol pair.

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

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

With no annotations present, the description carries the full burden and does so: it discloses the 0.99 USDC price floor and the all-or-nothing-per-coin behavior at that floor, partial fills, the fact that the sold amount (not the requested amount) is what gets charged against the owner daily limit, and the effective $10 exchange minimum. It also names the return fields (soldSz, usdcReceived) despite there being no output schema.

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?

Front-loaded with the core conversion and only slightly bloated by em-dash asides; every clause (coins allowed, floor, partial fills, limit charging) carries operative information rather than filler. Denser than ideal, but nothing is wasted.

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 two-parameter mutation with no annotations and no output schema, the description supplies everything an agent needs: allowed inputs, target asset, price floor, minimum size, partial-fill handling, and which fields to read back. No material gap remains.

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 enum and amount semantics are already documented and the baseline is 3. The description adds real meaning beyond the schema by explaining why the minimum is 11 (it reflects the exchange's $10 floor at the 0.99 price) and by tying 'amount' to the partial-fill behavior where requested vs. received can differ.

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 specific verb (convert) and resource (a stablecoin on the spot side) into a specific output (USDC) for a specific purpose (backing perp trades). It explicitly distinguishes itself from sibling operations by saying 'This is not spot trading and cannot buy any other coin,' so an agent can route between hl_swap and hl_place_order without opening a schema.

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 both when-to-use (to turn spot stablecoins into perp collateral) and hard when-not constraints: only USDH/USDT0/USDE, only into USDC, never another coin, not spot trading. Alternatives are implicitly routed away from this tool and no prerequisite ambiguity remains.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the single-direction constraint, whole-dollar granularity with the dashboard's cents-as-tracking-tag quirk (which explains why slightly less than requested is sent), a one-transfer-at-a-time concurrency rule, the reconciliation path for an unresolved transfer, and the owner-set daily limit. These are non-obvious operational traits an agent could not infer from the schema.

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?

Five short sentences, zero filler, and the core action plus direction constraint are front-loaded before the operational caveats. Every sentence conveys a distinct, necessary fact.

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?

No output schema and no annotations, so the description must stand alone for a 2-parameter mutation, and it does: direction limits, amount semantics, concurrency, failure reconciliation, and the daily cap are all covered. Nothing essential for correct invocation is missing.

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 is 3. The description adds genuine meaning beyond the schema by explaining why amounts are whole dollars and why the executed amount may be lower than requested, which prevents a false 'transfer failed' conclusion. It stops short of adding new syntax or format detail.

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 specific verb, resource, and direction: 'Move USDC from the spot account into the perp account so it can back trades.' It explicitly negates the reverse direction ('perp-to-spot does not exist here, deliberately'), so an agent can distinguish it from hl_swap or hl_transfer_status without opening any schema.

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 an explicit when-to-use rationale (to back trades), an explicit exclusion (no perp-to-spot), a routing rule to a named sibling ('reconcile with hl_transfer_status before retrying'), and a constraint (daily limit). This is the full when/when-not/alternative triad.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the three possible outcomes (landed, pending with retry eligibility, blocked requiring an owner to clear a double-land), which is a real business rule not derivable from any structured field. It stops short of stating read-only nature explicitly or any auth/rate-limit constraints.

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?

A single sentence, front-loaded with the verb and resource, then the outcome enumeration in a compact parenthetical. Every clause earns its place; nothing is padded.

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?

With zero parameters and no output schema, the description usefully compensates by describing the returned states themselves. It is nearly complete for a status tool, missing only explicit read-only framing and any mention of what is needed to identify the transfer.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies the account scope is implicit rather than passed as an argument, and adds no misleading parameter expectations.

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 specific verb and resource: it reconciles/reports the status of the account's in-flight transfer against the exchange ledger, and enumerates the three result states. It is clearly distinguishable from siblings like hl_transfer (initiates) and hl_account_status (broader account state), though it does not name any sibling explicitly.

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?

Usage is implied: 'in-flight transfer' and 'reconcile' signal this is a post-transfer verification call, most naturally after hl_transfer. However, there is no explicit when-to-use/when-not statement, no mention of the alternative (hl_account_status) and no statement of prerequisites or ordering.

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