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

Annotations already cover readOnly/idempotent/destructive, and the description adds real behavioral context: providers are resolved dynamically from the PoolAddressesProvider, and the tool reports nothing if that no longer points at the expected Pool (a silent-empty failure mode). It also discloses the MUTEXA_ETH_RPC configuration requirement, though it does not say which block is used when none is supplied.

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 compact sentences, front-loaded with what is returned, then the resolution/failure semantics, then the credential requirement. Every clause carries information.

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 exists, and the description compensates by enumerating the returned fields plus the empty-result condition and the RPC env var. Minor gaps: no mention of the optional symbol filter or how the block is chosen, and no note on result size or per-reserve keying.

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% and the single optional 'symbols' filter is documented there, so baseline is 3. The description's phrasing 'every ... reserve' does not mention that results can be narrowed by symbol, leaving a small gap between prose and 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 ('Risk parameters of every Aave V3 Ethereum reserve at one block') and enumerates the exact fields returned (max LTV, liquidation threshold, bonus, flags, frozen/paused, oracle price). This is unmistakably distinct from the Hyperliquid/planning siblings.

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 only implied by 'at one block' and 'every reserve' — the agent can infer this is a bulk snapshot read. There is no explicit when-to-use/when-not guidance or naming of an alternative (e.g., a single-reserve lookup or price tool) that would be preferred for other cases.

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?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower; the description still adds that results are live and sorted by 24h volume, which tells the agent how to interpret ordering and freshness of the returned list. It omits rate-limit or pagination behavior beyond the schema's limit cap.

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 ordering. The long field enumeration is dense but justified since there is no output schema; nothing is redundant, though the field list pushes the single sentence to its limit.

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 no output schema, enumerating returned fields (price, change, volume, OI, funding, tiers) is the right call and makes the tool callable as-is. Minor gap: it doesn't say whether limit is ignored when coins is supplied, or what happens for unknown coin names.

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% — both params are documented with examples and a default of 20 — so the baseline is 3. The description only restates the filter-vs-limit dichotomy without adding format, precedence, or truncation semantics 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 resource (Hyperliquid perp markets) with a specific verb/behavior (sorts by 24h volume) and enumerates exactly what data comes back. The resource is clearly distinct from siblings like hl_positions or liquidation_map, so an agent can select it without ambiguity.

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?

"Filter by coins or take the top N" names the two invocation modes but gives no guidance on when to choose one over the other, when to use this vs. a sibling such as hl_positions, or what happens when both parameters are supplied. Usage is implied rather than directed.

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?

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower; the description still adds real domain nuance — the Hyperliquid-reported liq price is returned alongside a locally computed one, and computedLiq is null for cross-margin because margin depends on the whole account. That explains an otherwise confusing null and is genuine added context.

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 starting with the resource and scope, then the returned fields. It is dense but every clause carries information; it could be split into two sentences for readability 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?

No output schema exists, and the description compensates by listing the returned fields (side, size, entry, mark, value, leverage, margin mode, margin, uPnL, liq prices). Empty-position behavior and any limit on position count are the only gaps for a single-address read tool.

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?

One parameter with 100% schema coverage, where the schema already documents the 0x… 42-character format, so baseline 3 applies. The description only adds that the address must be 'public', a marginal note 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+resource ('Open perp positions of ... address') and enumerates the exact fields returned, which is far beyond a tautology. It doesn't reference a sibling tool by name, so the agent must infer that this reads positions while liq_price/liquidation_map serve other purposes.

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?

'of any public Hyperliquid address' implies an unauthenticated lookup for a single account, but there is no explicit when-to-use clause, no exclusions, and no pointer to the close siblings (liq_price, liquidation_map). Usage is inferable rather than stated.

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?

