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

Beyond the annotations, the description discloses meaningful behavioral details: rows are newest-first, results are capped at limit, startTime is auto-computed to request roughly limit candles, and max limit is 500. This gives the agent valuable insight into how the tool behaves before calling it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it opens with the core purpose, then packs ordering, limiting, interval options, and an example into two sentences. Every sentence adds useful information 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?

Given the output schema exists and annotations cover safety profile, the description provides enough contextual detail: parameter behavior, valid intervals, ordering, and a concrete example. Nothing essential for selecting or invoking this tool 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?

With 0% schema description coverage, the description must explain parameters, and it largely does: coin is demonstrated via example, limit is explained as a cap with a max of 500, and interval gets an explicit list of valid values. Coin's exact format is only shown through the example rather than stated directly.

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: returns OHLCV candles from candleSnapshot for a given coin. It also specifies ordering and limits, making it clearly distinct from sibling tools like trades, quote, and order_book, which serve different market data 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?

The behavior and output are clearly described, so an agent can infer this tool is for historical OHLCV data. However, it does not explicitly say when to prefer this over sibling alternatives or mention any exclusions, leaving usage guidance mostly implied.

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/destructive annotations, the description discloses that funding_history is fetched only for topN coins and only appears on rows where that call succeeded. This conditional, partial-success behavior is useful and does not contradict the annotations.

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 purposeful sentences: core ranking behavior, funding-history nuance, and a worked example. No filler, and the most important information is front-loaded.

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 tool with two optional parameters and an output schema, the description covers the data source, parameter choices, returned fields, and the conditional funding_history behavior. An agent has enough information to decide and invoke 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?

With 0% schema description coverage, the description fully compensates: it defines metric options (premium default; oi/volume), topN as the number of ranked rows to return, and illustrates usage with a concrete example.

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 ('Rank'), a resource ('ALL perps'), a ranking metric, and an output shape (topN rows with premium, oi, dayVolume, markPx). The funding_history detail also distinguishes it from the funding_history sibling 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?

The description makes the use case clear: screen and rank perps by premium, oi, or volume and return the top N. It does not explicitly name alternatives or state when not to use it, though the 'fundingHistory rows are fetched ONLY for the topN coins' warning implies it is not a full funding-history endpoint.

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 mark it as read-only, open-world, and non-destructive. The description adds valuable behavioral details beyond the annotations: results are newest-first, capped at `limit` with a maximum of 500, and the premium is a current snapshot rather than part of the historical series. No contradiction with annotations.

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 packs all essential information into one dense sentence plus an example: data source, output fields, ordering, cap, and a usage illustration. No filler or redundant phrasing; every clause earns its place.

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 tool with only two parameters and an output schema, the description covers the key aspects: what data is returned, field names and units, ordering, and limit behavior. The annotations handle safety and world assumptions. Nothing critical is missing for an agent 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 description coverage is 0%, so the description must compensate. It names `coin` and `limit`, clarifies that `limit` caps results and has a max of 500, and gives a concrete example (funding_history(coin="BTC", limit=48)). It could add that `limit` defaults to 100, but the example and cap clarification provide solid guidance.

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 exactly what the tool returns: hourly funding history for a coin plus the current premium, with specific row fields (fundingRate, premium, time in ms). It clearly distinguishes this from general market tools by naming the internal data sources (fundingHistory, metaAndAssetCtxs) and ordering behavior.

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 provides clear context for when to use it: when you need hourly funding data and the current premium for a coin. It does not explicitly name alternatives or exclusions relative to siblings like funding_carry_screener, but the purpose is specific enough that an agent can infer the appropriate use case.

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 readOnlyHint/openWorldHint annotations, the description discloses significant behavioral nuance: mark prices are resolved from multiple sources and tagged with mark_px_source, null liquidation price is handled honestly with an estimated flag, and funding_drag aggregates negative funding payments. This gives the agent accurate expectations about data completeness and reliability.

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 dense but every sentence adds operational value: scope, data sources, mark resolution, estimation semantics, funding drag, and input validation. It is front-loaded with the key purpose and the only borderline item is 'KEY TOOL.' which is a useful prioritization signal.

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 an output schema present, the description does not need to enumerate return values. It covers edge cases like missing liquidationPx, isolated vs cross margin behavior, fallback mark sources, and required address format, so a correct call can be constructed without external documentation.

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 input schema only specifies address as a string with 0% description coverage, so the description carries the full burden. It fully compensates by stating the address must be 0x plus 40 hex characters and providing an example call, making validation unambiguous.

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 as liquidation risk for one perp account, drawing on clearinghouseState and userFunding. It enumerates the exact margin and position fields returned, and the perp-account focus distinguishes it from spot and market-data 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?

