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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond those annotations: the default time window, why it is narrow (high fill volume), and accepted since/until formats. It does not discuss pagination behavior, but the limit parameter is documented in 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?

Two sentences, front-loaded with what the tool returns and scoped by builder address, followed by practical time-window guidance. No filler or repetition.

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 still names the returned metrics (volume, builder fees, unique traders, top coins). It covers the key required parameter and the time-format semantics, making it complete enough for an agent to invoke 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 coverage is 75%, with builder and limit well documented. The description adds meaning for since/until by listing accepted Relative, date, date-time, 'now', and Unix ms formats, plus the default 1h window. It does not add much for limit, but the schema already covers that parameter.

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: retrieves fills routed through a builder by builder address, with named metrics (volume, builder fees, unique traders, top coins). It implicitly distinguishes itself from the many wallet-oriented siblings by operating on a builder/app address rather than a user wallet.

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 clear operational context: default window is last 1h because busy builders produce thousands of fills, and it explains accepted time formats. It does not explicitly name when to prefer a sibling, but the builder-address scope makes the intended use 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?

Annotations already establish read-only and open-world behavior. The description adds useful behavioral detail: wallet caps, the lower cap when includeHip3=true, sorting by balance, and handling of unified-account and portfolio-margin wallets whose funds sit in spot rather than perps.

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 front-loaded with the core lookup behavior, then follows with limits and account-type handling, then concrete watchlist examples. Every sentence adds practical selection or usage value.

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 three-parameter batch read tool with no output schema, the description covers what is returned, the batch size limits, sorting, and important account-type behavior. This is sufficient for an agent to choose and call it 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 100%, so parameter meanings are already documented. The description reinforces includeHip3's effect on the wallet cap but does not add meaning beyond the schema or explain minBalanceUsd semantics in its own text.

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 specific verb and resource: looking up balance, account mode, and open positions for many wallets. It clearly distinguishes this batch operation from sibling wallet-singular tools through the 1,000-wallet limit and watchlist framing.

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 gives clear usage context with watchlist examples such as finding whales or checking what 50 traders hold. It does not explicitly name alternatives like hydromancer_wallet_overview for single-wallet queries, so it stops short of 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?

Annotations already cover read-only and open-world safety, so the description's job is added context — and it delivers: fixed hourly granularity, the meaning of the sign, and the returned aggregates (average, annualized). It stops short of mentioning result limits, pagination, or maximum window length.

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 compact sentences with the core purpose front-loaded, followed by the sign convention and the default window. No filler or repetition.

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 does a reasonable job naming the returned aggregates, and it covers granularity and the default range. Gaps remain around the `until` parameter and any cap on window size, which an agent would need before calling with arbitrary ranges.

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 67%: coin is fully documented in the schema and the description adds nothing to it, while `since` gets only a restated default ('7d') shared by both sources and `until` is undocumented in both. The description does not clarify the accepted string/number forms for the time parameters.

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 specific resource and metric: hourly funding rates for a market, plus the average and annualized rate. It implicitly separates itself from the wallet-scoped sibling hydromancer_wallet_funding by specifying 'for a market,' though it never names that sibling, so the distinction requires the agent to infer it.

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 provides the interpretation rule ('positive funding means longs pay shorts') and the default window, which orients usage. But it never says when to pick this over hydromancer_wallet_funding or hydromancer_price_history, and gives no exclusions or prerequisites.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine scope context (~the result set includes HIP-3 perp DEXes, not just standard perps), but says nothing about result size, truncation, or pagination behavior beyond what the schema's limit field implies.

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 core purpose and scope, with the usage cue at the end. Minimal waste, though the parenthetical category list duplicates the enum without adding value.

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 carries the burden of explaining what comes back. It names the two entity types returned but not the identifying fields (ticker, market id, category) an agent needs to chain into snapshot or history tools, leaving a meaningful gap for a discovery 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?