Annotations already declare read-only, idempotent, non-destructive, non-open-world behavior. The description adds meaningful context that the score is a heuristic rather than a statistical guarantee and that output includes contributing factors and suggested fixes.

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-loads the score, range, and output content before the caveat. It is appropriately compact, though the long factor list makes the single sentence dense.

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 no output schema, the description explains the score range, contributing factors, suggested fixes, and the non-guarantee caveat. The input schema fully covers parameter semantics, so the remaining gap is mainly exact output formatting.

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 are already documented. The description reinforces their meaning as risk factors, including slices above the alert threshold, but does not add syntax or format details 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 computed metric, its 0-100 direction, and the factors it evaluates. It is clearly distinct from the market, position, and planning siblings without needing to name them.

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?

Implies the tool is used to assess how linkable a set of slices is, but it gives no explicit when-to-use, when-not-to-use, or alternative tool guidance. The heuristic caveat adds context but not usage 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?

Annotations already cover read-only, idempotent, non-destructive, open-world, so the bar is lower; the description still adds real value by disclosing that 'coin' triggers a live margin-tier fetch, that only fresh isolated perps are modeled, and that Aave inputs are restricted to standard mode single-collateral/single-debt. Those are genuine modeling limits an agent needs before trusting the output.

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?

Every clause carries information and the purpose leads the sentence. The trade-off is a single very long nested-parenthetical sentence that is harder to scan than a short bulleted split by kind would be.

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 an 11-parameter, two-mode calculator with no output schema, the description covers both modes' required inputs and where live data comes from, which is what an agent needs to select and invoke correctly. The return value is unambiguous from the title 'Liquidation price'.

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 91%, so the baseline is 3; the description earns a bump by grouping parameters by 'kind' (perp vs loan) and spelling out the coin-or-maxLeverage either/or, a mutual exclusivity the schema itself does not encode via oneOf. It does not explain units beyond the schema's own text or what happens if both are supplied.

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 opens with a specific computed quantity (liquidation price) and precisely names both supported model types, enumerating the inputs each expects. An agent can tell this is a calculator, not a position/loan viewer, but no sibling (e.g. liquidation_map, plan_ladder, plan_loans) is named as the alternative or contrast.

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 rather than stated: 'fresh isolated' position and 'single-collateral, single-debt ... standard mode' loan scope out the cases this handles, which hints at when to reach for it. But there is no explicit when-to-use statement, no exclusions (e.g. cross margin, e-mode, multi-collateral), and no routing to liquidation_map or plan_ladder.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the description adds real behavioral context: the data comes from an undocumented file the web app loads rather than an official API, sampling is capped at 100 accounts, and longs bucket below the mark while shorts bucket above. It also gives the reconciliation invariant (in range + outside + no liquidation price = total) so results can be sanity-checked. It omits failure modes and latency, keeping it at 4.

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 the core purpose and no filler. The dense 'in range + outside + no liquidation price = total' phrasing takes a re-read, and the data-source caveat sits slightly awkwardly at the end, 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 derived analytics call with no output schema, the description covers provenance, the sampling cap, bucket geometry, and a totals invariant, which is enough to call and interpret it. It does not describe the response structure in detail or what happens for an unknown coin, leaving a small gap.

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 goes further by clarifying that 'top' is a sample of the ranking, that 'rank' means 30-day volume or account value, and that the buckets run around the mark with longs below and shorts above. That adds interpretation the schema alone does not convey.

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 outcome: it ranks the Hyperliquid leaderboard by 30-day volume or account value, reads public positions of the top accounts, and buckets notional by liquidation price around the mark. That is a concrete verb-plus-resource definition an agent can match to a request. It does not name a sibling (e.g. liq_price) to distinguish itself, so it stops short of 5.

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 rather than stated: the description makes clear you'd call it to see liquidation clustering for one coin, and the 'at most 100' cap is disclosed. But there is no explicit when-not guidance and no routing to alternatives such as liq_price or hl_positions for single-account lookups.

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?