The description implies usage: call it when you need liquidation risk for a specific perp account, and it gives the required address format with an example. However, it never explicitly states when to prefer an alternative like wallet_balance or spot_overview, so the agent must infer selection from 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 declare readOnly and non-destructive behavior; the description adds meaningful operational context: the tool is backed by a single call, results are sorted descending by the chosen key, and are capped by limit up to 100. This goes beyond the structured annotations without contradicting them.

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 packs all essential info into three packed sentences plus an example, with no filler. The scope and single-call nature are front-loaded, followed by field list, sorting, and limits — each sentence earns its place.

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 tool with two optional parameters and an output schema, the description is complete: it names inputs, outputs (fields and totals), ordering, and the cap, and includes an invocation example. No important behavior is left unexplained.

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 input schema has no descriptions, so the description carries the full burden. It explains that sort accepts open_interest, volume, or premium with a default, and that limit has a default and a maximum of 100, reinforced by a concrete example. This fully compensates for the 0% schema 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?

The description clearly identifies the tool as a perp market overview with a specific data source ('ONE metaAndAssetCtxs call'), enumerates included fields (mark, open interest, day volume, premium, max leverage, totals), and describes sorting and limits. The 'Perp' qualifier and unique field set distinguish it from siblings like spot_overview and funding_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when this tool is useful: retrieving a ranked overview of ~233 perps with totals, with sort and limit controls. It does not explicitly name alternative tools or state 'when not to use', but the perp-specific framing and the visible sibling list make the intended usage reasonably 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 indicate read-only and non-destructive behavior. The description adds meaningful behavioral detail beyond those annotations: depth levels per side with default and max, nSigFigs-based aggregation, and per-side total liquidity sum (px*sz). It does not mention pagination or rate limits, but these are not required given the safety annotations and output schema. No contradiction with annotations.

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 with the core resource before adding precision and liquidity details. The nSigFigs terminology is somewhat technical but not wasted. The example at the end earns its place by showing a realistic 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?

With an output schema present and safety annotations covering side effects, the description sufficiently covers the essential call semantics: required coin, optional depth with default and max, and aggregation behavior. It does not specify coin formats or error behavior, but the example and defaults make the tool adequately callable.

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 0%, so the description must compensate. It explains 'depth' clearly (levels per side, default 10, max 100) and illustrates 'coin' with an ETH example. The coin parameter itself is only described as 'one coin', which is thin, but the example largely removes ambiguity.

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 identifies a specific resource (l2Book order book for a single coin) and states what is delivered: depth levels per side, aggregation precision, and total liquidity per side. It is clear and distinct from the other market-data siblings, though it does not explicitly name or contrast 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 context is implied: if you need an aggregated order book for one coin, this is the tool. The example call gives concrete invocation guidance, but the description does not explicitly say when to use this tool versus alternatives like market_overview, quote, or trades, nor does it state 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 destructiveHint=false, covering the safety profile. The description adds valuable behavior beyond that: the data sources (allMids + l2Book), the coin-validation rule against the perp universe, and the notable spot-pair pass-through behavior. No contradiction with annotations 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?

