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

Annotations already mark readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: accounts are privacy-hidden, and a privacy-empty result returns an honest error dict rather than an API failure. This goes beyond the annotations and helps an agent interpret unexpected results correctly.

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 information-dense, front-loading the core purpose before detailing data options and a usage example. Minor typo ('tapi') and a slight run-on structure prevent a perfect score, but every sentence contributes useful information.

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

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

For a simple read-only account tool with an output schema, the description covers purpose, parameters, default values, privacy behavior, and error semantics. It does not discuss invalid `data` values or exact address requirements, but the output schema and remaining context make the tool sufficiently usable.

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 carries the burden. It compensates well by enumerating the valid values for `data`, stating the default (`balance`), and giving an address example. Address format is only hinted at via the example, but overall parameter meaning is substantially clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('read') and resource ('account') scoped to 'ANY address' on Aster Chain, and explicitly names the underlying RPC methods (aster_getBalance, aster_openOrders, aster_userFills). This clearly distinguishes it from the sibling market-data tools such as order_book and trades.

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 clear usage context: keyless account reads for any address, with distinct data modes. It does not explicitly name alternatives or state when not to use it, but the domain is obvious from the sibling list, and the description leaves little ambiguity about the tool's role.

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 the tool as read-only and non-destructive. The description adds useful context: the Solana path is keyless, EVM paths depend on RPC configuration, and the result includes hourly buckets and chain breakdowns. It does not discuss rate limits, but the readOnlyHint covers the main safety concern.

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 structured, front-loading the purpose and following with configuration-dependent details, parameter options, and an example. Some internal jargon like 'D4 sub-block' adds parsing cost, but overall it 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 multi-chain data-fetching tool, the description covers data sources, configuration prerequisites, parameter constraints, and the presence of aggregate stats. Since an output schema exists, return values do not need to be spelled out fully; the main remaining gap is the precise role of the limit parameter.

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 compensate. It fully documents chain_filter with allowed values and default 'all', and gives a limit example. However, limit's exact meaning—whether it caps flows, buckets, or per-chain results—is never 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 clearly identifies the tool as fetching vault deposit flows from Solana and EVM chains, with a specific data source and an additional deposit_stats component. It is easily distinguished from the market-oriented sibling 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 states when EVM chain data is available (when ASTER_EVM_RPC_URL* is configured), defines the chain_filter options, and gives a call example. It does not explicitly compare against alternatives, but none of the siblings overlap with deposit flows.

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 mark this as a safe, read-only, open-world operation, so the bar is lower. The description adds meaningful behavioral detail by revealing that TEST* spot names and SETTLING futures statuses are hidden by default unless include_junk=True, and that output granularity changes when symbol is provided. This goes beyond the 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?

Every sentence adds unique information: scope, filtering behavior, venue values, symbol behavior, and an example. It is compact and front-loaded, though it leans toward telegraphic style and could be slightly better organized with labeled parameter sections.

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 annotations covering safety, the description needs only to cover invocation details. It explains all parameters, default behaviors, and an example. The main gap is a lack of explicit routing versus sibling tools, but for correctly calling this tool, the provided context is nearly sufficient.

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 carries the full burden of explaining parameters. It does this well: venue is constrained to {futures, spot, both}, symbol triggers single-symbol detail, and include_junk toggles junk filtering. The example further clarifies usage.

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 the resource ('Symbol universe') and the kind of data involved (filters, precisions, statuses, micro view), which makes the tool's aim clear. It also distinguishes the tool from siblings such as order_book or klines by focusing on symbol metadata, though it lacks an explicit verb like 'list' or 'get' and does not explicitly name sibling alternatives.

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 the tool is useful: fetching symbol metadata, with options for venue and single-symbol detail. It gives concrete examples and explains the include_junk flag, but it does not explicitly state when to choose this tool over sibling tools or provide exclusions. Usage guidance is present but only implicit.

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 establish read-only behavior and no destructive impact. The description adds genuinely useful behavioral context: the data source mix across 1/2/4/8h intervals is 'flagged honestly', the count is approximate (~730), and the output includes cap/floor and interestRate fields. This gives an agent an honest picture of data granularity and scope beyond the annotated safety profile.

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 efficient: one sentence covers the data source, coverage, fields, and an important data-quality caveat, followed by a compact parameter hint and a concrete example. Every element earns its place and the key scope 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 two-parameter, read-only tool with an output schema available, the description provides enough context: sources, coverage, output fields, sort semantics, and an example call. The only minor gap is that `limit` is not explicitly defined as a count of returned rows, though the example and parameter name make this reasonably inferable.

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 carry parameter meaning. It fully documents `sort` with allowed values and the default ('rate'), and the example shows `limit=10`, implying it controls result count. However, the description never explicitly states that `limit` limits the number of returned rates, leaving some ambiguity for a parameter that the schema does not describe either.

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: a funding overview panel aggregating premiumIndex ALL and fundingInfo, covering all ~730 funding rates with cap/floor, interestRate, and nextFundingTime. It does not use an explicit verb like 'retrieve' or 'get', but the context and example make the intended operation obvious. The 'ALL' and 'all ~730' scope helps distinguish it from narrower siblings like funding_screener.

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

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

