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

Adds substantial context beyond the annotations: every later position change (opened/closed/increased/reduced/flipped) is pushed to the user's channels, the first sight is a silent baseline, and the address counts against the plan's limit. The named failure responses (terminal_required, limit_reached) disclose error behavior the annotations cannot express.

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

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

Front-loads the invocation trigger in the first clause, then layers behavior, baseline semantics, and failure modes. Dense but every clause (including the format hint and error codes) earns its place; nothing is redundant with 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?

For a two-parameter write tool with no output schema, the definition covers trigger, push behavior, limit accounting, and failure codes. It omits what a successful response returns (e.g., an identifier) and any auth requirements implied by 'writes to your account,' leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both address and label are already documented in the schema. The description repeats the address format but says nothing about the optional label parameter, so it adds only marginal value. Baseline 3 applies when the schema carries the parameter documentation.

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

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

States a specific verb+resource: follow/track a Hyperliquid address to receive position alerts. The parenthetical format spec (0x + 40 hex) and the sibling list (add_watchlist_symbol, create_alert_recipe) make it unambiguous what this tool does versus adjacent alert 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?

"Call this when the user asks to follow, track or get alerts for a Hyperliquid address" gives a clear invocation trigger, and the terminal_required/limit_reached conditions tell the agent when the call will fail. It doesn't explicitly name alternatives (e.g., use add_watchlist_symbol for symbols) or the remove counterpart, so it stops short of full routing 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?

Goes well beyond the annotations by disclosing the default-list fallback including the single-list edge case, dedup behavior ('stays once', consistent with idempotentHint=true), per-connection rate limiting, and account-level auditing of each write. Nothing contradicts the declared hints; the readOnly=false/destructive=false profile is consistent with 'adds' and 'stays once'.

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 tight sentences: trigger first, then resolution/default behavior, then return value and write side effects. Every sentence carries distinct information with no repetition of the title or schema.

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

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