Schema coverage is 67%: limit and search are documented with defaults and examples in the schema, while category is a bare enum. The description merely echoes the enum values ('crypto, stocks, indices, commodities, fx') without adding meaning such as matching semantics or case sensitivity, so it stays at the baseline.

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 ('lists every tradable perp market') plus the extra HIP-3 exchange coverage, which is more than a restatement of the name. It does not explicitly contrast with the closest sibling, hydromancer_market_snapshot, so an agent must infer that this is the enumeration tool rather than a single-market lookup.

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?

'Use when unsure of a market's exact name' gives a clear selection context: it is the discovery step before calling a market-specific tool. There is no explicit when-not or a named alternative, which keeps it 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it specifies that depth is reported in USD within a 0.1% to 2% price band and that slippage is estimated over time for a given order size. It does not mention rate limits or auth, but for a read-only market-data tool this is a meaningful addition.

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 two tight sentences with no filler, and the core purpose is front-loaded before the return details. Every sentence contributes useful information about what is returned.

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 appropriately explains the return values: USD depth within a price band and expected slippage for a given order size over time. The simple three-parameter schema is well covered. It is slightly incomplete only because it lacks usage guidance and a fuller description of the return shape.

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, since, and orderSizeUsd in detail. The description loosely maps to those parameters by mentioning 'a market', 'given size', and 'over time', but it does not add syntax or default information beyond the schema. 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?

The description states a specific resource and return type: USD order book depth on each side and expected slippage for a market order. It clearly distinguishes the tool conceptually from sibling tools like market_snapshot or price_history by focusing on liquidity depth and slippage. It does not explicitly name a sibling, so it stops short of a 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?

The description explains what the tool returns but gives no explicit guidance on when to use it versus alternatives such as market_snapshot or price_history. There are no exclusions, prerequisites, or named alternatives. Usage must be inferred from the purpose statement alone.

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 readOnlyHint and openWorldHint, so safety is covered; the description adds the concrete return payload (mark/oracle/mid price, volume, OI in coins and USD) and notes that the top-markets list additionally includes max leverage. No rate-limit or pagination context, but for a read-only snapshot tool this is solid added value.

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?

Four short sentences, front-loaded with the returned data then the usage rule and the edge-case market type. No filler or restatement of the title.

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 only two optional parameters, full schema coverage, and no output schema, the description carries the return-value burden itself and does so explicitly (fields plus units plus the leverage extra). Nothing an agent needs to call it correctly 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 description coverage is 100%, so the schema already documents both 'top' (default 15, max 100) and 'coins' (max 20). The description adds only the HIP-3 naming convention ("xyz:TSLA"), which the schema's own example already shows, so it sits at the baseline.

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-less but precise operation: returns current mark/oracle/mid price, 24h volume and open interest for one or more markets. The word 'Current' implicitly separates it from hydromancer_price_history and hydromancer_open_interest_history, but no sibling is named 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?

'Leave coins empty for the top markets by 24h volume' gives clear invocation guidance for the default path, and the HIP-3 note tells the agent which market universe is supported. No explicit when-not or named alternative (e.g. use price_history for time series) is offered.

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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value beyond them by scoping the data to the caller's own account and listing the measured dimensions, though it says nothing about aggregation granularity or retention limits.

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 tight sentences: the first defines the payload and the second gives the use case. Front-loaded with content, zero 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 simple single-parameter read tool with no output schema, the description adequately conveys what comes back (the four metric families) and the account scope. It stops short of explaining per-day/per-request-type shaping details, but nothing critical to calling it 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?

Only one parameter exists and its schema description is fully documented ('Days to look back (default 7)'), including bounds. The description adds nothing about the `days` parameter, so this is the baseline 3 where the schema does all the work.

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 a specific resource ('Your own Hydromancer API usage by day and request type') and enumerates the metrics returned (requests, failures, speed, billable tokens). It is implicitly distinct from all siblings, which query market/wallet data rather than account usage, though no explicit verb or sibling comparison is offered.

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?