Usage is implied rather than explicit: the tool is positioned as the broad, comprehensive funding panel for all markets. It provides the `sort` options and an example call, but does not state when to choose this over funding_screener or other sibling tools, nor what this tool is not for. There is no explicit exclusion or alternative comparison.

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, open-world, non-destructive behavior; the description adds meaningful behavioral detail by defining direction semantics (long = positive rates/longs pay, short = negative) and the D1 funding_regime headroom sub-block sourced from fundingInfo. 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 main purpose is front-loaded, direction semantics are compactly defined, and a concrete example is included with no filler. The wording is dense and slightly run-on, but every clause provides useful information.

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

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

With an output schema present, return-value documentation is covered structurally. The description covers the ranking dimensions, the optional parameter semantics, and a usage example, which is complete for a two-optional-parameter read-only 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 carries the burden. It fully defines `direction` including the default and the long/short meaning, and the example clarifies that `top` selects the number of ranked markets. It does not explicitly state that `top` is a count, but the example is sufficient.

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 action — one-call ranking of all markets by funding metrics — and identifies the calculated sub-block funding_regime. It is clear about what the tool produces, but it does not explicitly distinguish this from siblings like funding_overview or mark_index_divergence, so it stops short of a full 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 phrase 'one-call ranking of ALL markets' implies this is the go-to tool for cross-market funding comparisons, and the example shows a typical invocation. It gives no explicit when-to-use/when-not-to-use guidance or mention of alternatives, so 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?

Annotations already mark this as read-only and non-destructive. The description adds meaningful behavior beyond annotations: price_type routing, spot endpoint difference, interval range, and limit snapping to a priced tier capped at 1000.

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 information-dense: resource definition, endpoint routing, interval/limit behavior, and a concrete example in a few lines. Every clause adds 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 5-parameter tool with an output schema, the description covers the essential invocation details: symbol, interval, limit, price_type semantics, and spot/futures routing. No critical gap prevents an agent from selecting or calling this tool 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 carries the burden. It meaningfully explains price_type values, interval range, limit cap, and the market distinction between futures and spot. It does not spell out every parameter default, but the example reinforces usage.

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 the resource as Klines (OHLCV) and explains exactly what the tool provides, including the endpoint-selection logic for futures price types and spot. This clearly distinguishes it from sibling tools like order_book, trades, and oi_snapshot.

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 concrete guidance on when each variant applies: price_type last|mark|index routes to different futures endpoints, while spot ignores price_type and uses a different endpoint. It does not explicitly contrast with sibling tools, but the intended usage 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, openWorldHint, and destructiveHint, covering safety. The description adds valuable behavioral context: the data source (ONE ticker/24hr ALL call joined with exchangeInfo), the shape of the returned panel, top volumes, status counts, fresh listings, sort modes, and limit cap. 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 well-organized: first sentence covers the core output, second covers sort options, third covers the limit constraint, and fourth gives a concrete example. 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 that an output schema exists and annotations cover the read-only safety profile, the description provides enough detail for an agent to call the tool correctly. It fully explains the two parameters and the nature of the returned overview. Explicit sibling routing would improve completeness, but it is not essential for 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?