With no output schema, the description compensates by stating the return value ('Returns the list's symbols after the change'). Combined with rate-limit and audit side effects and the default-list resolution rules, an agent has everything needed to call this 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 the baseline would be 3, but the description adds real semantics the schema lacks: watchlist_id falls back to the default list and, if the account has only one list, to that list. It also reinforces the symbol-format hint only implicitly, which keeps it from a 5.

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 ('Adds the symbol to the list named by watchlist_id') and pairs it with a natural-language trigger ('watch, follow or add a coin'). It is trivially distinguishable from siblings like remove_watchlist_symbol, list_watchlists, and add_tracked_address 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?

Gives a concrete user-intent trigger ('when the user asks to watch, follow or add a coin to their watchlist'), which covers the main selection question. It does not explicitly name the inverse tool (remove_watchlist_symbol) or state when not to use it, so it falls short of full alternative routing.

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

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

Annotations already declare a non-readonly, non-idempotent write, and the description adds meaningful extra context: default delivery (Telegram first, email fallback), cooldown_hours suppressing repeat fires per symbol, per-plan recipe caps returning a limit response, and per-connection write rate limiting with each write recorded on the account.

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 'Call this when...' routing sentence and dense with useful facts, but the entire body is a single run-on paragraph mixing field enum, units, conditions, scope, plan limits, and rate limits. A little structure would make the enum list and the write-constraints easier 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 9-param mutation tool with no output schema, the description covers what is created, how it fires, default channels, cooldown, scope defaults, plan caps, and rate limiting. Nothing an agent needs to invoke 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 coverage is 100% (baseline 3), but the description goes well beyond it: it enumerates all 17 valid field values that the schema only hints at with 'e.g. funding_rate_pct', and it disambiguates percent units ('0.05 means 0.05%'). It also clarifies the field/op/threshold vs conditions (max 6) alternative and the symbols-implies-scope-symbols relationship.

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

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

States a specific verb+resource ('Saves an alert recipe on the account') and immediately frames the trigger semantics (fires when every condition holds). It is clearly separable from list_alert_recipes, delete_alert_recipe, and parse_alert_text by naming the prep-step relationship.

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 says when to call it: the user asks to be alerted on a metric threshold AND has agreed to the exact condition, and it names parse_alert_text as the tool that produces that condition. Also states the plan-limit failure behavior, which is actionable 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 destructiveHint=true and idempotentHint=true, so the description earns credit for going further: it explains that an unknown id is a safe no-op that reports itself, that writes are rate limited per connection (sign-in or key), and that each write is recorded on the account. That is exactly the operational context an agent needs before a destructive call.

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 tight clauses: trigger first, then the action and no-op behavior, then rate-limit/audit facts. No filler, and the most decision-relevant 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 one-param destructive tool with no output schema, the description covers trigger, id provenance, failure semantics, and rate limiting. The only gap is the response shape on success, which is minor given the no-op case is described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single param's schema description already points to list_alert_recipes, so baseline is high. The description reinforces the id's provenance and adds non-obvious semantics — a stale/foreign id silently changes nothing — which is real value beyond the schema.

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

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

The description names a specific verb and resource ('Deletes the alert recipe with this id') and explicitly scopes it to the account. It also points to list_alert_recipes as the id source, so an agent can immediately distinguish it from create_alert_recipe and list_alert_recipes.

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?

'Call this when the user asks to remove an alert' is an explicit trigger condition, and 'list_alert_recipes shows the ids' supplies the prerequisite lookup step. It lacks an explicit when-not clause (e.g., versus editing a recipe), but the context is clear enough to route correctly.

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 the safety profile (readOnlyHint, openWorldHint), and the description adds real substance beyond them: the exact computation window, venue universe, and the >=75 / <=25 thresholds that define altseason vs bitcoin season. The provenance note "recorded daily history (never reconstructed)" is a valuable data-integrity disclosure an agent could not infer from structured fields.

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 dense sentences with zero filler: the trigger condition leads, the returned content and its semantics follow. Every clause carries information (thresholds, universe, provenance).

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 return-value burden and does so: live index value plus interpretation bands, strongest/weakest large alts, and recorded daily history. Nothing an agent needs to select or call the 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?

The tool takes zero parameters, so the baseline is 4. The description correctly adds nothing parameter-related, since there is nothing to disambiguate.

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

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

States a specific verb+resource: returns the live Altcoin Season Index along with strongest/weakest large alts and daily history. The index definition (share of top 50 Binance perp alts beating BTC over 90 days) makes it unmistakably distinct from siblings like get_market_indices, get_theme_indices, and get_factor_board.

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?

"Call this when the user asks whether it is altseason, how altcoins are doing against Bitcoin, or about market rotation" gives explicit triggering conditions tied to user intent. It does not name an alternative tool or a when-not-to-use case, so it stops 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 and openWorldHint, so safety is covered. The description adds genuinely new behavioral context: data is recorded hourly, the source is ByKaranteli (Binance and OKX only), and the series hold just the last 24 hours unless hours/asset is passed — an important truncation behavior an agent would otherwise miss.

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?

Usage triggers are front-loaded, followed by return contents and then retention caveats — a logical order with no filler. It is dense with comma-separated clauses, but every sentence carries information an agent needs.

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 describing return values, and it does: latest annualised rate per venue and asset, 30 days of hourly series for stablecoins and majors, and the carry table. Combined with the venue coverage and retention limits, an agent has enough to call this correctly without further clarification.

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 including the 720 maximum and the default-24 behavior. The description's line about series retention restates the schema's 'default 24, or the full 720 with asset' rather than adding new syntax or format detail, so the baseline of 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 (annualised margin borrow rates per venue and asset) with concrete output components: latest rate, 30-day hourly series, and the carry table. It is clearly distinguishable from siblings like get_funding_arbitrage or get_funding_heatmap because it names borrow cost and carry (funding minus borrow) as the subject.

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?

Opens with an explicit trigger list ('Call this when the user asks what it costs to borrow USDT, USDC...', 'which venue has the cheapest borrow', 'whether stablecoin borrow cost is spiking', 'what the carry of a basis trade is'). That is strong positive guidance, but it names no alternative tool and no when-not-to-use condition, so it falls short of the 5 bar.

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 safe-read (readOnlyHint=true, openWorldHint=true), so the description's job is to add output shape and quirks, which it does: history since 2017, positive premium = US buying pressure, and the non-obvious fact that the days parameter only extends the kimchi/Turkey rows. It does not state freshness/lag cadence of the 'latest daily' value, which is the main remaining unknown.

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 trigger clause is front-loaded before the return-value inventory, and every sentence carries information (triggers, outputs, sign convention, history depth, parameter scoping). It is dense but slightly overpacked, mixing trigger guidance and output enumeration in a single flow.

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 return-value burden and does so: it enumerates every field an agent would need, gives the sign interpretation, states history depth since 2017, and clarifies the one optional parameter's limited effect. Nothing required to call or interpret 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?

Schema coverage is 100%, so baseline is 3; the description earns an extra point by flagging that days only widens the kimchi and Turkey daily rows (up to 90) and does not extend the fixed 30-day headline premium series — a scoping nuance an agent could easily misread from the parameter name alone.

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 resource (Coinbase premium / US demand gauge) and states exactly what it returns: latest daily premium in percent, 7-day average, streak, 30 days of history, and annualized carry yields. It is specific and distinguishable from most siblings. The one gap is that 'what the cash-and-carry basis trade pays' overlaps conceptually with get_funding_arbitrage, and no boundary is drawn there.

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 opens with an explicit trigger: 'Call this when the user asks whether US investors are buying or selling Bitcoin or Ethereum, about the Coinbase Premium, or what the cash-and-carry basis trade pays.' That gives concrete user-intent contexts rather than a vague topic. It stops short of any exclusion or named alternative (e.g. get_turkey_premium for Turkey-only questions), so it is clear context without routing.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the analytical window (30-day rolling, daily returns) and universe (top perpetuals), which is real added context. It does not disclose result size limits or pagination behavior itself — those live only in the schema — so it adds value but not rich behavioral detail.

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, trigger condition front-loaded, then return shape, then parameter hint. No filler and nothing buried.

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

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

With no output schema and only one optional parameter, the description supplies what an agent needs: what the matrix is (Pearson, daily returns, 30-day rolling), over what universe, and how to reduce payload. It omits the character-ceiling behavior and the trimmed/truncation signaling that a caller may hit on a large board, which is the main remaining 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 description coverage is 100% and the detail parameter's schema text already defines compact/full/omitted semantics in depth. The description's closing sentence merely restates that mapping, adding no new syntax or edge cases. Baseline 3 applies since the schema does the heavy lifting.

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

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

States a specific verb-level outcome (returns the 30-day rolling Pearson correlation matrix of daily returns across top perpetuals) and names concrete user intents it answers: pairwise correlation, decorrelated pairs, alt/BTC tracking. No sibling in the list produces a correlation matrix, so it is cleanly distinguishable.

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?

Opening clause gives explicit triggers ("how correlated two coins are", "decorrelated pairs", "how tightly alts track BTC"), which is strong when-to-use guidance. It stops short of naming near-neighbors such as get_lead_lag or get_factor_board or stating when another tool is the better choice, so it is not 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 and openWorldHint, so the safety profile is covered; the description adds genuinely new context: data provenance (official CFTC), freshness ('updated every Friday'), and an interpretive caveat that hedge fund shorts are largely basis trade so week-over-week change matters more than level. That interpretive note is exactly the kind of behavioral insight annotations cannot carry.

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 trigger first, then the returned payload and cadence, then the interpretation caveat. No filler and the actionable when-to-call clause 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?

With no output schema, the description carries the burden of describing returns and does so (net positions, WoW changes, open interest, extremes/streaks) plus update cadence. For a zero-parameter read-only tool, an agent has everything needed to invoke and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is empty and fully consistent with the description.

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 specific data source (CFTC Commitments of Traders), the assets covered (Bitcoin/Ethereum) and the unit returned (net contracts), which is far beyond a restatement of the name. It does not, however, contrast itself with the sibling get_positioning, which an agent could easily confuse with this one.

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 explicit invocation triggers ('when the user asks how hedge funds or institutions are positioned', 'or about the CFTC Commitments of Traders report'), which is strong positive guidance. It stops short of stating when not to use it or which sibling to prefer for other positioning views.

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 important behavioral traits: the default response includes only the first 30 snapshot feeds, English notes only, and no per-venue matrix cells; detail modes alter truncation; and null country values should not be interpreted as unknown risk. These are substantive operational details an agent could not infer from 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 front-loaded with the triggering question types and then moves to return contents, caveats, and detail modes. It is dense but mostly efficient; the detail-mode explanation repeats information already present in the schema, which is a minor 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?

There is no output schema, so the description carries the burden of explaining return contents, which it does thoroughly by listing the registry sections and freshness information. It also covers default truncation, the meaning of null country values, and how detail modes change the response, leaving no major gaps for a one-parameter read-only registry 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 100% and the parameter description already explains compact, full, true, and default behavior in detail. The tool description restates the default and detail modes but does not add meaning beyond what the schema already provides.

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 — the live coverage registry — and enumerates exactly what it contains: liquidation feeds, snapshot feeds, funding arbitrage legs, positioning sources, whale tape, spot minutes, and Hyperliquid scan freshness. It clearly distinguishes itself from metric-oriented siblings by serving as the registry explaining what data is collected and how fresh it is.

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 triggering condition: 'Call this when the user asks which exchanges sit behind a ByKaranteli number, whether a feed is complete or sampled, since when a venue is collected, or how fresh the data is.' This is clear usage context, but it does not name any sibling alternative or state 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.

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

Beyond the readOnly and openWorld annotations, the description discloses that it returns latest readings and Pi Cycle cross dates, optionally the daily series, and that data is 'recomputed nightly from a first-party close record since 2012.' It also clarifies 'Levels, not forecasts,' setting correct expectations about output nature. These are meaningful behavioral details not captured by 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 front-loaded with the usage condition and is reasonably efficient. The long enumeration of indicators is slightly repetitive with the title but serves to specify coverage. Every sentence contributes, though the list could be trimmed without losing much.

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 100% schema coverage and no output schema, the description provides all an agent needs: the trigger scenario, the specific indicators covered, the return content (readings, cross dates, optional series), data source and update cadence, and a caveat ('Levels, not forecasts'). Nothing essential 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 parameters fully. The description mentions 'optionally the daily series' and the nightly recomputation, which lightly reinforces include_points and data recency, but adds no syntax or format details beyond the schema. Baseline 3 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 states a specific verb ('Call this when...') and a precise resource: Bitcoin cycle indicators, enumerating the exact indicators covered (Pi Cycle Top, Mayer Multiple, 200-week MA, 2-year MA multiplier, golden ratio multiple, profitable days, stock-to-flow, Puell Multiple, Bitfinex margin positioning). This clearly distinguishes the tool from siblings like get_market_indices or get_series, which are broader.

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 an explicit trigger: 'Call this when the user asks whether Bitcoin is near a cycle top or bottom by the classic indicators.' It does not name an alternative tool or state when not to use it, but the context is sufficiently clear that an agent can infer appropriate use.

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 only declare readOnlyHint and openWorldHint; the description adds non-obvious behavior such as the 5-minute sealing cadence, Solana mainnet writes, daily Base attestation, and the meaning of result ANCHORED. It also describes what the overview and per-record proof contain, going well beyond 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 description is front-loaded with the call condition and then covers invocation modes and return meaning without obvious filler. The prose is dense and could be split for readability, but every sentence contributes relevant information.

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

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

For a complex proof/verification tool with no output schema, the description supplies the missing return context: overview fields, record proof components, anchors, and verdict meaning. It also covers the main invocation modes, leaving little an agent needs for correct 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 description coverage is 100%, so the baseline is 3; however, the description adds semantic argument combinations beyond the schema: no arguments returns the stream overview, feed+asset returns one record at the newest epoch or at sequence, sequence alone returns one epoch, and catalog lists feeds. It does not add format details for each parameter, but the schema already covers those.

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 action: it returns on-chain proof for a sealed ByKaranteli number, either as a stream overview or as a per-record Merkle/signature proof. It distinguishes this verification/proof tool from sibling market-data getters by focusing on seals, Merkle roots, signatures, and Solana/Base anchors.

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 concrete triggering questions such as whether ByKaranteli data can be verified or was changed afterwards, and it explains argument modes: no arguments for overview, feed+asset for one record, sequence for one epoch, and catalog for the feed list. It does not name alternatives or explicitly say when not to use this tool versus sibling data tools.

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 read-only and open-world, and the description adds substantial behavioral context beyond them: returns newest first, AI-written notes checked against recorded data before publishing, publish time and data time, news-value score, board, coins, and permanent URL. It also discloses default window, count behavior, and detail variants, with no contradiction.

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

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

Front-loads the call condition and then moves to return behavior and parameter guidance, so an agent can find the key routing information quickly. It is dense and somewhat repetitive with the schema, but the content is largely purposeful for a complex, zero-required-param tool.

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 must explain what comes back; it does so thoroughly with ordering, provenance, field names, defaults, limits, language and card-type filters, and compact/full detail behavior. Given the annotations and full schema coverage, an agent has enough to 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?

Schema coverage is 100%, so the schema already documents all six optional parameters. The description mostly restates those defaults and options, adding only marginal context such as count indicating how many came back; baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific resource and scope: the desk's short dated observations written from its own recorded derivatives data. It distinguishes itself from raw-data siblings by framing the output as checked, quotable desk notes and explicitly saying it is information about data, never advice.

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 a clear triggering condition: call when the user asks what happened in crypto derivatives today/on a date, what the desk observed, or wants a dated quotable sentence. It implicitly overlaps with many sibling data tools but does not explicitly name alternatives or when not to use this one.

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 real value beyond that by disclosing the return grain ('one row per finalized US trading day and asset'), the units (USD), the four returned fields, and per-asset history start dates. It omits anything about caching, rate limits, or what happens when days exceeds available history, which keeps it short of a 5.

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

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

Three sentences: trigger first, return shape second, data-coverage caveat last. Every sentence carries distinct information an agent needs before calling, and nothing is repeated from the schema or 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?

With no output schema, the description compensates by listing the returned fields and row grain, and the per-asset history windows preempt the most likely failure mode (requesting days beyond available data). For a two-parameter read-only tool this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description earns above that by clarifying that 'days' counts US trading days and by giving per-asset start dates — which tells the agent that a large 'days' value returns fewer rows for SOL/XRP than for BTC/ETH. The asset enum is left entirely to the schema, which is fine.

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 trigger condition plus resource: 'when the user asks about Bitcoin, Ethereum, Solana or XRP spot ETF flows' and enumerates the exact metrics (net inflows/outflows, cumulative flow, total net assets). Names concrete tickers (IBIT, FBTC, ETHA, XRPC) so an agent can map a user question to this tool without opening the schema, and no sibling tool covers ETF flows.

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 'call this when' clause gives a clear positive trigger and enumerates three distinct user intents (daily net flow, cumulative since launch, total net assets). It does not name an exclusion or a competing tool (e.g. get_series or get_market_indices), but with no close sibling in the list the risk of mis-selection is low.

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 only cover read-only/open-world, and the description adds real behavioral substance the annotations lack: the n >= 30 significance gate, the 'distributions, not forecasts' caveat, the default 40-row page in board order, rows_total and trimmed reporting, and the 100,000-character ceiling on full answers.

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 trigger condition is front-loaded in the first clause, followed by return shape and then paging rules, which is the right order. It is dense but nearly every clause carries distinct information; the default/limit point is slightly restated from the schema.

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

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

With no output schema, the description carries the return-value burden and does so: it names the per-row fields (band, median 7-day follow-through vs base rate), the envelope fields (rows_total, trimmed), and the char ceiling. An agent could call this correctly without further 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 100% and already documents both parameters, so the baseline is 3. The description still adds meaning beyond the schema by explaining that trimmed names every cut, that rows_total counts all rows, and that the default ordering is the board's own.

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 concrete resource and payload: every recorded metric in its historical band plus the median 7-day BTC move versus base rate, explicitly framed as distributions not forecasts. That is far more than a restatement of the name, though it never names the nearest sibling (e.g. get_metric_context) to say how it differs.

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 three explicit triggering user questions ('unusual band', 'historically preceded BTC moves', 'cross-metric conditional overview'), which is unusually actionable. It stops short of exclusions or naming an alternative tool for the single-metric 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?

Annotations already declare readOnlyHint and openWorldHint, so the description's job is to add context, and it does: data is read daily from each venue's own fee endpoint, and per-pair priced venues are reduced to a median across pairs. It does not disclose coverage gaps or venues lacking a fee endpoint, which is the main remaining behavioral unknown.

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 invocation triggers, with no filler. The second sentence is long and packs in return shape, aggregation rule, and provenance, which is dense but still readable; a slight split would improve scannability.

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, yet the description states what comes back (maker/taker base tier per venue and market type, plus fee change log) and where it comes from. It stops short of specifying units (percent vs bps), timestamp granularity, or how venues without per-pair pricing are handled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly frames the output as venue-wide rather than accepting a notional argument, implicitly telling the agent that round-trip math must be done client-side.

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 (trading fee schedules) and a precise scope (base tier maker/taker per venue and market type, plus a fee change log). It clearly separates itself from siblings like get_leverage_tiers, get_venue_profile, or get_venue_markets by talking only about maker/taker pricing.

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?

Four concrete triggers are given: asking what an exchange charges, comparing maker/taker across venues, checking whether fees changed, and computing round-trip cost on a notional. What is missing is an explicit exclusion or named alternative (e.g. 'for VIP/volume tiers use X'), so the routing is clear but not exhaustive.

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 explains the VPIN scale, percentile, danger threshold, 24h average, historical implication, and the crucial caveat that VPIN says nothing about direction. This adds substantial interpretation and safety context that annotations alone do not provide.

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 dense sentences front-load the usage trigger and then summarize the return values and interpretation. Every clause carries useful information, with no redundant restatement of the name or 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?

With no parameters and no output schema, the description fully carries the burden by stating what is returned, how to interpret VPIN, the historical meaning, and the direction caveat. An agent has enough information to call and explain the result 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?

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline for a parameterless tool applies, and nothing in the description misrepresents inputs.

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 metric (VPIN order-flow toxicity) and asset scope (BTC, ETH, SOL perps), plus the exact user questions it answers. It is distinguishable from general positioning or pressure siblings because it is explicitly about informed/toxic order flow and market-maker pressure.

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 triggering conditions: users asking about informed or toxic flow, VPIN, or market-maker pressure. It does not explicitly name when not to use it or which sibling to use instead, so it falls short of the top score.

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, and the description adds substantial context beyond that: the data is measured from a minute-resolution record and is descriptive rather than predictive, plus it discloses the shape of results. Beyond annotations, no gaps or return-format issues remain, though pagination/error behavior is unstated.

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 when to call, then what is returned. Every clause earns its place, including the 'Description, not prediction' caveat that prevents misuse.

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 describing return values — and it does so thoroughly (per-window reactions, benchmark average, up/down split, next meeting date). 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?

There are zero parameters, so the baseline is 4; there is nothing for the description to clarify or omit.

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

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

States a specific verb+resource (measured FOMC impact on BTC) and precisely enumerates what it returns: 5/30/60-minute reactions, average versus a normal half hour, up/down split, next meeting date. It is clearly distinct from siblings like get_macro_liquidity or get_tradfi_board.

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 explicit triggering conditions — 'what Bitcoin does on Fed days', 'how FOMC statements move crypto', 'when the next FOMC meeting is' — which is strong context. It does not name a sibling alternative or state when-not to use it, so it stops 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 context beyond annotations: the venue coverage, the 12-perp scope, the fact that APR is net of taker fees and weekly rebalance cost, and that each row lists only its first 5 venue legs unless symbol is passed.

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 usage trigger, then moves efficiently into behavior and parameter guidance. The venue-name list is somewhat long but earns its place by clarifying breadth of coverage; overall it is appropriately sized for the tool.

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

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

There is no output schema, so the description must explain the return shape, and it does: best long/short venue per symbol with gross and net APR and limited venue legs per row. It covers the important calling context for a read-only analytics tool, though it could be slightly more explicit about pagination or page limits.

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 both detail and symbol are already well documented in the schema. The description largely mirrors that schema text, though 'pass symbol for every leg of one perp' adds a small amount of row-level context. Baseline 3 is appropriate when the schema carries the parameter documentation.

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 scope: it compares funding across venues for 12 major perps and returns the best long/short venue per symbol with gross and net annualized APR. It is clearly about cross-exchange funding arbitrage rather than general funding data, but it does not explicitly distinguish itself from sibling tools such as get_funding_heatmap.

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 opening sentence gives clear trigger conditions: funding arbitrage, funding rate differences between exchanges, or delta-neutral carry trades. It also explains how to use symbol and detail, but it does not name alternatives or state when not to use this tool.

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 real context beyond that: row count range (28-30), the fact that contracts without a live funding print are skipped, the exact returned fields, and the sign convention for funding. It does not cover rate limits or freshness/latency, keeping it below 5.

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

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

Front-loaded with the usage trigger and tightly packed, with no filler sentences. The second and third sentences are long and run-on, which mildly hurts scannability, but every clause carries information.

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

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

For a single optional param, read-only tool with no output schema, the description carries the return-shape burden itself (funding rate per settlement interval, 24h OI change, 24h price change) and covers the edge case of skipped symbols. Nothing needed 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 coverage is 100% and the symbol parameter already documents the BTCUSDT/BTC formats and the omit-for-all behavior. The description only restates the omitted-symbol default, so per the rubric 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 (current funding table across ~30 most traded Binance perps) plus the single-symbol variant, and names the sibling (get_top_movers) it is distinct from. An agent can select it 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?

'Call this when the user asks for the full current funding table ... or the funding rate of one specific coin' gives an explicit trigger, and 'For a pre-ranked top-10 of the most extreme funding rates, use get_top_movers instead' provides an explicit alternative with the condition that selects it.

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: true` annotation, the description provides crucial behavioral context: the data source ('largest accounts by equity on Hyperliquid's public leaderboard'), the update frequency ('scanned every five minutes'), and the output structure ('levels are their own liquidation prices bucketed around the mark').

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 tool utilizes its descriptive space entirely efficiently. Every sentence serves to scope the data, define its source, or describe the expected output format without unnecessary 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?

Despite lacking an output schema, the description provides all necessary context for an agent: what the data represents (liquidation price map), how fresh it is (5-minute scan), and how the resulting levels are categorized, making it a complete tool definition for an agent.

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?

Given 100% schema description coverage, the baseline is high. The description reinforces the context of the parameters by linking 'hours' to an 'hourly archive of level totals' and the 'coin' to 'Hyperliquid names,' adding valuable operational 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 clearly articulates the tool's specific function: mapping Hyperliquid whale tracked positions to liquidation prices. It provides multiple examples of use cases (notional at each price, comparison to LiqMap) which immediately define its purpose.

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 acts as a precise dispatcher, listing exact user intent phrases that necessitate this tool call. By providing specific data characteristics (tracked accounts, equity leader board) it implicitly defines its scope compared to broader market analysis tools.

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 what annotations cannot: the 5-minute refresh cadence, that data is addresses-only, and the 100,000 character ceiling with remediation advice. It does not state degradation behavior when the scan is stale or unavailable, but the substantive behavioral context is present.

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 trigger conditions are correctly front-loaded, but the second sentence is a dense six-clause run-on that merges return contents, defaults and parameter advice into one breath. Every clause carries information, yet the packing forces re-reading and would be clearer split apart.

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

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

There is no output schema, so the description must describe returns and does: the live board, positions with liquidation prices, and optional last-200 change events. It stops short of describing the fields per row (entry price, notional, PnL) or the trimmed-metadata behavior, which leaves some ambiguity for an agent reporting results to a user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the interplay between parameters — without coin the limit applies to the 30 largest coins and positions, and with coin it narrows scope. That cross-parameter relationship is genuinely additive rather than a restatement of the schema.

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

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

States a specific verb and resource: a live board of the 300 largest Hyperliquid accounts by equity, with long vs short, positions, liquidation prices and recent changes. An agent can tell this apart from generic positioning tools because the description names the venue, the account population and the ranking metric.

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?

Opens with explicit trigger conditions ("Call this when the user asks what Hyperliquid whales are doing, whether the biggest accounts are net long or short a coin...") covering four distinct question types. It also states default behavior without a coin. It does not name the nearest sibling, get_hl_positions, or say when that is the better choice, so routing against alternatives is left 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?

Annotations already declare readOnlyHint and openWorldHint, yet the description adds substantial context beyond them: data is a latest-hourly reading per venue, coverage spans every exchange on the insurance fund board, USD figures are OKX's own published total versus summed priced pools elsewhere, and a caveat that 'a fund is a balance the venue reports, not an audit of its reserves.' That precision and the methodological caveat are genuinely useful for interpreting results.

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

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

Front-loads the trigger scenarios, then the return shape, then the one parameter nuance and a caveat — a logical order with no filler. The single long paragraph is dense; breaking the return inventory into a tighter clause list would improve scannability slightly.

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 full burden of explaining returns — and it does, covering the metric set, the venue coverage, the hourly cadence, and the per-venue daily history. An agent has everything needed to decide and invoke.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaning: it explains exactly what 'pools' unlocks (contracts covered, asset, balance, USD) beyond the schema's terse 'large for Binance and Bybit' note. It also ties history output to 'daily closes per venue' without contradicting the schema's 1-366 day range.

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

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

States a specific verb+resource (retrieve exchange insurance fund data) and enumerates the exact metrics returned: fund size in USD, per asset, 24h/7d change, percent of perpetual open interest, and daily closes. This is clearly distinguishable from siblings like get_open_interest or get_venue_profile.

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?

Opens with explicit trigger conditions ('Call this when the user asks how big... whether a fund is shrinking or was used after a crash... how much exchanges hold to absorb bankrupt liquidations... how a fund compares with open interest'). It does not name a specific alternative sibling to use instead for the underlying OI data, but the when-to-use context is unambiguous.

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

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

Annotations already establish that this is a read-only, open-world data lookup, so the description does not need to carry the safety profile. It still adds useful context by naming the data source (daily Deribit chain) and enumerating the returned fields, which helps since there is no output schema; it stops short of disclosure about freshness, latency, or snapshot timing.

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 selection trigger and followed by the return contents. Every clause earns its place and there is 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?

With no output schema and only one fully documented parameter, the description supplies exactly the missing information: what analytical questions it answers and what fields the response includes. An agent can decide to call it and interpret the result without further context.

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 single currency parameter has full schema description coverage and an enum, so the schema already documents it completely. The description does not mention currency at all, so it adds no meaning beyond the schema; baseline 3 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 states a precise resource (implied-volatility surface and 25-delta skew) and enumerates the exact analytical questions it answers (IV by strike/expiry, skew, put vs call IV, term structure, downside protection cost). Those triggers distinguish it clearly from siblings like get_options_chain, get_options_snapshot, and get_options_flow.

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 explicit when-to-use triggers tied to user questions about IV, skew, term structure, and downside protection cost. It does not name an alternative tool or state when not to use it, but the trigger conditions are specific enough to route most calls correctly.

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, so safety is covered; the description adds genuine context by stating the OI figures come from on-chain custody state, which tells the agent the data is authoritative/derived rather than estimated. It does not mention freshness/latency, rate limits, or the shape of the response, so with annotations doing the heavy lifting a 3 is right.

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, zero padding, and the trigger condition is front-loaded before the enumeration of returned data. Every clause earns its place by mapping to a distinct piece of output the agent can expect.

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 telling the agent what comes back, and the enumerated fields (OI, utilization, borrow rates, AUM/APR, volume, top traders) do that well. What is missing is any guidance on when history_days should be omitted versus set, though with both parameters optional that is a minor 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 both parameters are documented in the schema, so the baseline is 3. The description's final sentence ('Pass base and history_days for the hourly OI history') adds a small amount by implying the two interact — history_days yields hourly OI history for the chosen base — but it repeats rather than enriches the schema 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?

States a specific verb-by-implication ('call this when the user asks about') plus a precise resource: Jupiter perpetuals on Solana, with an enumerated list of the data it returns (long/short OI, utilization, borrow rates, JLP AUM/APR, volume, top traders). Naming Jupiter distinguishes it in substance from the generic siblings get_solana_perps and get_open_interest, but it never explicitly says how it differs from them, leaving some overlap for the agent to resolve.

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 a clear invocation trigger ('when the user asks about Jupiter perpetuals on Solana') tied to named user intents. There are no exclusions or explicit alternatives ('use get_solana_perps instead when...'), which keeps it below a 5 given the crowded sibling set of perps/OI tools.

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 description's job is supplementary and it delivers: it discloses the return shape (daily rows vs. whole-window summary), the lag range, and the rolling coverage window. It does not mention rate limits or data-source freshness, keeping it just short of a 5.

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

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

Three sentences, front-loaded with the trigger before the return description, then the parameter nuance. Nothing is redundant or padding.

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

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

With no output schema, the description must explain return values, and it does — lag structure, lead asymmetry, and per-venue share of leading days. Combined with the single optional well-documented parameter and read-only annotations, an agent has everything needed 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 baseline is 3; the description goes slightly further by explaining the consequence of the parameter — the default 7-day daily rows versus the whole-window summary, and that 'days' up to 30 extends coverage. It largely restates the schema's default/max, so the added value is modest.

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?

Names a specific analytical artifact (per-pair daily cross-correlations of one-minute returns at lags -3..+3 plus lead asymmetry) rather than restating the tool name. The venue-focus (Coinbase, Kraken, Binance) and spot-vs-perp framing let an agent tell it apart from generic correlation siblings like get_correlations.

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?

Opens with an explicit trigger: 'Call this when the user asks which exchange leads price discovery or whether spot or perp moves first.' That is a clear usage condition, but no exclusion or named alternative (e.g. get_correlations) is offered for overlapping questions.

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 only declare readOnlyHint and openWorldHint; the description adds real context beyond that — provenance (recorded daily by ByKaranteli), a change log alongside current tiers, and truncation behavior (first 30 rows / first 5 tiers, up to 300) so the agent can anticipate incomplete results.

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?

Triggers come first, then return contents, then parameter behavior — well front-loaded. The final sentence packs three conditional clipping rules together and reads slightly run-on, costing a bit of clarity.

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, yet the description enumerates the returned fields and the change log, and discloses pagination/clipping defaults. An agent has everything needed to call it and interpret the response without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description adds materially: it gives the base-asset convention for symbol (e.g. SOL), enumerates valid venue ids that the schema lacks (bybit, okx, gate, htx, bitget, mexc), and explains the symbol/limit interaction that the schema leaves implicit.

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 (leverage ladder per venue: tier, notional floor/cap, max leverage, maintenance margin) and the exact questions it answers, which cleanly separates it from siblings like get_fee_table or get_venue_profile.

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?

Opens with explicit triggers (leverage allowance per coin, maintenance margin/risk limit ladder, highest-leverage venue, recent leverage cuts), so an agent knows precisely when to select it. It also explains the consequence of omitting symbol versus supplying it.

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 readOnly and open-world behavior. The description adds valuable context beyond that: plan-based timeframe access, default capping to the 30 nearest levels and 30 largest prints, and what detail modes change.

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 invocation trigger and return summary, then adds plan and detail behavior. It is somewhat repetitive with the schema around detail modes, but the repetition is functional rather than noisy.

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, open-world analytics tool with no output schema, it explains when to use it, what the response contains, plan limitations, default truncation, and detail-mode behavior. An agent has enough context to 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?

Schema coverage is 100%, so the schema already explains detail, symbol, and timeframe. The description still adds useful default-output semantics, notably the 30 levels / 30 prints cap and how detail full or compact alters the result.

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 operation and resource: returns a LiqMap snapshot with modeled liquidation levels, zone aggregates, and real liquidation prints. It clearly distinguishes this from generic liquidation-list siblings by naming clusters/heatmap and one-symbol scope.

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 explicit user-intent triggers such as where liquidation clusters sit, where leveraged longs/shorts would be liquidated, or reading a liquidation heatmap. It does not explicitly compare against siblings like get_liquidations or get_liquidation_cascades, so it stops short of full routing 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 safety (readOnlyHint=true, openWorldHint=true), and the description adds non-obvious context: the totals are 'an honestly-labeled lower bound from a real liquidation tape,' which tells the agent the figures are flooring estimates derived from observed data. It stops short of disclosing lookback depth, incident count, or aggregation methodology.

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 tight sentences: trigger first, return payload second, data-quality caveat last. No filler, and the most decision-relevant information (when to call) 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?

With no output schema, the description carries the return-shape burden and does so by enumerating the incident fields. However, a zero-parameter tool gives the agent no control over scope, and the description never states the lookback window or how many incidents come back — relevant since the user's 'recent crash' may not match the detector's window.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description usefully fills the vacated space by describing what the parameterless call returns.

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?

Names a specific deliverable ('auto-detected cascade incidents') and enumerates the returned fields (timing, notional flushed, long/short split, leading coins, BTC move), which distinguishes it from the raw-tape sibling get_liquidations. It does not explicitly name siblings, and the phrase 'who got liquidated' partially overlaps with get_liquidation_leaderboard, so the differentiation is strong but not airtight.

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?

Opens with an explicit invocation trigger: 'Call this when the user asks what caused a recent crash or flush, about liquidation cascades, or who got liquidated.' That gives clear context for selection, though it states no exclusions or conditions pointing to alternative tools.

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, but the description adds materially useful context: the data comes from 'counted venues' public feeds', SELL means a long was liquidated, and Binance's one-print-per-second-per-symbol cap makes its rows a floor. Those caveats go beyond structured fields and prevent misreading the ranking as exhaustive.

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 trigger conditions before the return description, and no filler. The second sentence is long and run-on, packing rank/symbol/venue/side/price/quantity/notional/time into a parenthetical, but every element is informative.

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 must explain the return payload — it does so field by field and includes the heatmap dimensions and a data-quality caveat. What remains unstated is pagination/truncation behavior on limit and whether venue coverage varies by window, which are secondary for a read-only leaderboard.

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 each parameter already documents its meaning, default, and bounds, so the schema does the heavy lifting. The description reaffirms the 24h/7d/30d window and the days-to-heatmap relationship but adds no syntax or edge-case detail beyond what is structured.

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: the largest single liquidation prints plus a 30-day weekday-by-UTC-hour session heatmap, with explicit window options. It distinguishes itself from a generic liquidations feed by emphasizing 'largest single prints' and the clustering heatmap, though it never names which sibling to use instead.

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?

Opens with concrete triggering questions ('biggest liquidation today or this week', 'who got liquidated for the most', 'when in the day or week liquidations cluster'), giving clear context for selection. It stops short of exclusions, e.g. it does not say when to prefer get_liquidations, get_liquidation_cascades, or get_liqmap.

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

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

With readOnlyHint and openWorldHint already set, the description adds substantial behavioral context: the data comes from own stream collectors, represents recorded events as a floor rather than estimates, covers a list of venues on a coverage page, starts at a specific date, and grows daily. It also clarifies the rows-versus-summary behavior, which is important for interpreting results.

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 primary use case and return shape. It is dense but every sentence earns its place by covering provenance, limitations, granularity, history start, and pagination behavior.

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 query tool with no output schema, the description explains the return structure (daily long/short totals per symbol and exchange), the rows versus summary distinction, the history start date, and how to expand results. Nothing essential is 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?

Schema coverage is 100%, so the schema already documents default limits and ordering. The description adds useful meaning beyond the schema by explaining that without a symbol the rows array holds the first 30 rows while summary covers every matching row, and that passing symbol or limit returns more rows.

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: it returns daily long and short liquidation totals in USD per symbol and exchange. The granularity (one row per finalized UTC day, symbol, exchange) clearly distinguishes it from sibling tools like get_liquidation_cascades, get_liquidation_leaderboard, and get_liqmap, even without naming them 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?

It gives a clear triggering condition: call this when the user asks how much was liquidated, whether longs or shorts got flushed, or for liquidation history. It also explains how to get more rows via symbol or limit. However, it does not explicitly say when to prefer a sibling such as get_liquidation_cascades or get_liquidation_leaderboard instead.

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 real behavioral detail beyond that: the return consists of recorded daily series plus latest values, and omitting days yields only the newest 7 points per series, which is a meaningful default an agent must know. It does not discuss data freshness, source, or gaps.

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 trigger, then return shape, then parameter guidance. No filler. Slightly dense phrasing ("pass days for the daily series, and series for one key over a long window") but every clause carries information.

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

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

For a two-parameter, no-required-argument read tool with no output schema, the description covers trigger, return shape, and default window behavior. The only gap is that it does not enumerate or point to how an agent discovers valid series keys beyond the schema's note about the answer's series field.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds the interaction between the two parameters: days controls the daily series, series narrows to one key over a long window. That combination logic is not obvious from either schema field alone, so it earns above 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 resource (macro liquidity: Fed balance sheet, reverse repo, rates, stablecoin supply) and what it returns (recorded daily series and latest values). An agent can tell it is a macro-series reader rather than an on-chain or venue tool. It stops short of naming a sibling it could be confused with, such as get_series or get_tradfi_board.

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?

"Call this when the user asks about macro liquidity, the Fed balance sheet, reverse repo, rates or stablecoin supply in relation to crypto" gives an explicit trigger condition. It also tells the agent which parameter form to pick: omit days for short default windows, supply days for the daily series, supply series for one key over a long window. No exclusion of alternatives is stated.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond that: values are live and refreshed roughly every 30 minutes, and Fear & Greed includes today and yesterday. It does not describe error behavior or exact freshness guarantees, but the added cadence detail is meaningful.

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?

It is a single compact sentence that front-loads the use case and enumerates the returned data points. Every clause contributes useful selection or freshness information, with no repetition of 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 zero-parameter read-only tool without an output schema, the description is nearly complete: it lists the main values returned and notes refresh cadence. It could be slightly stronger by clarifying the exact shape or units of the composite/dominance values, but nothing essential to invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty at 100% coverage, so there is no parameter semantics burden. The description correctly does not invent parameter details.

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 specific indices (Fear & Greed, Bitcoin dominance, total market cap, Retail Euphoria) and a clear use context, so the agent knows exactly what data this tool returns. It does not explicitly contrast itself with similarly themed siblings such as get_altseason, get_cycle_indicators, or get_pressure_scores, which keeps it from 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?

It gives a clear trigger condition: 'when the user asks about overall crypto market sentiment or macro state.' That is strong usage context, but it offers no explicit exclusions or named alternatives for overlapping sentiment/macro tools.

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 only cover readOnly and openWorld; the description adds substantial behavior: data provenance (ByKaranteli's own one-minute Binance USDT-M bars), the exact construction (30-minute TPO periods, 0.05% buckets of the day's open, 70% value area, first-hour IB, volume POC), and a documented empty-result path ('no_profile'). It does not mention rate limits, latency, or whether the last 60-day naked-POC window is truncated by the days parameter.

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?

It is front-loaded with the activation condition and then the return payload, with no filler sentences. The second sentence is very long and dense with parenthetical method detail, which slightly hurts scanability but every clause carries information.

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

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

With no output schema, the description must carry the return shape, and it does: per-day rows, naked POCs, latest-day bucket profile, plus the no_profile failure mode. It is complete enough to invoke correctly; only the interaction between the days parameter and the fixed 60-day naked-POC window is left ambiguous.

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 (days 1..30 default 7, symbol pattern) are already fully documented, which sets the baseline at 3. The description adds context about what 'days' means in output terms (one row per closed UTC day, naked POCs over the last 60 recorded days) but does not reconcile how the 60-day naked-POC window interacts with the days cap.

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 first sentence names the specific resource (Market Profile / TPO profile) and enumerates the concepts it resolves — POC, value area, initial balance, naked POCs — which no sibling tool covers. A reader can tell this apart from get_venue_profile or get_series 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?

The description opens with an explicit trigger ('Call this when the user asks about a perpetual's Market Profile, TPO profile, POC...'), giving the agent a clear activation condition. It stops short of naming when NOT to use it or which sibling to prefer for adjacent questions (e.g. get_venue_profile, get_series).

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 read-only and open-world, and the description adds substantive behavioral detail: buckets under 30 days are suppressed, most metrics do not separate from the base rate, and the interpretation says so plainly. That is exactly the kind of caveat an agent needs before reporting a result to a user.

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 trigger, then the mechanics, then the honesty rules — a sensible order with no filler sentences. The trailing metric enumeration is long but functional, listing the namespace rather than restating the schema.

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

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

For a single-parameter read tool with no output schema, the description carries the full burden and does so: it describes the returned fields (median forward BTC return, up-share at +1/+3/+7 days, all-days base rate), the suppression threshold, and the interpretation caveat. Nothing needed to call or interpret 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?

Schema coverage is 100% with a pattern constraint and four example keys, so the baseline is 3. The description adds real value by enumerating the full accepted metric namespace (dvol_btc, vpin_btc, fred_* series, btc_* network series), which the schema only hints at.

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 — bucketing a metric's current value against its own daily history and returning forward-return statistics per bucket. Distinguishes itself from sibling lookups like get_series or get_market_profile by framing the output as conditional distribution vs. base rate.

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?

Opens with an explicit trigger condition: call it when the user asks if a reading is high/low or what happened after similar readings. It also sets an explicit boundary with 'History, not a forecast,' telling the agent what this tool is not for.

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 useful context the annotations lack — the node is blocksonly, mempool data is absent, and the default window is the newest 7 points. It stops short of describing response shape beyond 'recorded daily series and latest values'.

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 tight sentences, front-loaded with the invocation trigger, followed by what is returned and how the two parameters behave. Nothing is redundant enough to cut, though the parameter sentence is somewhat compressed.

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, no output schema and read-only annotations, the description supplies what is needed: the metric coverage, the data-source limitation, the default window, and the existence of a series key field. A note on the returned series keys or units would close the remaining 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 both parameters are documented there, so the baseline is 3. The description still adds interaction semantics the schema does not: days applies to the daily series, series selects one key over a long window, and omitting both yields 7 points per series.

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 — returns recorded daily series and latest values for Bitcoin hashrate, difficulty and block fees — and scopes it to the operator's own node. The blocksonly caveat explicitly distinguishes it from any mempool-based sibling, so an agent can pick it 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?

Opens with an explicit 'Call this when the user asks about...' trigger covering the three relevant metrics and an exclusion (no mempool series). It explains the no-args vs days vs series modes, but never names a sibling as an alternative for overlapping questions like fee tables.

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 and openWorldHint, so safety is already covered; the description adds real context beyond that -- the data comes from an hourly scan and spans every covered exchange, and the detail flag trades page size against completeness. It stops short of describing ordering, freshness lag, or result shape in any detail.

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: trigger first, coverage second, parameter guidance last. Every sentence carries distinct information and nothing is repeated from the annotations or the name.

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 the work of explaining what comes back (listings plus delistings across exchanges) and how 'detail' changes the payload. The one gap is the time-window dimension -- the 30-day default and the cut-off to the external dataset are left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces the 'detail' parameter's compact/full tradeoff in plain language, which is mild added value, but it says nothing about the 'days' window -- the 1-30 day constraint and the pointer to the external listings dataset live only 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?

The description names a specific resource (new and delisted perpetual contracts) and a specific scope (across every exchange the hourly scan covers), which no sibling tool covers -- get_jupiter_perps and get_solana_perps are venue-specific market views, not listing/delisting feeds. The opening line maps directly to user question phrasing, so the tool's role is 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?

It gives explicit user-question triggers ('what new perpetuals were listed', 'which exchange listed a coin first', 'about delistings') that tell an agent exactly when to reach for it. It does not name an alternative tool or state when NOT to use it, 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 cover the safety profile (readOnlyHint, openWorldHint), yet the description still adds meaningful behavior: 5-minute resolution, the exact deltas returned, and the five regime labels the output can take. It omits any note about how fresh the data is, which symbols are covered beyond 'major perps', or rate 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?

Two sentences, no filler: the first front-loads the trigger conditions, the second front-loads the return shape. Every clause carries information an agent would otherwise have to guess.

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 no output schema and no parameters, the description does the heavy lifting by specifying resolution, deltas, and regime categories, which is enough to decide relevance and interpret results. A brief note on the symbol universe or refresh cadence would close the remaining 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?

With zero parameters and 100% schema coverage, the baseline is 4, and the description correctly signals that results are returned per symbol rather than requiring a symbol argument. No further parameter meaning is needed or missing.

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 (5-minute open interest with 24h OI and price deltas) and a distinctive analytical output (four-regime read per symbol), so an agent knows exactly what comes back. It stops short of naming which sibling (e.g. get_funding_heatmap or get_positioning) to prefer, so differentiation is implied by the regime framing rather than stated.

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 three concrete trigger questions – leverage entering/leaving, OI changes, longs vs shorts building – which is strong when-to-call guidance. It offers no when-not-to-call conditions and does not point to a competing tool for adjacent questions like funding or liquidations.

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

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

With readOnlyHint and openWorldHint already declared, the description adds real value: it discloses the data source (own hourly capture across every listed venue), plan gating (Free = largest strikes, Builder+ = all strikes), and a hard history boundary (recorded from 2026-09-30, so early days have short history). It does not cover payload shape, pagination, or latency, but with annotations carried elsewhere a 3 fits.

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 but well-ordered block: trigger first, payload second, plan/history caveats last. Every clause carries content (source, fields, plan limits, history start), though the sentence runs long enough that an agent must parse carefully.

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 analytical tool with a fully described 4-param schema and no output schema, the description covers the trigger, the returned fields, the venue scope, plan-tier limits, and the history truncation caveat. The main remaining gap is a sense of response shape/granularity (row-per-strike-per-hour vs. summary), which is only 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 100% and three of four params are enums with their own descriptions, so the schema does the heavy lifting and the baseline applies. The description adds only the plan-constrained meaning of strikes=all and the default-every-expiry behavior, which is marginally useful but largely redundant with 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 trigger and resource: 'when the user asks how the BTC or ETH option chain moved today or over the last day', plus the exact payload (OI and mark IV per expiry/strike, 1h/24h change, front-expiry ATM IV path). This implicitly separates it from snapshot-style siblings like get_options_snapshot and get_iv_surface, but it never names those siblings 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?

Gives an explicit, actionable call condition ('moved today or over the last day'), which is more than most siblings offer. It stops short of naming alternatives or stating when another options tool (snapshot, flow, IV surface) is the better choice.

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 open-world, so the safety profile is covered; the description still adds genuine behavioral context beyond them. The net-of-sold-legs explanation ('a spread counts its net premium') is a real methodological disclosure that prevents misreading the call/put premium split, and the 15-minute refresh cadence plus the Deribit/OKX venue scope tell the agent how fresh and how broad the data is.

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 usage trigger, then the return payload, then freshness, then the parameter — a sensible order. It is dense but nearly every clause carries information (venue, 48h window, net premium, cadence); only the trailing detail-parameter sentence is redundant with the schema.

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

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

With no output schema, the description carries the return-value burden and does it well: it enumerates the four returned quantities and the fields on each print, plus refresh cadence and data sources. The one gap is asset coverage — BTC/ETH scope appears only in the title, not the body, and there is no symbol parameter to narrow it, so an agent could over-generalize the universe.

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%, and the parameter's own description already spells out compact vs full, the trimmed list, and the 100,000-character ceiling. The description's sentence 'Pass detail "compact" for a shorter page or "full" for the whole answer' restates the schema with no added syntax, default, or interaction detail, so 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 concrete verb-plus-resource with unusual specificity: it returns 24h call vs put premium, block-trade share, multi-leg structure count, and the largest prints of the last 48h with strikes, IV, structure id and venue. That scope is clearly distinct from a point-in-time options snapshot or chain listing. It never names a sibling tool, so an agent must infer the boundary with get_options_snapshot, get_options_chain and get_iv_surface.

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?

Opens with an explicit invocation trigger — 'Call this when the user asks what big options players are buying, about block trades, or whether call or put premium dominates today' — giving three concrete question patterns. There are no exclusions or named alternatives, so an agent asking 'what is the option chain' or 'what's IV now' gets no routing 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 state readOnlyHint and openWorldHint, so the description correctly focuses on behavior beyond safety: the data is a daily snapshot (not intraday), venues are summed by default, 'DVOL is Deribit's index whatever the venue' is a real caveat, and max pain is flagged as 'not a price target'. These are genuine additions, though there is no coverage of latency, rate limits or data staleness.

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 trigger phrase is well front-loaded, but the second sentence is an enormous run-on that strings a dozen returned fields together with parenthetical explanations. It remains readable, yet the field inventory reads as a data dictionary and would be tighter as a structured list.

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 full burden of explaining return contents, and it does so thoroughly: walls, top OI strikes, put/call ratio, dealer hedging map, ATM IV by expiry with iv_source provenance, venues_included, per-expiry max pain and one-sigma implied move. An agent knows what it will get back before calling.

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% and the venue enum is fully documented in the schema. The description only restates the default-summing behavior and the meaning of the venue switch, which slightly clarifies semantics but adds little the schema does not already say.

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 concrete resources: call/put walls, GEX, zero-gamma level, DVOL, IV term structure, max pain, and per-expiry open interest, framed as a daily aggregated snapshot across venues. That specificity is enough to separate it from chain-level or surface-level siblings such as get_options_chain or get_iv_surface, even though those are not 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?

The opening sentence is an explicit trigger list ('call this when the user asks where the big options bets sit, about call/put walls, gamma exposure...'), which gives a clear when-to-use signal. It does not state when NOT to use it or name a preferred alternative for raw chain or IV-surface queries, so it falls short of a 5.

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

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

Annotations only declare read-only and open-world; the description goes well beyond by specifying the bucketing scheme (0.1% bins within 20% of mid, USD notional), the fixed coin universe, and the important caveat that uncorroborated books are returned with in_aggregate=false and held_out but excluded from aggregates. That held-out behavior is exactly the kind of non-obvious trait an agent must know before quoting numbers.

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 triggering conditions before the payload description, so the most decision-relevant content comes first. It is dense and runs as one long block, which makes it slightly harder to scan, but essentially every clause (bucket size, coin list, held_out rule) carries operational 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?

No output schema exists, yet the description fully characterizes the return payload (binned book, walls with venue split, 2% depth, book reach, optional history) and the per-venue exclusion flag. For a two-parameter read-only tool, nothing an agent needs to call it or interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both params are self-documented, so the baseline is 3. The description adds real meaning by enumerating the supported coins (BTC, ETH, SOL, XRP, DOGE, ADA, LINK, AVAX, LTC, BNB) – information the schema only implies via a regex pattern – and by clarifying that hours enables the optional 5-minute summed history.

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 (spot order book depth across all venues on the coverage page) and enumerates exactly what it yields: 0.1% binned book, largest walls with venue split, 2% depth and book reach. This is clearly separable from siblings like get_liqmap, get_market_profile or get_slippage 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?

Gives four concrete user-question triggers ('where are the bid or ask walls', 'how deep is the book', 'buyers or sellers have more resting orders', 'order book heatmap'), which is strong positive routing. It stops short of naming an alternative tool or stating when not to use it (e.g. perp books vs spot), so it does not reach 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 and openWorldHint, but the description adds real behavioral context the annotations don't: a 15-minute refresh cadence, the exact venue coverage list, and the default page shape when no symbol is given. It stops short of describing error behavior or what happens when a venue is unreachable, so not a 5.

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

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

Front-loaded with the trigger condition, then returns, then defaults, then parameters — a sensible information order with essentially no filler. It is a single dense paragraph, though, and the venue enumeration is long enough that slightly tighter structure (or bulleting) would scan better.

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 carries the return-value burden and does: venue-by-venue contents, CVD coverage limited to BTC/ETH/SOL, the 100,000-character ceiling note on 'full', and the trimmed-field reporting on 'compact'. An agent has everything needed to call this 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 the baseline is 3, but the description earns an extra point by stating the coupled defaults — no symbol yields the 10 most traded perps plus 24 newest CVD points, and passing symbol/limit/cvd_points widens that. The detail enum is explained in the description as well as 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?

Names the exact analytics returned (long/short ratio, taker buy/sell ratio, CVD) and the exact population (Binance USDT perps across every recorded venue), with venue-level enumeration. This is clearly separable from siblings like get_cot_positioning or get_pressure_scores without opening a schema.

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

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

Opens with an explicit invocation trigger: 'Call this when the user asks about the long/short ratio... net long or short... taker buy/sell ratio, or CVD for a perpetual.' It further routes between the default view and the symbol/limit/detail variants, so the agent knows both when to call it and how to shape the call.

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 operation. The description adds useful behavioral context: each symbol gets a composite score from funding, 1h/4h/24h OI deltas and basis, plus a LONG/SHORT/NEUTRAL direction and a regime label. It does not discuss rate limits or auth needs, so it is strong but not exhaustive.

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

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

Three sentences, all front-loaded and purposeful. The trigger, the alternative tool, and the returned content each appear without 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?

For a two-parameter, no-required-filter read tool with full schema coverage and annotations covering the safety profile, the description supplies everything else an agent needs: when to call it, the main alternative, and what the output contains.

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 both limit and symbol are already well documented in the schema. The description does not add syntax, defaults, or filtering semantics beyond what the schema provides, which is the baseline expectation 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 verb and resource: it returns a 0-100 derivatives pressure/stress score per symbol. It explicitly distinguishes itself from get_top_movers, the sibling used for a quick top-10 ranking, so an agent can separate the two without reading either 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 explicit trigger conditions: user asks which coins are crowded/over-leveraged or asks for pressure scores of specific coins. It also names the alternative tool, get_top_movers, and the condition that selects it.

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 readOnlyHint and openWorldHint, the description discloses that inputs are proprietary, outcomes are always published, and the result includes a score, state interpretation, stress locality, alarms, and scorecard. It also sets expectations by stating it is not a trade signal or crash predictor, though it does not mention freshness 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?

The description is front-loaded with the call trigger and then explains returns, state meanings, and caveats. It is longer than a minimal definition but every part is useful for interpreting the proprietary state labels.

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 return-value explanation and does so sufficiently: Psi score range, four state meanings, stress locality, recent alarms, and year-split scorecard. It also discloses proprietary inputs and interpretation limits, making it complete enough for a zero-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is no parameter semantics burden beyond the schema itself. The description appropriately avoids inventing input details and focuses on triggers and outputs.

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 output: the market's hidden liquidity state via PsiCharge, including the Psi score and state labels. It clearly distinguishes this from a trade signal or crash predictor, but does not explicitly compare it to sibling tools such as get_macro_liquidity.

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 a clear trigger: call this when the user asks about hidden liquidity state, PsiCharge, or deploying parked money versus unwinding stress. It does not name alternative tools or explicit when-not-to-use conditions beyond saying it is not a trade signal or crash predictor.

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 only declare readOnlyHint and openWorldHint; the description adds substantive context: this is a daily measurement from ByKaranteli's own Bitcoin Core node, and it details returned fields including exposed BTC share, script-family composition, dormancy cohorts, dormant-P2PK watch set, and provenance hashes. This gives the agent a clear sense of data provenance and verifiability.

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: the first front-loads the call conditions, the second efficiently enumerates the payload. No filler, and 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?

Without an output schema, the description carries the full burden of explaining return values and does so thoroughly, covering the main metrics, composition, cohorts, watch set, and provenance hashes. An agent has enough information 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?

The tool has zero parameters and an empty schema, so there are no parameter semantics to explain; baseline 4 applies. The description does not need to compensate for missing 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?

States a specific verb-resource pair (get quantum exposure) and a precise domain: daily first-party measurement of Bitcoin vulnerable to quantum computing. No sibling tool covers quantum exposure, so an agent can distinguish it immediately.

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 lists the user questions that should trigger the tool: how much Bitcoin is vulnerable to a quantum computer, quantum-exposed supply, P2PK coins, and Satoshi-era exposure. It does not name alternatives or exclusions, but none of the sibling tools overlap with this domain.

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 and the description is free to spend its words elsewhere. It does exactly that: live board scope, the top-400 volume cutoff, the default 30-row window, the 400-row ceiling, and the semantics of asc vs desc ordering. What it omits is refresh cadence and per-row field composition, which is meaningful but secondary for a read-only board.

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 trigger is front-loaded in the first clause, followed by return scope, then filtering/sorting, then pagination defaults, which is a sensible information order. It is a single dense paragraph with no filler sentences. A light break into trigger / returns / paging would have made it scannable rather than a run-on.

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 correctly carries return-value burden by stating that it returns the live board plus overbought/oversold counts per interval. Combined with the fully documented 5-parameter schema and read-only annotations, an agent has enough to invoke it correctly. Remaining gaps are refinement-level: the per-symbol row shape and what happens if symbol is outside the top-400 universe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the per-parameter baseline is already a 3. The description goes beyond the schema by explaining parameter interaction: that limit only matters in the absence of symbol, that the default slice is volume-ordered unless sort is given, and that order asc combined with sort yields most-oversold-first. That crossover behavior is not stated in the schema and is where mis-calls would otherwise happen.

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 concrete resource and metric (Wilder RSI(14) heatmap across eight named timeframes) over a defined universe (top-400 Binance crypto perps by volume plus every TradFi perp). That level of specificity separates it cleanly from lookalike siblings such as get_funding_heatmap, get_tradfi_board and get_top_movers without opening any schema.

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

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

The opening clause gives explicit trigger conditions ('when the user asks which coins are overbought or oversold', multi-timeframe RSI, or one contract's RSI on a named interval), which is strong when-to-use guidance. It also explains the default path (no symbol -> first 30 rows) and the escalation path (limit up to 400, order asc + sort for most oversold first). It stops short of naming when-not-to-use or a specific alternative sibling, which keeps it off 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 readOnly and openWorld annotations, the description discloses the response shape, provenance fields, plan-based depth restrictions, the 403 history_member_only error, and the daily-price exception. This is unusually rich behavioral context for an agent.

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 when-to-use guidance and remains information-dense throughout. It is long and somewhat repetitive about plan-based depth and the public 300-bar window, but most sentences carry necessary operational detail.

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 seven-parameter tool with no output schema, the description is highly complete: it covers return format, metric enumeration, defaults, pagination/window semantics, venue behavior, and plan-gated errors. An agent has enough information to invoke it correctly in normal and edge cases.

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?

Although schema coverage is already 100%, the description adds substantial meaning: it lists all supported metric values, explains venue and period behavior, and clarifies how from, to, and limit interact with the default 300-bar window and plan caps.

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 the history of one recorded metric for one perpetual as a time series. It enumerates the supported metrics and clarifies the time-series scope, which distinguishes it from snapshot-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?

It clearly says when to call the tool, including charting, backtesting, and 'what did X do over the last N days' use cases. It also explains defaults and plan-based limits, but does not explicitly name alternative sibling tools or when not to use this one.

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 real value on top by disclosing the 60-day horizon, the 54-venue source, the two separate result lists and their sort orders, and the default page size of 30. It omits failure behavior and any rate-limit or coverage caveats, which keeps it out of the 5 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?

Two sentences, front-loaded with the invocation triggers before the return description, with no filler. It is dense and the defaults sentence is long, but each clause carries information an agent needs.

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-optional-parameter read tool with no output schema, the description supplies the return shape (two grouped lists), the horizon, the default and maximum sizing, and the scoping effect of base. Only the exact field-level payload remains unspecified, which is acceptable without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, and the description genuinely adds semantics: base selects one asset's full lists and lifts the row cap, limit only applies without base and caps at 300. The per-list sort direction (expiries soonest first, settlements newest first) is not derivable from the schema alone.

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

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

States a specific verb and resource set: expiries of dated futures and options plus the settlement prices recorded at delivery, grouped by date, venue and underlying. An agent can distinguish this from near-siblings such as get_options_chain or get_venue_markets because the scope is explicitly 'expiring contracts and their final settlement prices', not live chains or venue metadata.

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?

Opens with four concrete invocation triggers ('expire soon', 'next quarterly expiry on an exchange', 'how many contracts settle this week', 'at what price a dated future settled'), which is strong context. It does not name a when-not case or an explicit alternative tool to prefer, so it stops short of the top band.

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 readOnly and openWorld, and the description adds meaningful behavior: it uses the full visible order book, excludes fees, and explains that null means the book cannot absorb that size. That gives an agent enough behavioral context to interpret edge cases 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?

Two dense sentences with no wasted text. The usage trigger is front-loaded, followed by return scope and important exclusions, so an agent can act on the first sentence and refine interpretation with the second.

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, but the description explains the return shape well enough: basis-point cost ladders, sizes from $10K to $5M, both sides, 8 perps, fees excluded, and null semantics. It is nearly complete for a read-only no-parameter tool, though it does not mention response formatting or ordering details.

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?

There are zero input parameters, so parameter semantics are inherently minimal and the baseline is 4. The description does not need to explain parameter formatting, but it usefully clarifies the size range and market coverage that shape the result.

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

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

States a specific verb/resource (slippage/cost for market orders) and scopes it to live execution cost across 8 major perpetuals, both sides, $10K to $5M. This clearly distinguishes it from a generic orderbook-depth tool by framing the output as cost ladders in basis points.

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 says when to call it: when the user asks how much slippage a trade would face, how thick the books are, or which major perp is thinnest. Those are concrete triggering conditions, not vague suggestions.

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 only declare readOnlyHint and openWorldHint; the description adds substantive behavior beyond that: the board is refreshed every 10 minutes, open interest is one-sided except on pool venues where it is both sides, medians are hourly rates, and history depth is plan-gated (7 days Free, 30 on Builder+). Those are exactly the operational constraints an agent needs before promising data to a user.

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 correctly: trigger conditions first, return shape second, parameter behavior last. However, it is delivered as one dense run-on with stacked parentheticals (venue aliases, plan tiers) that takes effort to parse; a couple of breaks would preserve all content with less friction.

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 full burden of return-value disclosure and does so thoroughly: per-venue totals with named fields, per-market rows ordered largest first with instrument type taxonomy, and the optional history series. Nothing an agent needs to call this correctly or describe results to a user is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so field-level meaning is already carried by the schema. The description still adds real semantics: without a venue you get the 30 largest markets, passing venue or raising limit (up to 300) widens it, and symbol defaults to Pacifica when venue is absent. It does not explain how symbol and history_days interact when symbol is supplied without history_days, which keeps it below a 5.

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 (reads the Solana perps board) and enumerates the exact scope: six named venues, per-venue totals, per-market rows, optional hourly history. It explicitly separates itself from the sibling get_jupiter_perps for Jupiter history, so an agent can route without opening either 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?

Opens with an explicit trigger list ('when the user asks about perpetuals on Solana as a whole, which venue has the most open interest or volume, a market on Pacifica/Phoenix/...'), and names the alternative tool for the one case this one does not cover (Jupiter history). When-to-use and when-to-use-something-else are both present.

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 openWorldHint annotations, the description discloses the return structure: eight equal-weight baskets, rebasing to 100 on 2025-01-01, multiple return windows, BTC comparison, member lists, and conditional omission of daily points. This gives the agent substantial behavioral context needed to set expectations and invoke include_points 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 front-loaded with the invocation trigger and follows with the return composition and parameter behavior. Both sentences carry necessary 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?

For a read-only tool with one optional boolean, no output schema, and full schema coverage, the description provides enough detail about when to call it, what the indices represent, what data is returned, and how include_points affects output. Nothing critical for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so include_points is already documented, but the description adds useful default semantics: daily points are omitted unless include_points is true. That goes beyond the schema's wording and clarifies actual call behavior.

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: eight equal-weight fixed-basket crypto narrative indices, and enumerates the covered themes. It distinguishes this from generic market or single-theme tools by describing narrative/sector rotation and theme-index output, not raw exposure or broad market data.

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

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

It gives explicit user-intent triggers such as asking which crypto narrative is leading, rotation between named narratives, or requesting a theme index. It does not name when-not-to-use cases or explicitly route to alternatives like get_market_indices or get_quantum_exposure, so it falls short of full 5-level 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 only say readOnly/openWorld; the description adds substantial context beyond that: a 10-minute refresh cadence, the provenance rule for wrappers, the meaning of price_source values (reference / issuer_oracle / wrapper / null) and what totals.priced_by counts, and the 100,000-character ceiling behaviour with a suggested narrowing strategy. This is exactly the kind of behavioral detail annotations cannot carry.

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 trigger is correctly front-loaded, but the body is a dense run-on: the first sentence alone packs an issuer list, four question types and a return summary. Several clauses (the issuer enum restated inline, the detail-mode recap) repeat what the schema already says, inflating length without adding selection value. Information-dense but not disciplined.

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, yet the description specifies the return payload in usable detail: per-wrapper fields (issuer, chain, price, premium_pct, DEX liquidity, 24h volume, supply in shares and dollars, holders, status), exchange spot pairs, perpetual futures cross, and aggregate totals. An agent can answer 'what will I get back' without calling the tool first.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema already documents top, chain, detail and issuer. The description still earns credit for clarifying the underlying parameter's cardinality effect (3 wrappers default vs. all when passed) and for restating detail modes in operational terms ('a shorter page', 'still under the 100,000 character ceiling'). Minor duplication of the schema's detail text keeps it off a 5.

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 an explicit trigger and names the precise resource (tokenized stocks / stock tokens) plus the concrete issuers it covers, then enumerates what the tool answers: onchain supply, issuer/chain dominance, premium to the real share, DEX pools and exchange pairs. No sibling tool covers this domain, and an agent can tell instantly whether a query belongs here rather than to get_tradfi_board or get_venue_markets.

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 a clear when-to-use condition (user asks about tokenized stocks, listing recognisable brand names an agent can pattern-match on) and a scoping rule: 'Without underlying, each stock lists its first 3 wrappers and 3 exchange pairs; pass underlying for all of them.' It also states a negative constraint ('Wrappers come from issuer sources only, never from a name search'), which pre-empts a wrong expectation. What it lacks is explicit routing away from any other tool, though no sibling is a real alternative.

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 declare this as a read-only, open-world operation, so the description's most valuable addition is the output shape: four top-10 lists returned in one call. That tells the agent this is a batch summary rather than a paginated or single-result query. It does not state freshness or refresh cadence, which keeps it below a 5.

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

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

Two sentences, both earning their place. The use-case triggers come first, and the return shape is stated last in a single compact clause.

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 parameters and no output schema, the description must carry the return-shape burden, and it does at a high level by specifying four top-10 lists. It doesn't enumerate exactly what fields each list contains, but that is a minor gap for a screening tool whose title already names the four dimensions.

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?

This tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool applies, and the description correctly avoids inventing parameter-like 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 names a specific capability: a screener that surfaces four derivative market extremes (OI changes, funding, basis, stress) in one call. That is clearly distinguishable from single-metric siblings such as get_open_interest or get_funding_heatmap because it advertises an aggregated cross-metric view rather than one series.

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 concrete trigger phrases ('what is moving in crypto derivatives right now', biggest OI changes, extreme funding, widest basis, highest stress), which maps directly onto user intents. It does not explicitly name which sibling to use instead for a single-metric deep dive, but the intended usage context is unusually 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 real behavioral context: the full return payload, the default paging rule (first 30 by open interest), and that limit can go to 150. It doesn't mention rate limits or data freshness/latency, which would round it out.

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 trigger condition, then the return payload, then the parameter rules — a logical order. The parenthetical symbol examples are slightly dense but all serve disambiguation; only minor trimming is possible.

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, but the description enumerates the returned fields, the market filter options, the default and maximum result counts, and the session-state information. An agent has everything needed to call it correctly and interpret the result 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 coverage is 100%, so the baseline is 3. The description earns above baseline by explaining the interaction between the params: 'Without symbol, the first 30 contracts by open interest; pass symbol, or limit (up to 150) for more,' which is behavioral meaning the schema alone doesn't convey.

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

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

States a specific verb and resource: 'Returns Binance's TradFi perpetual board' with an enumerated field list (mark, index, basis, funding, OI, liquidations, session state). This clearly distinguishes it from siblings like get_tokenized_stocks, get_open_interest, or get_market_indices.

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?

Opens with an explicit trigger list ('Call this when the user asks about stock perpetuals, tokenized-equity perps, funding rates, OI, liquidations, which exchanges list a stock perp, or whether the equity session is open'). It doesn't explicitly exclude or route to the nearest siblings (get_tokenized_stocks, get_open_interest), which keeps it from a 5.

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