'Use to check how much of your plan you are using' gives a concrete trigger for calling the tool. There are no exclusions or named alternatives, but none of the sibling tools overlap with account usage, so the guidance is sufficient in context.

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 that this is a safe read-only operation, so the description carries a lower burden. It adds useful details like the default hourly granularity and 24-hour window, but does not mention limits, pagination, or data source behavior.

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, front-loaded, and every sentence contributes: the purpose, an interpretive heuristic, and the default time window. There is no filler 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 simple read-only time-series tool with a mostly described schema and no output schema, the description is nearly complete. The main remaining gap is that it does not clarify return structure or `until` semantics, but an agent can call it correctly from the provided information.

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 75%, with the coin parameter well documented and interval enum/defaults supplied. The description restates the default hourly/24h behavior but adds no clarification for the undocumented `until` parameter or timestamp formats, so it only marginally exceeds schema value.

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 clearly identifies the resource and scope: open interest history for a market, expressed in coins and USD. It does not explicitly distinguish itself from siblings such as price_history or funding_history, but the purpose is still unambiguous.

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 through the interpretive note about rising/falling open interest, suggesting positioning analysis. However, it never states when to choose this tool over alternatives like price_history or market_snapshot, nor does it give exclusions.

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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds one genuinely useful behavioral fact: only settled markets (with results) are returned, not live ones. It does not disclose return volume, ordering, or whether pagination beyond limit exists.

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 well-formed sentence with the resource and scope front-loaded and zero filler. 'HIP-4 outcomes' is mildly jargony but immediately disambiguating for a Hyperliquid-aware agent.

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 carries some return-value burden and does say results and trading stats are included, which is helpful. However, for a 4-parameter, no-required-parameter listing tool it leaves gaps: default ordering, whether filters combine, and what the result/stats fields look like.

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 four parameters are already documented in the schema. The description's 'searchable by text, underlying asset or category' reinforces the three filter axes but adds no syntax, combination, or precedence semantics. Baseline 3 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 verb-like scope (settled Hyperliquid prediction markets, HIP-4 outcomes) plus what data comes back (result and trading stats) and the searchable axes. An agent can immediately tell this apart from the wallet/market-data siblings, though it never names a 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?

There is no when-to-use / when-not-to-use guidance, no mention of prerequisites, result ordering, or when to fall back to hydromancer_raw_request for other HIP-4 queries. The 'searchable by...' clause is closest to usage help but is parameter restatement rather than situational 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description still adds real behavioral context: the default window, the granularity range supported, and the specific limitation that '1s' intervals only work over roughly the last 30 minutes. It stops short of stating result-size limits or truncation behavior.

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?