Three sentences, each earning its place: the core function and outputs, the validation behavior, and a concrete call example. The most important information is front-loaded, and there is zero filler or repetition of schema/annotation data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (1 parameter) with an output schema covering return values and annotations covering safety, so those burdens are lifted. The description covers behavior, data source, coin validation, and an example. Minor gaps: domain terms like allMids and l2Book are unexplained, but this is not critical for such a scoped 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 0% schema description coverage, the description must carry the parameter documentation burden. It compensates well by explaining the coin validation against the perp universe, the spot pair format, and providing an explicit example (quote(coin="BTC")). It could be more explicit about accepted formats and case sensitivity, but for a single-param tool this is strong compensation.

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 function: retrieving a single coin's live quote from allMids and l2Book, returning bid/ask/mid/spread and top-of-book sizes. It names the resource (one coin), the verb (get live quote), and the output fields, which clearly distinguishes it from siblings like candles (historical), trades (executed trades), and order_book (full depth).

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 usage context is implied — an agent needing a live quote for one coin would naturally select this tool. The validation note adds when it can be used (coins in the perp universe, spot pairs in '@{index}/NAME' format). However, no explicit alternatives or exclusions are named; the distinction from order_book or market_overview is left to inference.

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

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

The description discloses the data sources (spotMeta + spotMetaAndAssetCtxs), the token-name mapping, sorting by day volume descending, and the limit cap with a max of 100. This adds meaningful behavioral context beyond the readOnlyHint/openWorldHint annotations, though it does not mention edge-case behavior such as what happens when limit exceeds the maximum.

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 a compact, front-loaded sentence that covers purpose, data sources, content, sorting, and cap, followed by a simple example. It contains no fluff, though the long opening sentence packs several ideas together and could be split for even easier reading.

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?

Given the presence of an output schema and safety annotations, the description covers the essential behavioral context: what data is included, how names are resolved, ordering, and limit semantics. Minor details like full field definitions or invalid-limit handling are omitted but are unlikely to prevent correct invocation.

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 input schema provides only a type and default for limit with no description, so the description compensates by explaining that limit caps the result count and has a maximum of 100, plus a concrete example. This is sufficient for the single 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?

The description clearly states that the tool returns a spot market overview of ~326 pairs and enumerates the fields (name, mark, day volume, OI) and the HIP-1 to ERC-20 link resolution. This identifies the resource and content well, though it does not explicitly contrast it with sibling market_overview or use a direct verb, 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 example call spot_overview(limit=10) demonstrates usage, and the tool's purpose is inferable from the name and description. However, there is no explicit guidance about when to choose this tool over alternatives like market_overview, nor any exclusions, so the usage context is only implied.

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 readOnlyHint, openWorldHint, and destructiveHint annotations, the description discloses the adaptive block-window algorithm, row ordering and max (500), `from_block` default behavior, and error degradation into an RpcError-kind dict. This gives the agent a solid model of runtime behavior and failure modes.

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 dense but every sentence carries operational value: windowing mechanics, output format, error behavior, and an invocation example. The length is justified by the tool's complexity, though a bit more scannability would help.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers input semantics, output row fields and ordering, windowing behavior, error handling, and a call example, which is complete even though an output schema exists. No critical operational detail appears missing for correct invocation.

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 0% schema description coverage, the description compensates by explaining `from_block` (anchors the walk, default latest - 300) and `contract` (the queried token address), and illustrating `limit` with an example and the 500-row max cap. However, `limit`'s own default of 100 and exact row-capping semantics remain implicit rather than explicitly stated.

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 the exact resource (ERC-20 Transfer events for a `contract` on HyperEVM) and identifies the mechanism (`eth_getLogs`). It is clearly distinct from sibling tools like trades, order_book, or wallet_balance, which concern other data categories.

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 establishes a clear context for use: retrieving recent ERC-20 transfer events for a specific contract on HyperEVM. It does not explicitly mention when not to use it or name alternative tools, but the event-specific scope is sufficiently clear to guide tool selection.

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 readOnlyHint/annotations, the description reveals how the profile is assembled (userFills + userFunding + clearinghouseState), how limit affects analysis (max 500, newest-first), and flags that the win-rate metric is approximate ('win-rate-ish'). This is meaningful behavioral disclosure.

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 dense but efficiently organized: core purpose first, metric list, then limit semantics, then a usage example. There is no filler or repetition of schema 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?