Schema description coverage is 0%, so the description must compensate. It does so by defining the allowed sort values (volume, change, listings), the default sort, and the maximum limit. It could clarify the exact meaning of 'change' and 'listings' sort behavior, but the provided parameter guidance is largely sufficient.

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 futures market overview and enumerates the specific data elements returned (symbol, last, 24h change %, quote volume, trades count, top volumes, status counts, fresh listings). This differentiates it from sibling tools like spot_overview and funding_overview by market domain, though it lacks a direct action verb like 'retrieves' or 'lists'.

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 by stating this is for futures markets, which implies use when a futures market overview is needed rather than spot, funding, or order book data. It does not explicitly name alternatives or give exclusion criteria, but the domain distinction is enough for basic 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?

Annotations already indicate a read-only, non-destructive operation. The description adds useful behavioral context: it uses only one premiumIndex call, cross-checks with markPriceKlines vs klines, limits analysis to up to 3 symbol-pairs, and is weight-economical. This goes beyond the annotations and helps an agent understand cost and scope.

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 not bloated; the first sentence packs the core behavior and constraints, and the example is useful. Minor readability could improve, but every 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?

Given a single optional parameter and an output schema, the description covers the essential mechanism, data sources, and efficiency. It does not explain what threshold defines 'widest divergences' or how to interpret results, but the output schema likely covers return structure. Overall it is complete enough for selection and 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?

Schema coverage is 0%, so the description must compensate. It provides an example invocation with limit=10, which demonstrates usage but does not explicitly define what limit controls. The single parameter is simple and the default of 20 is in the schema, making the meaning reasonably inferable.

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 mark/index divergence screener, using markPrice vs indexPrice spread and cross-checking klines. This distinguishes it from sibling screeners like funding_screener and market_overview. The purpose is specific and actionable.

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 use case is implied by the name and description: find divergence opportunities. It does not explicitly state when to prefer this tool over alternatives, nor does it mention when not to use it. The 'weight-economical' note hints at cost-conscious usage but does not provide explicit selection 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 mark this as read-only and non-destructive, and the description adds meaningful behavioral details beyond that: the per-symbol one-call constraint, the 10-call cap, the absence of keyless OI history with a concrete 404 endpoint, and the default symbol selection behavior. This goes well beyond what the annotations alone communicate.

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 purpose, followed by precise constraints and a concrete example. Every sentence contributes useful information, and the honest note about the 404ing history endpoint is a valuable guardrail rather than 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?

With an output schema present and annotations covering safety, the description handles the key invocation concerns: per-symbol behavior, call limits, default behavior, and a clear example. It is nearly complete, but the implicit treatment of `top` leaves a small semantic gap for an agent deciding how to construct a valid call.

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 explicitly explains the `symbols` parameter, including its None default and an example, and it mentions the N cap. However, it never directly explains the `top` parameter, leaving its relationship to top-volume symbol selection to be inferred rather than 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 identifies the tool as an open interest snapshot and immediately clarifies that it is a per-symbol endpoint, which makes the resource and scope clear. It stops short of explicitly contrasting it with sibling tools, though the per-symbol and no-history details help distinguish it from broader market or kline 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 provides clear usage context: it is a per-symbol endpoint, each symbol costs one call, N is capped at 10, and when symbols is None top-volume futures symbols are used. It does not explicitly name alternatives or exclusion conditions, but the constraints are specific enough to guide 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?