Four dense sentences with zero filler; the core purpose and OHLCV payload come first, then defaults, then the time-format grammar. Every clause earns its place and nothing is repeated from structured fields.

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, four-parameter tool with no output schema, this is close to complete: payload shape, default range, interval bounds, and time syntax are all present. The remaining gap is volume — no hint about maximum candles returned or whether long ranges get truncated or paginated.

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 schema description for 'since' is only 'Default "24h"' and 'until' is undocumented, so the description carries most of the load by enumerating accepted formats: relative ('30m', '7d'), date, date-time, 'now', or Unix ms. That is a genuine value-add beyond the schema. It does not restate the 'coin' semantics already well documented in the schema, which is appropriate.

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 verb and resource — 'Price history as candles (open, high, low, close, volume) for any market' — and unpacks the OHLCV acronym, so there is no ambiguity about the return shape. Sibling differentiation is only implicit (contrasting with hydromancer_market_snapshot or hydromancer_market_depth), since no sibling is named, which keeps it at 4.

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 useful defaults ('1h candles for the last 24h') and an important caveat that '1s' covers only about 30 minutes, which implicitly steers the agent toward valid invocations. However, it never says when to choose this over hydromancer_market_snapshot or other price-adjacent siblings, and gives no exclusions or prerequisites, leaving usage inferential.

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 readOnlyHint and openWorldHint, so the safety baseline is set. The description adds genuinely useful domain context beyond that: 'this server never places orders,' which directly addresses the main fear an agent has when hand-crafting an arbitrary request body to a trading API. It stops short of noting error behavior or that response shape varies per endpoint.

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 the escape-hatch purpose, then the call convention, then the safety guarantee. The long doc URL earns its place as the only way to enumerate valid endpoints.

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 open-world raw proxy with no output schema, the description supplies what an agent needs to act: the purpose boundary, the required body key, a doc link, and the read-only guarantee. A brief note that the response shape is determined by the requested 'type' would close the last 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% and the schema already shows example bodies and the limit bounds. The description adds value the schema does not state outright — that the body must include a 'type' key — and points to the authoritative endpoint list. It does not explain how 'limit' interacts with specific endpoints, but the schema handles the mechanics.

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 ('send any Hydromancer /info request directly') plus the exact scope boundary: endpoints the other tools do not cover. The named examples (vaultSummaries, historicalOrders, spotMeta, etc.) make it unmistakable against the 18 named siblings, which all target specific resources.

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 defines when to use it (endpoints not covered by other tools) and, by implication, when not to — an agent should reach for the dedicated sibling first. The doc URL gives the agent a way to resolve the remaining 'which endpoints exist' question.

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 that this is a read-only, open-world retrieval tool. The description adds useful behavioral context beyond the annotations: results are newest first, totals are grouped by side, and the default window is the last 24 hours.

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 three short sentences, front-loads the core behavior, and uses the remaining space only for interpretive context and the default window. Nothing is redundant or 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 invocation, the description is mostly complete because the optional parameters and default window are clear. With no output schema, however, it gives only a high-level sense of the return value and does not explain response fields or time-format expectations for since/until.

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 75%, with coin and limit well described and since partly described. The description reinforces the market-vs-whole-exchange behavior and the 24h default, but it does not clarify the until parameter or accepted time formats beyond what the schema already says.

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 specific resource (force-closed/liquidated positions), scope (one market or the whole exchange), ordering (newest first), and aggregation (totals by side). This is precise enough for an agent to distinguish it from wallet-trade and market-history siblings without opening the 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?

Usage is implied: the tool is for recent liquidations, optionally narrowed to a coin, with a default 24h window. However, the description gives no explicit when-to-use guidance, exclusions, or alternatives such as how this differs from market snapshot or raw request workflows.

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?

The annotations already disclose that this is a read-only, open-world data tool. The description adds useful context about bot and one-off-wallet filtering plus a follow-up workflow, but it does not explain data freshness, ranking methodology details, or response shape beyond the schema parameters.

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 three sentences, front-loads the core action, then provides concrete use cases and a sibling-tool pairing. No sentence is redundant, and the progression is easy for an agent to scan.

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 nine-parameter read-only leaderboard with no output schema, the description adequately covers purpose, usage, filters, and follow-up workflow. It could go further by describing the response fields or paging model, but the full schema already carries the parameter detail.

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 nine parameters are already well documented. The description reinforces the main ranking dimensions, periods, and filters, but adds little syntax or semantics beyond what the schema provides; baseline 3 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?

The description states a specific verb and resource: rank Hyperliquid traders by realized profit, win rate, or volume over selectable periods. It also distinguishes this leaderboard tool from sibling wallet-inspection tools by naming hydromancer_wallet_overview as the follow-up for holdings.

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 gives clear example use cases (“best traders this week”, “consistent winners on stocks”, “top traders using builder X”) and explicitly pairs the tool with hydromancer_wallet_overview. It does not spell out when not to use it or name a competing ranking alternative, but the intended context 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely non-obvious behavior — the default 30-day window and the full set of accepted since/until encodings. It stops short of stating truncation behavior when a wallet has more than the 500-row cap, or whether a partial/empty result is possible.

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 what a row is, then the use case, then the time-window mechanics. No filler, and the most decision-relevant fact (round-trip granularity) comes first.

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, so an agent knows what it will get. Defaults, format flexibility and the skill-evaluation use case are all present; only deep-pagination edge cases are unaddressed, which is minor for a read-only listing 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?