Annotations already establish read-only, idempotent, open-world, non-destructive behavior. The description adds useful context beyond them: it uses the market's live margin tiers and mark, and optionally previews costs when feeRate and accountCost are supplied.

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 compact and front-loaded: it defines the core behavior first, then explains placement, sizing alternatives, and optional cost preview. The sentences are dense but each contributes relevant information.

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 complex 13-parameter planning tool with no output schema, the description explains inputs and live-data behavior but does not say what the result contains, such as returned slice sizes, liquidation prices, or cost preview structure. That leaves a meaningful gap for correct invocation interpretation.

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 high at 92%, so the baseline would be 3. The description still adds meaningful semantics by explaining placement modes, alertThreshold-based slice sizing, and the optional cost-preview condition.

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 uses a specific verb and resource: splitting a Hyperliquid perp position into isolated slices whose liquidation prices form a band. It clearly distinguishes the tool's function from data-querying siblings like hl_markets or liq_price, though it does not explicitly name alternative 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?

It explains parameter-level choices, such as placement 'around' vs 'beyond' and using slices vs alertThreshold, which implies how to use the tool. However, it gives no explicit guidance on when to choose this tool over siblings like liquidation_map or plan_loans.

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?

Annotations already declare read-only, idempotent, non-destructive, open-world; the description adds the piece annotations cannot convey — that live mode requires the MUTEXA_ETH_RPC environment variable and fails otherwise. It also previews what the call reports (the band, extra collateral, and whether the single loan already exceeds max LTV), which reduces uncertainty about running 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?

Two sentences, no filler: the first defines the operation and output shape, the second gives the mode-selection rule and prerequisites. Mode selection is front-loaded in the second sentence where an agent will look for it before reading the schema.

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 an 11-parameter, no-output-schema tool the description covers the essentials (what it does, required inputs by mode, what it reports) but leaves the required 'placement' enum unexplained — an agent cannot know what 'around' vs 'beyond' does — and says nothing about the sibling plan_ladder's overlapping scope.

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 91%, so the baseline would be 3; the description earns above that by grouping parameters into mutually exclusive modes (live-reserve vs offline), which the flat schema cannot express. The gap is the required placement enum (around/beyond), which is left entirely undefined in both schema and description, and seed/sizeJitter are likewise only schema-documented.

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 concrete transformation on a specific resource: splitting one Aave V3 loan (one collateral, one debt, standard mode) into staggered-LTV loans whose liquidation prices form a band. That is far more than a restatement of the name. It does not, however, distinguish itself from the sibling plan_ladder, which the title ('Plan a loan ladder') makes easy to confuse with this 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?

Explicitly splits usage into two modes and names the parameters that select each: collateralSymbol for live reserve data (with the MUTEXA_ETH_RPC prerequisite called out) versus ltv/liqThreshold/priceUsd for offline planning. No guidance is given on when to prefer this tool over the sibling plan_ladder or liquidation_map, so it falls short of a 5.

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?

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: positions are sorted by closest liquidation, an alert threshold produces flags, and replan projects slices beyond today's liquidation price — the 'same JSON as the tracker-view CLI' line usefully signals output stability. It does not mention rate limits or failure modes for an invalid/empty address.

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 leads with the core deliverable and then enumerates the fields, with the optional replan behavior placed last where it belongs. The parenthetical field list is dense but each item is informative; no sentence is 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?

There is no output schema, so the description must carry the return shape — and it does, naming the fields and ordering of positions plus the flag and replan additions. What remains uncovered is minor: whether spot and perp positions are both included, how 'distance' is expressed, and behavior when the address has no positions.

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 all three parameters are already documented with patterns and units, making 3 the baseline. The description does add a little for replan ('isolated slices placed beyond today's liquidation price'), clarifying what 'band of slices' means, but it does not clarify that threshold is a USD value, which the schema states but the description only loosely echoes as 'above your alert threshold'.

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?

It names a specific resource (a Hyperliquid address's open positions) and enumerates exactly what is returned — side, size, value, leverage, entry/mark/liq price, distance, uPnL — plus flagging and optional re-planning. The purpose is unmistakable. It stops short of a 5 because it never distinguishes itself from close siblings like hl_positions or liquidation_map, which plausibly return overlapping position/liquidation 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?

Usage is only implied: 'what public trackers see' and the optional replan flag suggest a monitoring/triage use case, and the required threshold implies it is meant for alert-style screening. There is no explicit when-to-use versus hl_positions, liquidation_map, or liq_price, and no statement of when the replan variant should be chosen over plan_ladder.

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