Given the output schema exists and annotations declare read-only/open-world behavior, the description adds the missing operational details: input semantics, max fill limit, data source composition, and an example. Nothing critical for calling this tool 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?

With 0% schema description coverage, the description compensates by explaining limit's semantics and showing address usage with a concrete example. It could more explicitly define the address format and clarify defaults, but the example plus limit explanation covers the essential meaning.

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 'Trading profile for one address' and enumerates concrete outputs (closed PnL, fees, volume, fill count, per-coin breakdown, net funding, open positions), making the resource and action unmistakable. The address-scoped aggregate profile is clearly distinct from market-level siblings like market_overview, candles, and order_book.

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 clearly establishes that the tool is for a single address's trading profile and documents constraints such as limit capping fills at 500 newest-first. It does not explicitly name sibling alternatives or state when not to use it, 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?

Beyond the readOnlyHint and non-destructive annotations, the description discloses meaningful behavioral traits: results are newest-first, capped at 500 rows, and each row carries side, px, sz, time, coin, hash, and users. The example also clarifies parameter usage, which adds value over annotations alone.

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 a single dense sentence followed by a clear example. It front-loads the core action and then lists output fields and constraints without unnecessary words, making it easy for an agent to parse quickly.

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?

Given the small parameter count, annotations, and the presence of an output schema, the description is fully adequate. It covers ordering, maximum row count, output fields, and parameter usage through the example, so an agent has enough information to select and correctly call the 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 description coverage is 0%, so the description must carry the parameter meaning. It does so by showing coin as the required base asset (example 'BTC') and limit as controlling row count, including a concrete call example. It does not deeply explain coin format or edge cases, but it provides enough for correct invocation.

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 tool's action as retrieving 'Recent public fills from recentTrades(coin)' and specifies the exact data fields included. It distinguishes itself from likely siblings by emphasizing 'both sides' addresses' and 'users [maker, taker]', which is unique among the listed tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: for recent public trades with maker/taker address details, newest-first, up to 500 rows. It does not explicitly state when not to use it or name alternative tools, but the sibling list and clear output scope provide sufficient 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?

Beyond the read-only annotation, the description discloses how balances are fetched: eth_getBalance, eth_call balanceOf, and spotClearinghouseState. It also reveals the token resolution limit, the rate-limit awareness, and the output row structure with balance_raw, balance, and source.

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 information-dense but well-organized, leading with the core purpose and then listing sources, limits, output fields, and an example. Every sentence adds value and no content is redundant with the annotations.

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 tool with one parameter and an output schema, the description covers all essential behavioral context: supported balance types, token resolution logic, rate limits, output fields, and an invocation example. Nothing critical 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?

The only parameter, address, has no schema description, but the description includes a concrete example call and makes clear the address is a wallet address on HyperEVM. The 0x example sufficiently compensates for the single low-coverage 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?

The description clearly states what the tool does: returns wallet balances across HyperEVM native, ERC-20, and Hyperliquid spot sources. It names the exact RPC methods and output structure, making it distinct from sibling tools like token_transfers or market_overview.

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 context on what the tool covers and even notes the 20-token cap and 100 req/min RPC budget. It does not explicitly name alternative tools or say when not to use it, but the scope is well-defined enough for an agent to select it correctly.

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