Annotations already declare read-only and non-destructive behavior. The description adds valuable behavioral detail beyond annotations: depth is snapped to the nearest priced tier, weight costs are listed, and the venue-dependent endpoint behavior is disclosed. No contradictions exist.

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 with the core purpose, and each sentence adds useful information: endpoint mapping, depth snapping/weights, and a concrete example. It avoids fluff while remaining technically specific.

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, the description provides enough context for correct invocation: which venue to use, how depth is handled, and a call example. Nothing critical is missing for an agent to select and call this 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 compensate. It explains venue by mapping futures/spot to endpoints, depth by snapping/weight tiers, and symbol through the example. It does not exhaustively define possible venue values, but it conveys the essential meaning of all three 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 action and resource: retrieving an aggregated order book, and identifies the exact endpoints for futures and spot. It clearly distinguishes the tool from siblings like klines or trades by naming the depth/order-book use case.

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 about venue-specific endpoints and an example call, so when an order book is needed this tool is implied. However, it does not explicitly discuss when to prefer this tool over alternatives such as market_overview or trades, nor does it give exclusion criteria.

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 this is a safe read-only, non-destructive operation. The description adds meaningful behavioral detail beyond annotations: it joins ticker/24hr data with exchangeInfo, filters TEST* junk pairs by name, and notes the approximate pair count (~68). This gives an agent a concrete sense of the operation's 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 and information-dense, with the core idea front-loaded and a helpful example. The technical shorthand ('sapi ticker/24hr ALL') is slightly cryptic but does not add unnecessary length.

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 a very simple tool with one optional parameter and an output schema, the description covers the operation's scope, data sources, and filtering behavior. It does not explain return structure, but the output schema exists and annotations cover safety. The only notable gap is explicit sibling differentiation.

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 provides a usage example (limit=10) but does not explicitly define what 'limit' controls (likely the number of returned pairs). The example helps, but the semantics are left largely to inference.

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 ('spot market overview') and the data sources used (sapi ticker/24hr ALL joined with exchangeInfo), which distinguishes it from broader siblings like market_overview. It lacks an explicit imperative verb, but the intent is clear and scoped to spot trading pairs.

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 clear context for what the tool returns (spot market overview with trading pairs), which implies when it is appropriate. However, it does not explicitly mention when not to use it or name alternative tools for different scopes, leaving exclusion criteria unstated.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: the futures endpoint requires no key, is 'fresh,' and the spot path may return 'an honest error dict' if dead. This goes beyond what the annotations convey, though it doesn't address rate limits or response ordering.

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 purpose ('Recent trades'). The example is efficient and adds clarity. The phrase 'probed live in smoke' is slightly tangential but contributes to transparency. No redundant wording, so the length is appropriate.

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 that an output schema exists, return values need no description. The annotations cover safety. Still, a caller might be uncertain about the exact valid values for `venue` (e.g., 'futures' vs 'spot') and whether the error dict behavior applies only to spot. The description is adequate for selection but not fully complete for invocation without schema inspection.

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 stated as 0%, so the description must carry parameter meaning. The example `trades(symbol="BTCUSDT", limit=10)` covers symbol and limit usage, and the text distinguishes futures vs spot, indirectly hinting at the venue parameter. However, limit semantics, the default of 20, and valid venue values are not explicitly explained, so compensation for the schema gap is only partial.

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 'Recent trades,' which clearly identifies the resource and operation. It also distinguishes the futures endpoint from the spot path, helping separate it from sibling tools like order_book or klines. However, it uses a noun phrase rather than an explicit imperative verb like 'get' or 'fetch,' so it is not quite 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 implies when to use this tool (when recent trades are needed) and gives context that the futures endpoint is 'keyless and fresh' while the spot path was uncertain. It does not name alternative tools like klines or order_book, nor does it explicitly state when NOT to use this tool, so guidance is implied rather than explicit.

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 annotation, the description discloses that the correlation is computed locally from klines with at most two klines calls, caching when possible, and an honest note when data is insufficient. This gives useful operational context without contradicting 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?

The main functionality is front-loaded and every sentence contributes: core map, correlation sub-block, window semantics, and an example. It is dense with parenthetical lists but not bloated given the complexity.

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 screener with an output schema, the description covers the main behavior, window choices, and a call example. It lacks explicit when-to-use guidance and limit semantics, but is largely complete for 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 must carry parameter documentation. It documents window with valid values and purpose, but says nothing about the meaning or behavior of limit beyond the example call, leaving a real gap.

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 it is a TradFi-perp screener that produces a local asset-class map by baseAsset with per-class volumes/prices/funding, plus a correlation sub-block. This identifies the resource and operation clearly and distinguishes it from generic siblings like market_overview or spot_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?

The description implies usage through its screener framing and window parameter, and provides an example call. However, it never explicitly explains when to choose this tool over its siblings or when not to use it.

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