With 80% schema coverage the baseline is 3, and the description earns above it by documenting the accepted since/until formats (relative units, date, date-time, "now", Unix ms) — the schema only says "Start of window" and leaves until entirely undocumented. It adds nothing on coin or limit, but those are already well described 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?

States a concrete verb+resource ("Completed trades for a wallet") and immediately defines row granularity — "each row is a full position from open to close" — which is precisely what separates it from the sibling hydromancer_wallet_trades fill/trade list. The enumerated row fields (entry, exit, size, gross and net PnL, fees, funding, hold time) make the scope unambiguous without opening the 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?

It gives an explicit use case ("Best tool for judging trading skill") with a concrete example question ("what is this wallet's win rate and best coin?"), which is real routing guidance. It never names the alternative (hydromancer_wallet_trades) or states when-not to use it, so the agent must infer the boundary from the row-granularity framing.

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 this is a safe, open-world read. Beyond that, the description discloses the sign convention ('Positive = received, negative = paid') and the aggregation granularity ('hour by hour, with totals per coin') — genuinely non-obvious behavioral facts an agent would otherwise have to discover by calling the tool. It does not cover the unit of the amounts (USD notional vs token quantity) or pagination/limits, keeping it out of the top band.

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 compact sentences, front-loaded with what the tool returns before the caveats. Slight redundancy in restating the 7-day default that the schema already encodes as "7d", but 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 no output schema, the description must carry the return format, and it does partly (hourly buckets, per-coin totals, sign convention). It omits the timezone/format of the hourly timestamps and the units of the funding amounts, which an agent needs to present results 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 coverage is 67% — the address pattern and since's default are already documented in the schema. The description adds the effective default window in human terms, but does not clarify the string-vs-number duality of since/until (e.g., '7d' vs a unix timestamp) or what until defaults to, which is the single biggest ambiguity 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?

States a concrete resource and shape: funding paid/received by a wallet's open positions, bucketed hourly with per-coin totals. That is far more specific than the title. It stops short of 5 because it never distinguishes itself from the sibling hydromancer_funding_history (market-wide funding history), leaving the agent to infer the wallet-scoped vs market-scoped split from the name alone.

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?

'Default window: last 7 days' gives the agent a usable default, which is real guidance. However, there is no explicit when-to-use or when-not-to-use, and no pointer to an alternative tool for the closely related market-level funding series or for per-position detail.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope context (what counts as an open order, including trigger orders), but says nothing about pagination, ordering, empty-result behavior, or rate limits on this read.

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 tight sentences, front-loaded with the core scope. The second sentence is interpretive rather than redundant, though slightly soft ('shows where a trader plans to buy, sell or exit') compared with the precision of the first.

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, so the description is the only source of return-value context, yet it does not describe the fields an agent would get back (side, price, size, trigger type, timestamps). Adequate for selecting the tool, thin for interpreting results.

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?

Only one parameter and schema description coverage is 100%, with the address format documented in the schema itself. The description adds no parameter-level meaning, so the baseline 3 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 and scope: 'all resting orders for a wallet right now', and enumerates the order types included (stop-loss, take-profit). An agent can tell this apart from historical tools by the 'right now' framing, though no sibling is named 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 only implied by 'right now' and 'resting orders', which signals a current-state snapshot versus historical trade/order tools. It never states when to prefer it over hydromancer_wallet_trades or hydromancer_wallet_closed_trades, and offers no exclusions or prerequisites.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value beyond that: it discloses the full return surface (positions, spot balances, PnL/win-rate record) and explains the includeHip3 opt-in and its default-off behavior, which affects the result set in a non-obvious way. Missing only operational context such as invalid-address handling or rate limits.

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 capability, then the use case, then the flag. The long parenthetical field list is justified because there is no output schema, but it makes the first sentence quite dense. No filler sentences.

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 carries the burden of describing returns and does so thoroughly, including aggregate metrics like win rate and human score. Combined with annotations covering the read-only/open-world profile, an agent has what it needs to call this correctly; only edge-case behavior and response shape beyond field names are unstated.

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, making 3 the baseline. The description adds concrete meaning beyond the schema by giving an example HIP-3 ticker ('xyz:TSLA') and reinforcing that address can be 'any Hyperliquid wallet', which clarifies the domain of the pattern-constrained string.

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 verb+resource phrase ('One-call profile of any Hyperliquid wallet') and then enumerates exactly what the profile contains: account value, perp positions with side/size/entry/liquidation/leverage/uPnL, spot balances, and a realized trading record. It is clearly distinguishable from siblings like hydromancer_wallet_trades or hydromancer_wallet_open_orders, which are narrower slices of the same 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?

It explicitly says 'Use this first' and gives two concrete example questions ('what is this wallet holding?' / 'is this trader any good?'), which is a strong routing signal. It does not, however, name an alternative or state exclusions (e.g. 'use hydromancer_wallet_trades for the full trade list'), so the when-not guidance is absent.

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?

Beyond the readOnly/openWorld annotations, the description discloses ordering (newest first), the default 24h window, what the aggregates contain, and the non-obvious default that split orders are merged (paired with the mergeSplitOrders flag). It does not mention rate limits or the maximum result set, though the limit cap is in 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?

A single dense paragraph that front-loads the payload (every fill, newest first, with totals), then handles time-window formats and the merge default. No filler sentences.

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 carries the return-value burden and does so by naming volume, realized PnL, fees and a per-coin breakdown. Paging (limit/offset) is left entirely to the schema and the absence of a single-fill detail tool is unaddressed, but an agent has enough to call it 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 coverage is 100%, so every parameter is already documented. The description restates the since/until accepted formats verbatim from the schema rather than adding interpretation, and only meaningfully reinforces the mergeSplitOrders default. Baseline 3 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 verb and resource — every fill (buy/sell execution) a wallet made in a time window — plus ordering and aggregate contents. This implicitly separates it from siblings like wallet_closed_trades, wallet_open_orders and wallet_transfers, but never names 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?

Usage is implied by the definition of a 'fill' and by the window semantics, so an agent can infer when this fits. There is no explicit when-to-use/when-not or routing to alternatives such as wallet_closed_trades for position-level results.

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds real context beyond them: the default result window is the last 30 days, meaning calls silently truncate historical scope unless since/until are set. Missing are rate limits, truncation/pagination behavior when results exceed limit, and whether an invalid or unknown address returns an error or an empty set.

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 resource and scope in one sentence, then the time-format rules. Every sentence carries information the schema does not. The format enumeration is slightly list-heavy but each item is load-bearing for correct invocation.

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, 4-parameter query tool with no output schema, the description covers the resource scope, the default time window, and the time-format contract. An agent can call it correctly from this plus the schema. It would be stronger if it clarified ordering of returned rows or the relationship to the trades/funding siblings.

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 75% and the two thin parameters are exactly the ones the description rescues: since/until are documented in the schema only as "Default 30d", while the description spells out the accepted forms (relative like "30m"/"7d", ISO date, date-time, "now", Unix ms). It adds no semantics for limit or address, but those are already fully described 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?

Opens with a concrete verb+resource ("Money movements for a wallet") and enumerates the included categories: deposits, withdrawals, sends, spot/perp transfers, vault deposits and liquidations. That enumeration distinguishes it well from siblings like wallet_trades or wallet_funding. It stops short of explicitly naming the sibling it is not (e.g. hydromancer_recent_liquidations, which overlaps on the liquidation category), so it does not fully earn a 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?

The description never states when to choose this tool over hydromancer_wallet_trades, hydromancer_wallet_funding, or hydromancer_recent_liquidations, all of which plausibly overlap. The only usage-adjacent information is the default 30-day window, which is a behavioral fact rather than routing guidance.

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