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

Annotations only cover the safety profile (not read-only, idempotent, non-destructive). The description adds the real behavioral payload: which events fire alerts, that the first sight is a silent baseline, that it consumes a plan address quota, and the exact failure signals terminal_required / limit_reached. This is substantive disclosure beyond structured fields and consistent with the annotations.

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

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

Three sentences, each carrying distinct load: trigger, alert semantics, and quota/error behavior. The most decision-relevant clause (when to call) is front-loaded with zero filler.

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

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

With no output schema, the description still explains what a successful add produces (silent baseline, then alerts) and what the two failure outcomes mean, which is exactly what an agent needs to report back. Nothing material 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 description coverage is 100%, so both address and label are already documented, including the 0x + 40 hex format the description repeats. The description adds nothing about the optional label or defaults, 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 action (follow/track a Hyperliquid address for position alerts) and the trigger phrasing an agent will see. The Hyperliquid-address scope plus the position-change alerting behavior clearly distinguishes it from add_watchlist_symbol and create_alert_recipe in the sibling list.

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 when-to-use trigger ('when the user asks to follow, track or get alerts for a Hyperliquid address') and names the contrasting siblings implicitly via the lifecycle (list_tracked_addresses, remove_tracked_address). It does not state when-not to use it or a direct alternative, but the invocation 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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the basic safety profile. The description adds useful behavioral context beyond annotations: rate limiting per key, account-level recording of each write, and the fact that adding an existing symbol leaves it in place only 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?

The description is front-loaded with the trigger condition, then behavior, return value, and side effects in four efficient sentences. Every sentence adds relevant information with no repetition or waste.

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 mutation tool, the definition covers the trigger, target-list fallback behavior, idempotent handling, return value, rate limits, and account auditing. With full schema coverage and helpful annotations, an agent has enough context to call it correctly 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 the schema already documents both parameters. The description still adds fallback semantics for watchlist_id: if omitted, the symbol goes to the default list or the only list the account has, which is slightly more informative than the schema's default note.

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

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

The description uses a specific verb and resource: adding a symbol to a watchlist, with clear account-level scope. It is immediately distinguishable from sibling tools like remove_watchlist_symbol and list_watchlists without needing to inspect 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 explicitly says to call it when the user asks to watch, follow, or add a coin to their watchlist, which gives clear usage context. It does not name when not to use it or explicitly route to alternatives such as list_watchlists or remove_watchlist_symbol, so it falls short of full alternative 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 cover safety flags (not read-only, not destructive, not idempotent); the description adds genuinely new behavior — all-conditions-must-hold semantics, Telegram-first with email fallback, cooldown_hours gating per symbol, account plan recipe limits and the limit response, plus per-key write rate limiting and account auditing.

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, and each sentence carries information (units, limits, fallback, enums). It is dense and the long inline field enumeration makes it heavy, but nothing is 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?

For a 9-parameter, zero-required mutation tool with no output schema, the description covers trigger, condition model, delivery, cooldown, scoping, unit conventions and quota/error behavior — an agent needs nothing else 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 already 100%, but the description still adds value the schema lacks: the full enumerated field list (schema only gives 'e.g. funding_rate_pct'), the op set, the percent-unit convention ('0.05 means 0.05%'), the either/or of field+op+threshold vs conditions (max 6), and the channels-empty fallback. Slight overlap with the schema's own enum docs keeps it from a perfect 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?

Specific verb+resource ('Saves an alert recipe on the account') plus the exact trigger semantics — fires when every condition holds. It is clearly distinguishable from parse_alert_text, list_alert_recipes and delete_alert_recipe among the siblings.

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

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

States the precondition precisely: call when the user asks to be alerted on a threshold AND has agreed to the exact condition, and explicitly routes text parsing to parse_alert_text. That is a when-to-use plus an alternative, which is the top of the range.

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 destructive=true, idempotent=true and readOnly=false, so safety is covered. The description adds genuinely new operational context — per-key write rate limiting, that each write is recorded on the account, and that an unknown id is a silent no-op — though it doesn't say whether deletion is reversible.

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?

One dense paragraph, front-loaded with the trigger condition and the core action. The trailing clause about rate limits and audit recording is slightly run-on but each 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?

With no output schema, the description still explains the important response behavior (unknown id 'changes nothing and says so'). For a single-param destructive tool with rich annotations, only the reversibility question is left open.

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 there is a single required param, so the schema already documents 'id' as the recipe id from list_alert_recipes. The description reinforces provenance but adds no syntax or format detail beyond it; 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 precise verb+resource ('Deletes the alert recipe with this id from the account') and scopes it to the caller's own account, distinguishing it from create_alert_recipe and list_alert_recipes. 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?

Explicit when-to-use ('Call this when the user asks to remove an alert') plus a direct pointer to list_alert_recipes as the source of valid ids. It also clarifies the no-match behavior so the agent knows an unknown id is not an error path.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds substantial behavior beyond that: the exact index formula (share of top 50 Binance perpetual altcoins beating BTC over trailing 90 days), the altseason/bitcoin-season thresholds (>=75 / <=25), the inclusion of strongest/weakest alts, and the caveat that daily history is 'never reconstructed.' This is rich, honest behavioral disclosure.

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

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

The description is a single well-structured sentence that front-loads the user-intent triggers before the return details. Every clause carries useful information: formula, thresholds, return contents, and the reconstruction caveat. No filler or redundancy.

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

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

With no parameters and no output schema, the description carries the full burden and fulfills it: it covers when to call, what the indicator measures, how the index is classified, what outputs to expect, and a data-quality warning. Nothing essential is missing for an agent to decide whether and how to invoke this tool.

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

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

The tool has zero parameters and the schema is 100% covered with an empty properties object. There are no parameter semantics for the description to clarify, so the baseline of 4 applies; the description already explains what data will be returned.

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 explicit call conditions ('Call this when the user asks whether it is altseason, how altcoins are doing against Bitcoin, or about market rotation') and precisely names the resource: the live Altcoin Season Index plus recorded history. It also defines the index calculation and thresholds, making the tool's purpose unmistakable and clearly distinct from generic market index tools.

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

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

The description gives strong, explicit when-to-use guidance: altseason questions, altcoin-vs-Bitcoin performance, and market rotation. It does not name alternative sibling tools or state when not to use it, so it stops short of full exclusionary guidance, but the provided context is sufficient for correct routing in most cases.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to re-state safety. It adds valuable context beyond annotations: return content (annualised rate, 30-day hourly series, carry table), data source (ByKaranteli), and venue coverage (Binance and OKX today). No contradiction, and it enriches the behavioral profile.

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

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

The description is a single paragraph with three sentences, front-loaded with the trigger conditions. It is efficient, though slightly packed with several trigger examples and detail. No fluff, but could be tightened without loss of meaning.

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 with no output schema, the description is complete: it specifies when to call, what data is returned, the time range, and the source. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, so the schema is trivially complete (100% coverage). The baseline for 0 params is 4, and the description doesn't need to explain parameters. It correctly omits parameter details, which is appropriate.

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

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

The description lists specific trigger questions (borrow cost, cheapest venue, stablecoin spike, basis trade carry) and names the exact resource (borrow rates per venue and asset). It clearly distinguishes from sibling tools like get_funding_arbitrage (funding arbitrage) and get_leverage_tiers (leverage tiers), which are about different concepts.

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?

Provides explicit 'when to use' conditions with concrete user queries. Does not mention when not to use or alternatives, but the context is clear and the tool is parameterless, so ambiguity is low. Missing exclusions keep 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.

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by detailing the output fields (daily premium, 7-day average, streak, last 30 days, carry yields) and the interpretation of positive premium as US buying pressure. No contradiction; it supplements the annotations with useful behavioral context.

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

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

The description is concise (four sentences), front-loaded with the usage trigger, then return values, then historical depth and interpretation. Every sentence contributes valuable information without 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?

Given no output schema and no parameters, the description fully covers what the tool returns (latest premium, averages, streaks, 30-day history, carry yields) and how to interpret it. It also mentions historical coverage since 2017, making it complete for this straightforward 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 has zero parameters, so the baseline is 4. The description does not need to explain inputs and instead focuses on output semantics, which is appropriate and sufficient for a parameterless tool.

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 defines the tool as a gauge for US buying/selling pressure via Coinbase Premium, explicitly naming the metric and the related carry yield. It distinguishes from siblings by referencing specific topics such as Coinbase Premium and cash-and-carry basis trade, which are unique among the sibling list.

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?

Provides explicit trigger conditions ('Call this when...') for user queries about US investor activity, Coinbase Premium, or carry trade yield. However, it does not mention alternatives or when not to use this tool, so it lacks exclusionary guidance that would elevate it to 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 provide readOnlyHint and openWorldHint, covering the safety profile. The description adds substantive behavioral detail: Pearson correlation, 30-day rolling window, daily returns, and top perpetuals as the universe. This meaningfully explains what computation the tool performs 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?

Two sentences, each earning its place: the first gives trigger scenarios and the second describes the output. No fluff, and the use cases are 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 parameters and no output schema, the description explains the return value well, including method, window, and data universe. It could be slightly more specific about what 'top perpetuals' means or how an agent extracts a pair-specific answer from the matrix, but for a zero-param tool this is largely 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?

The tool has zero parameters, so schema description coverage is trivially 100% and there is no param info to add. The description appropriately omits param details, and the baseline for zero-param tools applies.

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

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

The description names a specific verb and resource: 'Returns the 30-day rolling Pearson correlation matrix of daily returns across the top perpetuals.' It also lists concrete user intents (two-coin correlation, decorrelated pairs, alts tracking BTC), making it clearly distinguishable from the sibling analytics tools.

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

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

The description explicitly says 'Call this when the user asks' and gives three representative queries, which tells the agent when the tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for selection among the large sibling list.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: data source (official CFTC), update frequency (every Friday), and an important interpretation caveat about hedge fund shorts being basis trades. This helps the agent understand the data's nuance and reliability.

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

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

The description is compact—three sentences that front-load the call instruction, then detail the return contents, and end with a note. Every sentence serves a purpose with no 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?

Even without an output schema, the description names the specific data returned (net positions, week-over-week changes, open interest, extremes/streaks) and the source/update cycle. This is sufficiently complete for an agent to invoke the tool and interpret results correctly.

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

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

The tool has zero parameters, so the schema is empty. The description compensates by stating the scope (BTC and ETH CME futures) and the output dimensions, adding meaning beyond the bare schema. Baseline 4 for zero params 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 clearly identifies the tool's function: retrieving CFTC Commitments of Traders positioning data for Bitcoin and Ethereum futures. It distinguishes itself from sibling tools (e.g., get_etf_flows, get_open_interest) by focusing specifically on trader categories and the weekly COT report.

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

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

It explicitly states when to call: 'when the user asks how hedge funds or institutions are positioned in Bitcoin or Ethereum, or about the CFTC Commitments of Traders report.' This provides a direct trigger and implicitly differentiates it from alternatives like total open interest or ETF flow 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, and the description adds valuable behavioral nuance: the registry is 'live', includes freshness for each feed, and the caveat that 'snapshots[].country is the jurisdiction only when the venue states one; it is null for most venues, so do not read null as unknown risk.' This goes beyond the annotations and helps the agent interpret null values 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?

Three sentences, each with a distinct job: trigger conditions, return content summary, and a field-level caveat. No filler or repeated schema information, and the most important usage signal 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 explaining return values, and it does enumerate most major categories: liquidation feeds, snapshot feeds, funding arbitrage legs, positioning sources, whale tape, spot minutes, and Hyperliquid whale scan with freshness. It is complete enough to call and interpret the tool, though a more explicit shape or example would make it fully self-sufficient.

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

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

The tool has zero parameters, so the baseline is 4. The description never needs to explain parameter syntax or semantics, and the schema is trivially complete at 100% coverage.

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

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

The description clearly states the tool returns the 'live coverage registry' and enumerates its contents, so an agent knows it is a read-only metadata/inventory tool. It does not explicitly contrast itself with related siblings like get_venue_markets or get_venue_profile, but the title and content make the scope clear.

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 explicit trigger conditions: '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 strong usage guidance, though it stops short of saying when not to use this tool versus a sibling.

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 no destructive behavior needs disclosure. The description adds useful behavioral context beyond annotations: data is recomputed nightly from a first-party close record since 2012, the daily series is optional and large, and the output is explicitly 'Levels, not forecasts.'

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

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

The description is three sentences with no filler. The trigger is front-loaded, followed by return contents and a useful caveat. Every sentence contributes to effective tool selection or invocation.

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

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

Given no output schema, the description adequately describes what will be returned: latest readings, Pi Cycle cross dates, and optionally the daily series. It also states the data source and recomputation cadence. It could be slightly richer about the exact response shape, but the information needed to call the tool correctly is present.

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 parameters are already documented. The description adds value by flagging the daily series as 'large,' warning agents about response size when include_points is true, and by indicating that the default behavior is latest values and cross dates only.

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

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

The description opens with a specific trigger ('Call this when the user asks whether Bitcoin is near a cycle top or bottom') and enumerates the exact indicators covered, which clearly identifies the tool's resource and scope. It does not explicitly name a sibling alternative, but the indicator list is distinctive enough to separate it from the many market-data siblings.

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

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

The description gives explicit usage context by telling the agent exactly which user intents and indicator names should trigger this call. It lacks an explicit 'when not to use' or named alternatives, but the closing caveat 'Levels, not forecasts' helps set expectations about 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=true and openWorldHint=true, and the description adds substantial behavioral context beyond that: the 5-minute sealing cadence, Merkle root signing, Solana write and Base attestation, per-mode return shapes, and the meaning of result ANCHORED. This is rich, non-redundant transparency.

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

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

The description is dense but front-loaded with the primary decision trigger and then systematically explains cadence, call modes, and result interpretation. Every sentence earns its place given the tool's complexity, but the description is long and could be tightened without losing meaning.

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 values. It does so thoroughly: overview fields, proof contents (value, leaf, Merkle path, signed manifest, signature, anchors), catalog behavior, epoch selection, and the meaning of ANCHORED. Nothing essential is missing for an agent 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 individual parameters are already documented, but the description adds significant combinatorial semantics: no arguments yields the stream overview; feed plus asset yields a single record's proof; sequence alone targets one epoch; catalog lists feeds. This goes well beyond the schema and helps an agent choose the correct parameter combination.

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-resource pairing: retrieving an on-chain proof for a sealed ByKaranteli number. It clearly states the tool's role in the BYK Data Layer and is immediately distinguishable from the many market-data sibling tools because it is about verification/proofs, not metrics.

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 explicit when-to-use triggers: user asks whether BYK data can be verified or changed, asks about on-chain proofs, or wants the proof behind one sealed number. It also details different call modes (no args, feed+asset, sequence alone, catalog), but it does not explicitly name alternatives or when not to use this tool, so it slightly misses the 'when-not' 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses important behavior: returns one row per finalized US trading day and asset, lists the exact fields (net inflow, total net assets, cumulative inflow, value traded), states values are in USD, and notes roughly 14 months of history. This gives an agent a clear model of what the call will produce without contradicting the annotations.

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

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

The description is three sentences with no filler: a front-loaded trigger phrase, a concrete list of returned fields, and a useful history-length detail. Every sentence earns its place and the structure lets an agent quickly decide whether to invoke 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?

Even though there is no output schema, the description fully explains the return shape: one row per finalized trading day and asset, with all five key fields and currency. Combined with complete parameter documentation in the schema, nothing essential is missing for an agent to understand what the tool returns and how to call 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?

Schema description coverage is 100%, so the schema already documents both parameters fully, including the enum and the days range. The description adds slight context around the output rows being per trading day and per asset, which indirectly clarifies the parameters, but it does not materially elevate meaning 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 resource — US spot Bitcoin, Ethereum, and Solana ETF flows — and a concrete verb ('Call this when the user asks about...'). It covers the tool's key data types (daily inflows/outflows, cumulative flow, net assets) and its scope, making it instantly distinguishable from the sibling tools, none of which target 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 description explicitly states when to call the tool: when the user asks about BTC, ETH, or SOL spot ETF flows, including specific metrics like daily net flows, cumulative flow, and net assets. It gives clear invocation context but does not discuss when not to use it or name alternative tools, so it stops just short of full when/when-not guidance.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the n >= 30 gate, the median 7-day BTC move vs base rate, and that results are distributions rather than forecasts. This gives the agent meaningful expectations about the output without contradicting 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?

Two dense sentences lead with use cases and then describe the output format and qualifications. Every clause carries useful information, and the 'distributions, not forecasts' phrase is a compact yet critical disambiguation.

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 of explaining what the agent will receive: every recorded metric, its historical band, median 7-day BTC move, base rate comparison, and sample-size gate. This is sufficient for a no-argument read-only tool.

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

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

The input schema has zero parameters and 100% coverage, so there is no parameter semantics for the description to add. A baseline of 4 is appropriate because the tool takes no arguments and the description cannot meaningfully elaborate on 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 resource ('factor board') and the exact function: returning recorded metrics in their historical band with the median following BTC move. It distinguishes itself from siblings by emphasizing a cross-metric conditional overview and explicitly noting 'distributions, not forecasts.'

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 explicit trigger scenarios: unusual-band indicators, historical precedent for BTC moves, or cross-metric conditional overview. It does not name specific sibling alternatives or say when not to use this tool instead of another, but the 'not forecasts' clause offers a mild exclusion.

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

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

Annotations already mark the tool readOnlyHint=true, and the description adds useful behavioral context: it returns base tier fees, uses a median across pairs where venues price per pair, includes a fee change log, and is read daily from venue fee endpoints. This goes beyond the annotations without contradicting them.

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

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

Two sentences, front-loaded with the trigger conditions, followed by a compact data-source and output description. Every phrase adds value—there is no filler, repetition, or irrelevant 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 zero-parameter read-only tool with no output schema, the description fully covers what the agent needs: when to invoke it, what it returns, how data is aggregated, and how fresh the data is. Nothing critical is missing.

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

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

The tool has zero parameters, so the schema carries no burden and the description cannot add parameter-level detail. The description instead clarifies what the unfiltered response covers (all venues and market types), which is the appropriate compensation for a parameterless tool.

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 ('get'), the resource (trading fee schedules per venue), and the exact data returned: base tier maker and taker per venue and market type. It also lists concrete user intents, making it clearly distinguishable from sibling tools like get_venue_markets 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?

The description explicitly says 'Call this when...' and enumerates four specific query types: exchange fees, maker/taker comparisons, fee changes, and round-trip costs. It does not name alternatives or state when not to use it, but the context is clear enough for an agent 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 declare readOnlyHint and openWorldHint, but the description adds meaningful behavioral context: the VPIN scale (0=balanced, 1=fully one-sided), the 90-day percentile, the danger threshold, and the 24h average. It also notes that elevated readings historically precede volatility and warns that VPIN says nothing about direction, which goes beyond the annotation cues.

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

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

The description is two sentences, front-loaded with the 'Call this when' instruction, followed by a concise explanation of return values and interpretation. Every sentence earns its place with no fluff.

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 fully carries the burden of explaining return values and their meaning. It specifies the current VPIN, percentile, threshold, and 24h average, and provides interpretative guidance. The tool is simple (no params) and the description covers all necessary 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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details (there are none); it is adequate given the empty 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 clearly states the tool's purpose: detecting informed or toxic order flow via VPIN for BTC, ETH, and SOL perps. It uses specific verbs ('Call this when...') and distinguishes itself from sibling tools by focusing on VPIN and order-flow toxicity.

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 explicitly tells when to use the tool ('when the user asks whether informed or toxic order flow is building, about VPIN, or whether market makers are under pressure'). It doesn't name alternatives or state when NOT to use it, but the trigger context is very clear, and the 'VPIN says nothing about direction' caveat subtly hints at scope limits.

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 carry readOnlyHint=true and openWorldHint=true, and the description adds meaningful context beyond them: the closing caveat "Description, not prediction" tells the agent these are retrospective statistics rather than forecasts, preventing a whole class of misuse. It also discloses the data provenance ('measured from a minute-resolution record') and the statistical framing ('near a coin flip'). No contradiction with annotations.

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

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

Three sentences, each earning its place: the first front-loads usage triggers, the second enumerates return fields, the third delivers the critical epistemic caveat. No filler, no repetition of the title or schema, and the most important routing information comes first.

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

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

For a 0-parameter read-only tool with no output schema, the description is fully sufficient: it covers when to call, what data comes back, and how to frame the results. The one thing it omits (exact numeric formatting) is minor against the low complexity and the fact that annotations already cover safety.

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 with 100% schema coverage, so there is nothing to document; the baseline of 4 applies. The description instead productively covers return semantics — per-statement 5/30/60-minute BTC reactions, average move versus a normal half hour, up/down split, and next meeting date — which is the information the agent actually needs.

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 specific trigger scenarios — "what Bitcoin does on Fed days, how FOMC statements move crypto, or when the next FOMC meeting is" — and scopes the resource precisely as measured FOMC impact on Bitcoin. This clearly distinguishes it from the 33 siblings; no other tool in the list is FOMC-specific, so an agent can route correctly without opening schemas.

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 first sentence gives explicit, concrete when-to-use triggers phrased as call conditions. It doesn't name alternatives or say when not to use it, but for a 0-parameter informational tool the three trigger phrases are specific enough to make misrouting unlikely. This matches 'clear context, no exclusions'.

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

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

The description goes well beyond the readOnlyHint/openWorldHint annotations by explaining the universal venue coverage, the 12 major perps, and the calculation assumptions (net of taker fees and weekly rebalance cost). It also specifies what the tool returns, which is valuable behavioral context for a side-effect-free data tool.

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

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

The description is compact, front-loads the user trigger, and packs relevant scope/output details into two sentences. There is no filler and every clause adds useful information.

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

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

Given no input parameters and no output schema, the description is complete enough: it states when to call, what data is scanned, what the output decision is, and the cost assumptions. An agent can invoke this tool and interpret its result 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?

The tool has zero parameters, so the description does not need to explain parameter semantics. Schema coverage is trivially complete, and the 0-parameter baseline of 4 applies.

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

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

The description states a clear user-trigger and a specific analytical deliverable: identifying best long/short venue per symbol with gross and net APR. It names the domain (funding arbitrage, funding rate differences, delta-neutral carry trades) and describes scope, so it is easy to distinguish from siblings like get_funding_heatmap or get_fee_table.

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 explicitly says when to call the tool, listing three user-intent patterns. It does not name alternatives or state when not to use it, but the trigger conditions are clear enough for an agent to select 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 include readOnlyHint=true, which the description agrees with by describing a read-only query. Beyond that, it adds valuable behavioral context: contracts without a live funding print are skipped, returns include funding rate per settlement interval, 24h open interest change, and 24h price change, and positive funding means longs pay shorts. No contradiction with annotations.

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

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

Three sentences, each with a distinct job: trigger/scope, alternative routing, and return field details. It is front-loaded with the main use case and contains minimal redundancy, though the scope ('~30 most traded Binance perps') is restated in both the title and the return-spec sentence.

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 minimal annotations, the description carries the burden of explaining return values and behavior. It covers the data returned per symbol, the skip condition, the row count, and the meaning of positive funding. There is no missing information needed to invoke the tool correctly, aside from minor unit details for the 24h changes.

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% for the single optional symbol parameter, with examples (BTCUSDT or BTC) and the default behavior (omit to get all 30 rows). The description's mention of 'funding rate of one specific coin' aligns with the schema but does not add new semantic content, so 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 opens with the specific trigger ('when the user asks for the full current funding table...') and names the exact resource and scope (~30 most traded Binance perps, 28-30 rows). It also states the alternative for top-10 rankings (get_top_movers), distinguishing this tool from the closest sibling. The return fields are listed, making the tool's purpose 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?

Explicitly states when to call: for the full current funding table or the funding rate of one specific coin. It also gives an explicit exclusion: use get_top_movers for a pre-ranked top-10 of the most extreme funding rates. This is clear routing with no inference needed.

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 this as a read-only, open-world lookup. The description adds meaningful provenance and behavior: the universe is the largest accounts by equity on Hyperliquid's public leaderboard, scanned every five minutes, with levels being the accounts' own liquidation prices bucketed around the mark. It does not describe return shape or caveats.

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 usage triggers, followed by source/behavior details and then the parameter note. It is dense but each sentence serves a purpose, with minimal waste.

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, and the description compensates by explaining the data universe, refresh cadence, bucket logic, and archive behavior. It remains somewhat incomplete on the exact return fields, but it gives enough context 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 baseline is 3. The description adds some semantic context for hours by stating it returns the hourly archive of level totals, though it adds little beyond the schema for the coin parameter.

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

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

The description states a specific resource: the liquidation price map of the largest tracked Hyperliquid accounts, per coin. It distinguishes itself from get_liqmap by framing the data as account-level levels compared against the LiqMap model, and from general whale tools by specifying tracked leaderboard accounts.

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 user-question triggers: liquidation levels for Hyperliquid whales, tracked notional at each price, large-account positioning, and comparison with the LiqMap model. It does not explicitly name a when-not-to-use case or a direct alternative tool, 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 mark the tool as read-only and open-world, and the description adds useful behavioral detail beyond those hints: the board is live, scanned every 5 minutes, contains addresses only, and event data is capped at the last 200 changes. No contradiction with annotations.

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

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

Two sentences, front-loaded with before-call guidance followed by return details. The intent list is slightly long but each item maps to a real user query, and there is no filler or repeated boilerplate.

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 correctly explains what is returned and its limitations: top-300 board, addresses only, 5-minute scan cadence, and last 200 events. Given only two optional, schema-documented parameters, this is sufficient for an agent 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 description coverage is 100%, so the schema already documents both the coin and events parameters. The description echoes that events means the last 200 position changes but does not add new parameter-level semantics beyond the schema.

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

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

The description opens with explicit call conditions and names the concrete deliverable: a live board of the 300 largest Hyperliquid accounts by equity, plus up to 200 position-change events. This is a specific verb-resource pairing that clearly identifies what the tool does and distinguishes it from nearby whale/market tools.

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

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

The description gives explicit trigger phrases: asking what Hyperliquid whales are doing, whether they are net long/short a coin, largest open positions with liquidation prices, or recently opened/closed/flipped positions. It does not, however, state when not to use it or point to alternatives such as get_whale_tape.

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=true and openWorldHint=true, the annotation already covers safety. The description adds value by disclosing data provenance and limitations: 'A fund is a balance the venue reports, not an audit of its reserves' and the nuance about OKX's own published total vs. sum of priced pools elsewhere. These details help an agent reason about trustworthiness and interpretation without contradicting the annotations.

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

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

The description is dense but every sentence earns its place: usage triggers first, then return details, then parameter semantics, then a caveat. There is no filler or repetition of schema content. The structure front-loads the most important decision information for an agent: when to call.

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 data retrieval tool with no output schema, the description provides a thorough picture of available metrics, per-venue coverage, parameter behavior, and data caveats. An agent can confidently invoke it for the stated use cases. There is no missing critical context such as rate limits or auth requirements, which annotations already cover.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by clarifying what 'pools' actually returns: 'every pool row (the contracts it covers, asset, balance, USD)', which adds structural meaning that the schema's terse 'Include every pool row' lacks. The venue and history_days parameters are adequately covered by the schema, and the description reinforces their use with context like 'per covered venue' and 'daily closes per venue.'

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

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

The description uses a specific verb+resource pairing: 'Call this when the user asks how big an exchange's insurance fund is...' and enumerates the exact metrics returned (fund USD value, per-asset breakdown, 24h/7d change, percent of open interest, daily closes). This clearly separates it from the many sibling data tools, particularly get_open_interest and get_coverage, by naming the insurance fund domain explicitly. The title reinforces the scope with concrete metric names.

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 explicit when-to-use triggers: asking about fund size, shrinking/used after crash, how much exchanges hold, or comparison to open interest. These are clear, actionable conditions. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is strong and 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 provide readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: the data source ('daily Deribit chain') and the returned components ('expiry x moneyness', per-expiry ATM/25-delta IV, skew/butterfly, constant-30d history'). No contradictions with annotations exist.

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

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

The description is two efficiently packed sentences with front-loaded usage conditions and a dense but readable inventory of return contents. No filler words or redundant restatements of the tool 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?

For a read-only tool with one optional parameter and no required fields, the description sufficiently explains what the agent will get and when to call it. No output schema exists, so the explicit enumeration of return dimensions is valuable; exact formatting/units are not explained, but that is a minor gap for this complexity level.

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 the only parameter being an optional currency enum already fully described as 'BTC or ETH, default BTC'. The description correctly does not repeat schema details but adds no additional parameter-level meaning 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 clearly states a specific verb plus resource ('Call this when the user asks about implied volatility by strike or expiry... Returns the IV surface...') and enumerates the exact contents returned. It is distinct from option-related siblings like get_options_snapshot or get_options_flow by specifying skew, term structure, and the Deribit-derived 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?

The opening line gives explicit and detailed when-to-use conditions: implied volatility by strike/expiry, skew, put versus call IV, term structure, or downside-protection cost. It does not name alternatives or state when not to use the tool, so it falls short of a full 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 no safety contradiction exists. The description adds behavioral context by stating the data is 'read from the on-chain custody state' and emphasizing exactness, which is useful beyond the annotations. It does not discuss rate limits or failure modes, but the read-only annotation lowers the burden.

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 with no filler: the first front-loads the trigger and the full data inventory, the second gives parameter guidance. Every clause earns its place.

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

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

For a multi-purpose data tool, the description covers all major output categories and the role of both parameters. There is no output schema, but the description compensates by listing return values explicitly. The only notable gap is what happens when parameters are omitted, since required parameters is 0.

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%: base's pattern and history_days' range are already documented. The description only restates 'Pass base and history_days' and clarifies that these drive the hourly OI history. That is marginally helpful but adds little 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 the exact resource (Jupiter Perps on Solana) and enumerates the specific data provided: long/short OI, utilization, borrow rates, JLP metrics, 24h volume, and top traders. It also differentiates the tool from siblings by emphasizing the on-chain custody source and Jupiter-specific 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?

The description opens with an explicit trigger condition: 'Call this when the user asks about Jupiter perpetuals on Solana.' It gives clear context for when to use the tool, but does not name specific alternatives or state when not to use it, so it stops short of a perfect 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?

The readOnlyHint and openWorldHint annotations cover the safety profile, and the description adds valuable behavioral context by specifying the exact output: per-pair daily cross-correlations at lags -3..+3, lead asymmetry, and share of days each venue led. This goes beyond the annotations without contradicting them.

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

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

Two sentences carry exactly the needed information: when to invoke the tool and what it returns. The trigger is front-loaded and every phrase contributes meaning.

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 with no output schema, the description is complete. It explains both the query conditions and the returned metrics, so an agent can correctly select and invoke it without further elaboration.

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 is no parameter semantic burden on the description. The baseline for a zero-parameter tool is 4, and the description appropriately needs to add no parameter-level detail.

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 and function: venue lead-lag across Coinbase, Kraken, and Binance. It begins with an explicit call trigger and clearly distinguishes this tool's domain (who moves first) from the many sibling market 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 provides an explicit 'call this when' statement covering both exchange lead-lag and spot-vs-perp lead questions. However, it does not explicitly name alternative tools or state when not to use this tool, 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; the description safely adds that data is 'recorded daily by ByKaranteli' and includes a change log, which helps the agent understand freshness and history. It does not cover rate limits or response formatting, but the annotations already carry the safety profile.

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

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

Three tight sentences: trigger conditions, return contents, and parameter guidance. Every sentence earns its place, 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 read-only tool with no output schema, it covers the core needs: supported intents, returned ladder fields, change log, data provenance, and example parameter values. It could clarify what happens when both parameters are omitted (e.g., returning all venues/symbols), but the schema marking both optional and the phrase 'per venue' make this reasonably inferable.

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

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

The schema already documents both optional parameters with examples, so the baseline is 3. The description adds concrete accepted venue ids (bybit, okx, gate, htx, bitget, mexc) and clarifies that symbol means a base asset, which is genuinely useful 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 opens with concrete user intents ('how much leverage an exchange allows on a coin', 'maintenance margin or risk limit ladder') and explicitly names the returned resource: tier, notional floor/cap, max leverage, maintenance margin rate, plus a change log. This clearly distinguishes it from the sibling market-data tools by naming a unique resource and data source.

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 examples ('which venue offers the highest leverage for a symbol', 'whether an exchange recently cut leverage') and practical invocation guidance ('Pass symbol for one base asset... venue for one exchange'). It does not state when not to use this tool or name alternatives, 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the one-symbol scope, the exact return components (modeled levels by price, zone aggregates, real prints), and the account-key-based timeframe limitation. This materially informs the agent about behavior that annotations alone would not convey.

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, follows with the return contents, and ends with plan/tier constraints. Every sentence earns its place; there is no filler or repetition of schema fields.

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

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

For a two-parameter read-only tool, the description covers trigger intent, return contents, symbol scope, and auth-gated timeframes. Without an output schema, a bit more detail about response shape would strengthen completeness, but nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context that timeframe availability depends on API key tier and that the tool serves one symbol, but it does not add significant meaning beyond the schema's own parameter descriptions.

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: 'Call this when the user asks where liquidation clusters or liquidity pools sit...' and details the returns as modeled liquidation levels by price, zone aggregates, and real liquidation prints. This clearly distinguishes it from siblings like get_liquidations and get_liquidation_cascades by emphasizing the LiqMap heatmap and venue-counted real prints.

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 ('Call this when the user asks where liquidation clusters...') and explains key-tier access constraints affecting which timeframe is served. It does not explicitly name sibling alternatives to exclude, but the trigger framing is strong enough to guide selection.

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

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

Annotations already indicate readOnlyHint and openWorldHint, and the description adds meaningful behavioral context beyond them: results are auto-detected, totals are an honestly-labeled lower bound, and the data comes from a real liquidation tape. This manages expectations about data completeness and provenance without contradicting annotations.

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

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

The description is compact and front-loaded: the trigger condition appears first, followed by the output contents, then the important caveat about lower-bound totals. Every sentence earns its place and there is no redundancy or 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 no-argument, read-only tool with no output schema, the description covers when to call it, what data it returns, and a key limitation. It could go slightly further on output formats or explicitly distinguish itself from get_liquidations for raw per-liquidation data, but it is sufficient for selecting and invoking the tool correctly.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter semantics to document. Per the baseline for zero-parameter tools, a 4 is appropriate; the description's focus on output fields is correct and does not need to compensate for missing parameter docs.

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 names the resource (auto-detected liquidation cascades), specifies the action (returns cascade incidents), and enumerates the returned fields (when, total notional flushed, long/short split, leading coins, BTC's move). This differentiates it from siblings like get_liquidations by emphasizing cascade incidents and the forensic case-file framing.

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

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

The description opens with explicit trigger conditions: 'Call this when the user asks what caused a recent crash or flush, about liquidation cascades, or who got liquidated.' This gives clear context for when to use the tool, but it does not name alternatives or explicitly state when not to use it, so it falls short of a 5.

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

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

Annotations already mark it readOnly, but the description adds meaningful behavioral detail: data is from counted venues' public feeds, Binance is capped at one print per second per symbol and therefore its rows are a floor, and SELL means a long was liquidated. This goes well beyond what annotations 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?

The description is front-loaded with a 'Call this when' opening and packs a lot of necessary detail into two sentences. It is slightly long and lists many output fields, but every clause earns its place given there is no output 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 tool with no output schema, the description fully covers what is returned: rank, symbol, venue, side semantics, price, quantity, notional, millisecond time, and the heatmap structure. It also gives the key Binance limitation unchecked. The agent has enough context to select and invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents days, limit, and window fully. The description echoes the window values and mentions the 30-day heatmap, but does not add new parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description opens with explicit user intents: biggest liquidation today/week, who got liquidated the most, largest single print, and clustering by session. It also states the exact output (largest single liquidation prints plus a 30-day UTC heatmap), which distinguishes it from sibling tools like get_liquidations or get_liqmap.

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?

Provides clear when-to-call guidance with concrete examples ('when the user asks for the biggest liquidation today', 'when in the day or week liquidations cluster'). It lacks explicit when-not-to-use guidance or named alternatives, so it falls just short of a 5.

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

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

Beyond readOnlyHint=true, the description adds meaningful behavioral context: data is recorded from ByKaranteli's own stream collectors, reflects a floor rather than estimates, covers only venues on the coverage list, is finalized per UTC day, and starts on 2026-07-30. This helps the agent set expectations about completeness and freshness without contradicting 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 information-dense but every clause earns its place: trigger conditions, return shape, data provenance, coverage caveat, granularity, and history start are all packed into three sentences. The key usage trigger 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?

Despite having no output schema, the description conveys the return granularity, units, data source, coverage caveat, and start date. An agent has enough context to know what it will get and how to interpret it, especially since the two parameters are already fully documented by 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 that results are per symbol and per exchange and that history is growing daily, but it does not add material parameter-level detail beyond what the schema already provides for days and symbol.

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

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

The description states exactly what the tool does: returns daily long/short liquidation totals in USD per symbol and exchange. The trigger phrase 'Call this when the user asks how much was liquidated' plus the resource scope makes the purpose unmistakable and distinct from sibling tools like cascades, leaderboard, or liqmap.

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

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

It explicitly names the use cases: user asks about crypto futures liquidation amounts, longs/shorts getting flushed, or liquidation history. It does not name alternative sibling tools or give when-not-to-use guidance, so it falls just 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, covering the safety profile. The description adds that it returns "the recorded daily series and latest values," which is useful return-shape context, but says nothing about data recency, update cadence, or pagination. One extra sentence of context against a solid annotation baseline earns a 3.

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 filler, with the triggering condition front-loaded before the return description. Every clause earns its place.

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

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

For a read-only, no-required-param series tool with no output schema, the description covers both trigger and return shape, which is nearly everything an agent needs. Minor gaps remain around data freshness and whether results are aggregate or per-metric, keeping it just under a 5.

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 a single parameter and 100% schema description coverage, the schema already documents the 30-4000 range, the 365 default, and the clamping behavior. The description mentions no parameter detail at all, so it adds nothing 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?

States a clear verb (get) and enumerates the specific series returned: Fed balance sheet, reverse repo, rates, stablecoin supply, tied to crypto. The title reinforces the scope. It is distinguishable from generic siblings like get_series and get_tradfi_board, though it does not explicitly name a sibling it differs from.

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 explicit triggering conditions. It stops short of naming an alternative tool or stating when NOT to use it, so it lands at a clear-context 4 rather than a full routing 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. The description adds useful context: the refresh interval (~30 minutes) and the specific components included (today/yesterday's Fear & Greed, Bitcoin dominance, total market cap, Retail Euphoria). This goes beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the usage trigger, and packs detailed data points without redundancy. Every sentence earns its place with no fluff.

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

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

Given the tool's simplicity (no parameters, no output schema, simple data retrieval), the description is fully complete: it states what to call it for, what data it returns, and the refresh cadence. No critical information 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, so the schema provides no semantics. The baseline for 0 params is 4. The description compensates by explaining exactly what data will be returned, making the parameterless invocation clear.

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

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

The description clearly states the tool's purpose: answering questions about overall crypto market sentiment or macro state. It lists specific data points (Fear & Greed, BTC dominance, total market cap, Retail Euphoria) and distinguishes itself from sibling tools that focus on narrower metrics like funding, liquidations, or options 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 description explicitly tells when to use the tool ('when the user asks about overall crypto market sentiment or macro state'). It does not explicitly mention alternatives or when not to use it, but the sibling list provides context and the instruction is clear enough for an agent to select it appropriately.

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 cover readOnly and openWorld, so the bar is lower, but the description adds substantial behavioral context: it discloses the data source (own one-minute bars of Binance USDT-M perp), calculation parameters (30-min TPO periods, 0.05% buckets, 70% VA, first-hour IB), scope (one row per closed UTC day), and an edge case (symbols without minute bars return no_profile). It does not discuss latency or rate limits, hence a 4 rather than 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, front-loaded with the trigger condition, but the second sentence is a dense, comma-laden inventory of return fields that is hard to parse. The value-area abbreviations (VAH, VAL) are expanded, which helps, yet the run-on structure reduces readability.

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 data-retrieval tool with no output schema, the description adequately conveys what is returned (daily profile rows, naked POCs, latest day per bucket) and includes an important edge-case behavior (no_profile). It is complete enough for correct invocation, though a note on pagination or time-to-compute would make it fully self-contained.

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

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

Schema coverage is 100% and the schema documents both parameters with defaults, ranges and a symbol pattern. The description adds meaning for the data window indirectly ('closed UTC day', 'last 60 recorded days') but doesn't restate or refine the 'days' parameter semantics. Baseline 3 is appropriate when the schema carries the parameter semantics.

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 Market Profile data for a perpetual) and enumerates the exact metrics: TPO profile, POC, VAH/VAL, initial balance, naked POCs. Distinguishes clearly from siblings like get_orderbook_depth or get_volume_profile-adjacent tools by naming its unique concepts.

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?

Front-loads 'Call this when the user asks about...' with a rich set of trigger terms (Market Profile, TPO, POC, value area, initial balance, naked POC), which is strong contextual guidance. However, it does not name sibling alternatives (e.g., where to go for raw price/volume) or state exclusions, so it stops short of full when/when-not guidance.

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

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

The description goes well beyond the annotations by disclosing key behavioral traits: buckets under 30 days are suppressed, most metrics do not separate from the base rate, and the interpretation says so plainly. It also specifies the concrete outputs (median forward BTC return and up-share at +1/+3/+7 days with the all-days base rate), which is valuable given there is no output schema.

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

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

The description is front-loaded with the primary use case, then delivers mechanics, honesty rules, and the supported metric list in a compact sequence. Every sentence adds decision-relevant information, and the length is justified by the need to convey conditional-distribution behavior and interpretation caveats.

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-only tool with no output schema, the description is complete: it explains what the tool returns, how the bucketing works, the interpretation caveat, and the supported metric candidates. Nothing essential is left for the agent to infer.

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

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

The input schema already fully documents the single `metric` parameter with examples and a pattern, so the baseline is 3. The description adds extra semantic value by enumerating the full supported metric set and clarifying that the metric must be a 'recorded metric' with daily history, which helps the agent pick valid 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 precise trigger condition and resource: it explains the tool buckets a metric's current value against its own daily history to determine whether readings are high or low and what happened after similar readings. It clearly differentiates itself from a forecast and lists the exact metrics it supports, making its purpose unambiguous even among many sibling tools.

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

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

The description gives an explicit 'Call this when...' condition: when the user asks whether a metric reading is high or low, or what happened after similar readings. It also states 'History, not a forecast,' which is a useful exclusion. It does not name alternative tools, but no sibling tool appears to overlap directly, so the lack of explicit alternatives is not a significant gap.

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

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

The annotations already establish read-only and open-world behavior, and the description adds useful provenance and scope details: measurements come from ByKaranteli's own node, the node is blocksonly, and therefore no mempool series is available. It does not cover rate limits or response shape in depth, but it meaningfully supplements 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 two tight sentences, front-loads the usage condition, and uses the parenthetical to disclose the blocksonly limitation without wasting words. Every part earns its place.

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

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

For a simple read-only tool with one optional, fully documented parameter and no output schema, the description provides enough context: when to call it, what metrics it returns, what form the return takes, and the own-node/ blocksonly limitation. 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%, and the single days parameter is already fully documented in the schema, including its 30-4000 range and 365 default. The description adds no parameter-level meaning, so the baseline of 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 names the specific Bitcoin network metrics returned (hashrate, difficulty, block fees), states that it returns recorded daily series and latest values, and identifies the data source as ByKaranteli's own node. This is enough for an agent to distinguish it from generic series or unrelated market-metric siblings.

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

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

It gives a clear trigger: 'Call this when the user asks about Bitcoin hashrate, difficulty or block fees.' It also rules out mempool queries because the node runs blocksonly, but it does not name a specific alternative tool for mempool-related 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?

The readOnlyHint and openWorldHint annotations already establish the safety profile, so the bar for behavioral disclosure is lower. The description adds useful operational context by stating that the tool returns both listings and delistings and that its scope is 'every exchange the hourly scan covers.' It does not describe return shape, but that is reasonable for a simple list-returning tool.

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 with no filler. Trigger conditions are front-loaded, followed by a compact statement of what the tool returns and its coverage scope.

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 parameter, the description provides the necessary invocation context: when to call it, what it returns, and over what exchange coverage. The absence of an output schema is acceptable because the description clearly summarizes the returned content as listings and delistings.

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 top-level description does not elaborate on the days parameter, but the input schema fully documents it: integer range 1-30, default 30, plus a pointer for longer listing history. With 100% schema description coverage, the baseline of 3 applies and no additional parameter explanation is required.

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 explicit trigger conditions ('Call this when the user asks what new perpetuals were listed, which exchange listed a coin first, or about delistings') and names the exact resource: new and delisted perpetual contracts across exchanges. This clearly differentiates it from the many sibling data tools like get_funding_heatmap 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 provides explicit call conditions tied to concrete user intents, so an agent knows when to invoke it. It does not explicitly say when not to use it or name alternative tools, which keeps it just below a perfect 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 cover read-only safety, and the description adds useful non-obvious behavior: 5-minute resolution, 24-hour deltas, and the exact regime categories per symbol. It does not contradict annotations, but it also does not mention data freshness, coverage limits, or any edge cases.

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 carrying full value: the first front-loads the exact user intent, the second compactly enumerates the return fields and regime labels. No filler or redundant phrasing.

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-param, read-only tool, this covers the trigger, scope, resolution, delta fields, and four possible regime labels. Nothing an agent needs to decide whether to call it or interpret its output 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. The description adds that the result is per symbol across major perpetuals, which is sufficient context for a parameter-less call.

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 starts with a specific trigger ('Call this when the user asks...'), identifies the resource (open interest for major perpetuals), and specifies the output contract (5-minute OI, 24h deltas, four-regime regime labels). This clearly separates it from siblings like funding heatmap or liquidations by tying it directly to leverage positioning.

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 conditions for use: leverage entering/leaving the market, OI changes, or longs/shorts building. It does not name alternatives or provide when-not-to-use guidance, so it falls just short of full routing advice.

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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely non-obvious behavior: anonymous depth returns only the largest strikes while a key with member depth returns every strike, and data capture begins 2026-09-30 so early queries return short history. One tier-limitation and one data-availability caveat is solid added value; it does not cover rate limits or response shaping beyond that.

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 invocation trigger, then the payload, then the two caveats. Dense but every clause carries information; only the 'ByKaranteli's own hourly capture of every listed venue' phrasing is slightly promotional.

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: OI, mark IV per expiry/strike, 1h and 24h deltas, and the ATM IV path. The access-tier and history-window caveats finish the picture for a 4-param optional-all tool; only pagination/volume limits are unaddressed.

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% with per-parameter descriptions and enums, so the baseline is 3. The description restates venue capture and expiry/strike structure but adds no syntax, defaults, or format detail beyond what the schema already documents.

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 — hourly open interest and mark IV per expiry and strike, plus 1h/24h change and the front expiry's ATM IV path. The scope is precise enough to separate it from a static snapshot, but it never names the neighboring options tools (get_options_snapshot, get_iv_surface, get_options_flow), so the distinction is left to inference.

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 trigger: 'Call this when the user asks how the BTC or ETH option chain moved today or over the last day.' That is a clear usage context, but it offers no when-not or named alternative for the overlapping siblings, which is what a 5 would require.

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 and open-world status; the description adds real behavioral context: 15-minute refresh cadence, 24h/48h windows, net-premium accounting for multi-leg blocks, and the supported venues (Deribit, OKX). It does not discuss auth, rate limits, or behavior when data is missing.

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, trigger first, then a tight enumeration of returned metrics. The return-value list is dense but earns its place because no output schema exists, and no sentence is filler.

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

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

For a zero-parameter, annotation-light read tool with no output schema, the description effectively documents what comes back (metrics, time windows, venues, update cadence). Only gaps are error/empty-state behavior and how a client should interpret the 'net premium' when legs straddle venues.

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 schema carries nothing to interpret; per the baseline, zero-parameter tools start at 4. The description instead spends its words on output fields, which is appropriate here.

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 set: 24h call vs put premium, block-trade share, multi-leg structure count, and largest prints over 48h with strikes, IV and venue. That is enough to separate it from get_options_snapshot or get_iv_surface, though it never explicitly contrasts itself with those siblings.

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

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

It gives explicit trigger conditions ('when the user asks what big options players are buying, about block trades, or whether call or put premium dominates today'). That is clear when-to-use guidance, but there is no when-not guidance or named alternative for overlapping options 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 safety is covered; the description adds genuinely new behavioral context: the snapshot is daily, venue aggregation is summed by default, and 'DVOL is Deribit's index whatever the venue' clarifies a surprising cross-venue behavior. It also warns that max pain is 'not a price target', which pre-empts misreading. It stops short of stating latency, rate limits, or freshness guarantees.

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 sentence is correctly front-loaded, but the remainder is one sprawling clause chain of output fields separated by commas and em-dashes, which is hard to scan and mixes several distinct concepts (walls, dealer map, iv_source, max pain, expiries) in a single breath. Every item is arguably useful, but the structure costs readability.

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 describing return content, and it does so exhaustively: walls, top strikes, put/call ratio, hedging map, ATM IV by expiry, venues_included, per-expiry OI by side, max pain and one-sigma implied move. An agent knows what it will receive 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?

With one parameter at 100% schema coverage the baseline is 3, and the description exceeds it by explaining that 'all' sums every venue while passing a venue id narrows the aggregation, plus the non-obvious caveat that the venue choice does not change DVOL. That is real semantic value beyond the enum labels.

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 ('daily snapshot of the listed option chains of every options venue we record') and enumerates the exact payload: call/put walls, GEX, zero-gamma level, DVOL, term structure. The 'daily snapshot of open interest across venues' framing implicitly separates it from flow-oriented siblings like get_options_flow and surface-oriented 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 trigger set: 'Call this when the user asks where the big options bets sit, about call/put walls, gamma exposure (GEX), the zero-gamma level, implied volatility (DVOL) or the IV term structure for Bitcoin or Ethereum.' Clear context for invocation, but no exclusions or named alternatives, so an agent must still infer when get_iv_surface or get_options_flow is the better pick.

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

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

The description goes well beyond the readOnlyHint/openWorldHint annotations, disclosing binning granularity (0.1% buckets within 20% of mid), USD notional, venue splitting, 2% depth, book reach, per-venue handling, and the in_aggregate=false/held_out treatment of uncorroborated books. No annotation contradiction exists.

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

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

The description is dense but purposeful; every sentence carries operational detail. It is front-loaded with usage triggers before output specifics. It is slightly long and packed into a few complex sentences, but not wasteful.

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

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

For a tool with no output schema, the description thoroughly covers scope, inputs, aggregation behavior, coin universe, and data-quality caveats. It does not describe the exact response structure or field names, but the returned concepts are clear enough for invocation decisions.

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 explains both parameters. The description adds contextual value by linking hours to summed 5-minute history and listing accepted coins, but it mostly reinforces rather than expands on 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 opens with concrete user intents ('where the bid or ask walls are', 'how deep the spot order book is') and names the resource: spot order books from every venue on the coverage page. It clearly distinguishes this from generic market data tools by specifying the unique wall/depth/heatmap 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?

It gives explicit trigger conditions ('Call this when the user asks...') and lists representative queries. It does not explicitly say when not to use it or name a sibling alternative, so it stops short of a 5, but the usage 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 declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds genuinely useful behavior beyond the annotations: a 15-minute refresh cadence, the fixed symbol universe, and a venue-by-venue breakdown of which ratio types come from which exchange.

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 front-loaded before the deliverable details, and the sentence is dense but not padded. Every clause contributes information—venue coverage, ratio types, refresh cadence—though it is a long single sentence with many parentheticals.

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?

Because there is no output schema, the description carries the burden of explaining returns, and it does so thoroughly: per-venue ratio breakdowns plus a distinct BTC/ETH/SOL CVD series. For a one-parameter read-only tool this is nearly complete; the only gap is unspecified behavior when symbol is omitted, which the schema itself leaves optional.

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 'symbol' already described as a Binance symbol with an example. The description adds only a modest tie-in: the symbol should be a perpetual within the 30 most traded set. That is enrichment, not replacement, so the baseline 3 applies.

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

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

The description names the resource ('positioning board statistics' for perps) and specifies exact data types: long/short ratios, retail vs. top-trader positioning, taker buy/sell ratio, and CVD. It scopes the universe concretely (30 most traded Binance USDT perps across all recorded venues), which clearly differentiates it from get_cot_positioning and other sibling market metrics.

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 about...' followed by a concrete list of query patterns that route here. It gives clear context for when to use the tool, but never names when-not-to-use it or points to alternatives such as get_cot_positioning for CFTC positioning data.

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 valuable context by disclosing the 0-100 composite score inputs, the LONG/SHORT/NEUTRAL direction, and the plain-language regime label, which is important since no output schema exists. It could go further by stating the returned row/symbol field, but this is not a serious gap.

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 with no wasted words. The first sentence carries the primary trigger, the second routes to an alternative tool, and the third explains the output composition. Important information is front-loaded, 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?

For a read-only tool with two simple optional parameters and no output schema, the description supplies the essential operational context: when to use it, what it returns, how the score is composed, and which sibling to choose instead. The schema covers parameter details, and annotations cover safety, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents limit and symbol, including defaults, sorting, and example formats. The description's mention of 'specific coins' and 'each symbol' weakly reinforces symbol semantics but does not add parameter-level meaning beyond the schema, so the 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 names a specific resource (derivatives pressure scores), a precise verb-purpose (responding to crowded/over-leveraged coin queries), and the exact composite construction (funding, OI deltas, basis). It also clearly separates itself from get_top_movers, making the tool's identity unmistakable.

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

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

It explicitly states when to call this tool ('when the user asks which coins are crowded or over-leveraged, or asks for the pressure/derivatives-stress score of specific coins') and gives a concrete alternative for a different use case ('For a quick top-10 ranking of the highest-stress coins right now, use get_top_movers instead'). This is model 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 indicate readOnly and openWorld hints, and the description adds meaningful behavioral context: inputs are proprietary, outcomes are always published, and the tool is not to be over-interpreted as a signal or predictor. It also explains the meanings of each state, helping the agent set user expectations.

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

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

The description is dense but front-loaded with the invocation trigger, followed by return fields and caveats. It is slightly long, and some information repeats the title, but every part still contributes useful context for selection and use.

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 with no output schema, the description covers the main return components, defines the state values, and sets expectations. Minor details like what exactly 'stress locality' or 'year-split measured scorecard' contain are left open, but they do not prevent correct invocation.

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

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

The tool has zero parameters, so there is no semantic gap to fill; this matches the baseline 4. The description reinforces that no user-supplied inputs are required by stating inputs are proprietary.

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

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

The description clearly identifies the resource (PsiCharge hidden liquidity state), the exact subject matter (parked money deploying, stress unwinding), and the returned fields. It distinguishes itself from sibling market-data tools by focusing on a proprietary liquidity-state model rather than generic market metrics.

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 'Call this when the user asks...' trigger, which is strong usage guidance. It also gives exclusions ('Not a trade signal, not a crash predictor'), but it does not name alternative sibling tools or state when another tool should be chosen 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?

The readOnlyHint annotation already signals safety, and the description adds substantial behavioral context beyond annotations: it specifies the data source (ByKaranteli's own Bitcoin Core node), daily frequency, and provenance hashes for re-verification. This tells the agent exactly what kind of computation and guarantees are involved.

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 uses a compact, well-organized list to enumerate return fields. No sentence is wasted, and the provenance-hash detail earns its place because it justifies the verifiability claim.

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 to lean on, the description fully enumerates what the agent can expect: exposed BTC, share of held value, UTXO count, script-family composition, dormancy cohorts, watch set, and provenance hashes. This is complete enough for an agent to select the tool and interpret its result confidently.

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 no parameters and schema description coverage is 100%, so there is no parameter surface for the description to clarify. The 0-parameter baseline of 4 applies; the description appropriately focuses on output semantics instead.

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

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

The description opens with a precise call condition and names the exact resource (quantum-exposed Bitcoin). It lists concrete synonymous user phrasings (quantum-exposed supply, P2PK coins, Satoshi-era exposure), making the tool's purpose unmistakable. It also clearly differentiates from the market-focused sibling tools, none of which cover quantum exposure.

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 explicitly states when to call the tool ('Call this when the user asks...'), giving clear contextual triggers. It does not name alternatives or exclusion cases, but the sibling list contains no overlapping quantum-exposure tool, so the absence of explicit alternatives is not a meaningful gap.

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 provide readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context: the live nature of the board, the market universe, and overbought/oversold counts per interval. It doesn't mention refresh cadence or detailed response shape, but for a read-only query tool this is acceptable.

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 definition is compact and front-loaded with trigger conditions, then follows with the return value and filtering options. Every clause earns its place: universe, intervals, counts, and parameter use are all covered 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 straightforward read-only board tool with no output schema, the description adequately explains what is returned (live heatmap with per-interval overbought/oversold counts) and how to shape results via symbol, kind, and sort. More exact output field details could be added, but not enough is missing to prevent correct invocation.

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

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

Schema description coverage is 100%, with all three parameters described and two constrained by enums. The description merely restates their roles ('Filter by symbol or kind, sort by an interval') without adding semantic details beyond the schema, so the 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 uses a specific verb and resource ('Returns the live board...'), names the exact universe (top-400 Binance crypto perps by volume plus every TradFi perp), and ties to concrete user intents (overbought/oversold, multi-timeframe RSI, one contract's RSI on specific intervals). This clearly distinguishes it from sibling tools like get_funding_heatmap or get_top_movers.

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

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

It explicitly states when to call the tool: when the user asks about overbought/oversold coins, a crypto RSI heatmap, multi-timeframe RSI, or a single contract's RSI across listed timeframes. It does not explicitly mention when not to use it or name alternative tools, 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 only declare readOnlyHint and openWorldHint, but the description adds substantial behavior: the exact response shape (points as [t, v], OHLCV for price, plus unit, kind, source, source_kind, bars served, member depth and provenance), depth/authorization behavior (public depth serves fewer bars and no 5m bars; Builder key and above get member depth), and where bar limits live. This is genuinely useful context beyond the 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?

The trigger is front-loaded and the prose is information-dense with little filler, but it is long and partly redundant, listing the metric set once in prose and again in the 'metric is one of' clause. It is appropriately sized for a broad time-series endpoint, though not maximally tight.

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 explanation and does so (point/tuple format, unit/kind/source fields, bar count, provenance), plus depth limits and the metric list. For a 7-parameter, high-complexity endpoint, 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 the baseline is 3, but the description adds real semantics: the full metric key list, venue support notes, and the rule 'Pass from and to (ISO) for a window, or limit for the newest bars', which explains how parameters interact rather than restating them. It adds value over the schema without fully documenting every parameter's edge 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?

Opens with a precise verb+resource+scope: the history of one recorded metric for one perpetual as a time series, and enumerates the metric space (price, volume, CVD, OI, funding, liquidations, RSI, ETF flows, whale net flow, etc.). An agent can distinguish it from single-metric siblings like get_open_interest or get_etf_flows because it is framed as the general time-series endpoint.

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 when-to-use trigger: history for one metric/one perpetual, for charting, backtesting or 'what did X do over the last N days'. It also implies usage via the metric list and the from/to vs limit guidance. It does not explicitly name when NOT to use it or route to specific sibling tools (e.g., prefer get_liquidations for a cascade view), so it stops 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 readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: a 60-day lookahead, grouping by date/venue/underlying, coverage of 54 venues, and inclusion of settlement prices. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences with no filler. The first sentence front-loads trigger conditions and user intents; the second states the exact return scope and grouping. Every part earns its place.

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

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

For a zero-parameter, read-only tool with no output schema, the description fully explains what the user gets: next 60 days of expiries, grouping dimensions, venue coverage, and settlement prices. Nothing essential is missing for an agent to decide whether to call this tool.

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

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

There are zero parameters and the schema coverage is 100%, so the description does not need to explain parameter semantics. Baseline for zero-parameter tools is 4, and no additional parameter detail is required.

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

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

The description uses a specific verb ('returns') and clearly identifies the resource: futures/options expiries and settlement prices. It also lists concrete user intents ('what futures or options expire soon', 'next quarterly expiry', 'how many contracts settle this week'), which distinguishes it from sibling tools focused on other data like options flow or open interest.

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 explicitly tells when to call it by enumerating several query phrasings. It does not name alternatives or state when not to use it, but among the sibling tools none overlap with expiry/settlement functionality, so the usage context is clear.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds valuable behavior beyond annotations: the return format (cost ladders in basis points), the exact order sizes, both side coverage, exclusion of fees, and the null semantics for unabsorbable sizes. This is richer than the baseline for annotated read-only tools.

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

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

The description is compact and front-loaded with the most critical usage trigger. It covers what, when, and return semantics in just two sentences. Every clause adds value (e.g., size range, both sides, null meaning), with no filler or repetition.

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

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

Given the tool has no parameters and no output schema, the description carries full responsibility for explaining return values and edge cases. It does so thoroughly: live cost ladders, order size range, number of perps, both sides, fee exclusion, and null behavior. This makes the tool fully understandable without needing additional 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?

The input schema has zero parameters, which is a baseline 4. The description adds no parameter-specific semantics because there are none, but it implicitly tells the agent that no arguments are needed, consistent with a fixed-market tool. The description does not need to compensate since there is nothing to document.

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

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

The description clearly states the tool's purpose: it returns live cost ladders for market orders, addressing slippage, book thickness, and thinnest perp market queries. This distinguishes it from sibling tools like get_funding_arbitrage or get_liquidations, which focus on different data. The verb 'returns' and specific scope ('8 major perpetuals', '$10K to $5M', 'both sides') make the purpose unmistakable.

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 explicit usage guidance: 'Call this when the user asks how much slippage...' It also covers related use cases like book thickness and thinnest market. While it doesn't explicitly mention when not to use it or alternative tool names, the context is clear enough for an agent to select this tool over siblings for slippage-related queries.

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 establish read-only and open-world, so the description carries the real load and does: refresh cadence ('board read every 10 minutes'), data semantics (one-sided OI, both sides on pool venues), history retention tiers (7 days free, 30 with member depth), and a hard capability exclusion (Jupiter hourly history not available here). This is precisely the behavioral context an agent cannot get from readOnlyHint 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?

Dense and front-loaded: the usage trigger leads, then payload contents, then history caveats. It is long and uses heavily nested parenthetical lists, which costs some scanability, but every clause carries distinct information rather than restating the name or 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?

Despite having no output schema, the description fully specifies the return shape (per-venue totals with named fields, per-market rows ordered largest-first with instrument type, optional hourly history) plus the refresh cadence and retention limits. For a 3-optional-parameter read tool, nothing needed to call or interpret 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%, so the baseline is 3, but the description adds meaning beyond it: it clarifies that hourly history is offered 'of one market on any venue but Jupiter' (the schema never states this restriction), and that symbol resolves against Pacifica by default. It does not explain the venue-vs-symbol interaction further, keeping 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?

Names a specific verb and resource ('get_solana_perps' = the Solana perps board) and enumerates exactly what the board contains: open interest, 24h volume, hourly rates across six named venues. It also cleanly separates itself from the sibling get_jupiter_perps by declaring Jupiter history lives there, 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 ('Call this when the user asks about perpetuals on Solana as a whole, which venue has the most OI or volume...'), covering cross-venue comparison, single-venue lookups, and Jupiter-vs-orderbook comparison. It also names the alternative tool (get_jupiter_perps) and the condition that selects it, giving when-to-use and when-not in one pass.

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 index construction (equal-weight, fixed basket), the rebase date (2025-01-01), the available return windows (1d/7d/30d/90d/YTD), the BTC comparison, and the member lists. It also transparently warns that daily points are omitted unless include_points is true and that include_points returns a large payload.

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 sentence front-loads the trigger conditions, and the second packs the output details into one clear, scannable statement. Every element 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?

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: what indices, how constructed, base date, return windows, BTC comparison, member lists, and the include_points caveat. For a simple one-parameter 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?

The schema covers the single boolean parameter include_points with a description, and the tool description adds the default behavior: daily points are omitted unless include_points is true. This extra information about the parameter's effect on response size is valuable beyond the raw 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 the resource ('eight equal-weight fixed-basket indices') and the exact narrative categories (AI, RWA, DePIN, memecoins, L1, L2, DeFi, quantum), making it unmistakably distinct from generic market-index or single-asset tools. The trigger phrasing 'which crypto narrative or sector is leading' and 'for a theme index' gives the agent a direct signal for when this tool applies.

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

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

It provides clear when-to-use context: narrative leadership, sector rotation, or theme index requests. It does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5, but the trigger conditions are specific enough to route the agent 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 only give readOnlyHint and openWorldHint, but the description adds substantial behavioral context: the board refreshes every 10 minutes, the exact composition of each row (reference share price and session, per-wrapper premium_pct vs a fresh reference, DEX liquidity and 24h volume, supply in shares and dollars, holders, status), and the meaning of price_source and totals.priced_by. This is well beyond what the annotations convey.

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?

Strongly front-loaded with the trigger condition, but delivered as one very dense run-on paragraph. The long parenthetical issuer list largely duplicates the schema's issuer enum, and the price_source/totals detail is packed tightly without structure, so not every clause earns its place independently.

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

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

There is no output schema, so the description must carry the return-value burden, and it does: it describes the per-underlying layout, wrapper fields, exchange pairs, perp cross, totals, and the price_source taxonomy. An agent can interpret the response without additional documentation.

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

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

Schema description coverage is 100%, so top, chain, issuer, and underlying are already documented with defaults, ranges, patterns, and the issuer enum. The description reinforces the chain/issuer vocabulary but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (return the tokenized-stocks board) and enumerates the exact concept space (xStocks, Ondo, Robinhood, bStocks, etc.). No sibling tool in the list covers tokenized equities, so the agent can route to it unambiguously from the name plus the opening clause.

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?

Front-loads an explicit trigger: 'Call this when the user asks about tokenized stocks or stock tokens' followed by the concrete issuer/protocol vocabulary an agent would encounter. It also states an exclusion ('Wrappers come from issuer sources only, never from a name search'), so misuse is guarded against.

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 supplied by annotations, the description adds valuable context by disclosing the output structure ('four top-10 lists in one call') and enumerating the exact metrics included. This is helpful beyond the annotations, though it stops short of detailing data freshness or list ordering.

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

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

The description is two sentences, directly front-loaded with a 'call when' trigger, and every word adds value. It avoids repeating schema or annotation information, making it highly efficient.

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 zero parameters, no output schema, and rich annotations, the description is sufficiently complete for an agent to invoke the tool correctly. It clearly communicates the high-level output (four top-10 lists) and categories; only minor details like field names or time window are absent, but these are not critical for selection.

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 accepts zero parameters, so the schema is trivially complete (100% coverage). The description reinforces that no input is needed, and it focuses entirely on output behavior, which is the appropriate use of description space for a no-parameter tool.

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

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

The description clearly states the tool returns top movers in crypto derivatives, listing specific categories (OI changes, funding, basis, stress). It distinguishes itself from siblings by explicitly aggregating four top-10 lists into one call, which is a unique multi-metric offering compared to single-metric tools like get_open_interest.

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

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

The description provides explicit when-to-use context: 'Call this when the user asks what is moving in crypto derivatives right now' followed by concrete query examples. It does not mention exclusions or alternatives, but the context is clear enough for an agent to route appropriately.

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?

Since annotations already mark it read-only, the description can safely focus on what the tool returns; it does so generously by listing mark, index, basis, funding, 24h volume, open interest, liquidations, other venues, and session state. It also explains the optional filtering behavior by market or symbol, adding context beyond the 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 three sentences and each sentence has a distinct job: trigger conditions, returned fields, and filtering. It is front-loaded with the 'Call this when' list and contains no redundant or decorative wording.

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, but the description enumerates the return payload in enough detail for an agent to know what the call provides. With zero required parameters and clear optional filters, an agent can invoke the tool correctly without further 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?

The input schema already documents both optional params at 100% coverage, so the baseline is 3. The description adds a concrete example symbol (TSLAUSDT) and clarifies that filtering is by market category or by a single symbol, but otherwise reuses the schema's enums and patterns.

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 specifies a concrete verb and resource: 'Returns Binance's TradFi perpetual board' with detailed per-contract metrics. It also enumerates unique application domains (stock perps like TSLA/NVDA/gold, tokenized-equity perps, TradFi funding/OI/liquidations, cross-exchange listings, session state) that clearly set it apart from the crypto-focused siblings.

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

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

The description opens with a direct trigger: 'Call this when the user asks about...' followed by several distinct query categories. It does not mention when not to use it or name alternative tools, but the positive conditions are specific enough for an agent 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the data comes from ByKaranteli's own ten-minute venue record, output is checkpoint-by-checkpoint, and it reports venue disagreement plus the next-open realised gap.

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 definition is two compact sentences with no wasted wording. The call condition is front-loaded, and the data-source/parameter scope is compressed into the second sentence without diluting the message.

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, two optional parameters, and full schema coverage, the description is complete enough. It explains the purpose, the intended user question, the data source, and the conceptual outputs an agent should expect.

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 both parameters are already well documented there, including the symbol pattern and the weekend/night enum. The description repeats the window choices and whole-board default but adds no extra syntax, constraints, or examples 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 states a specific resource and scope: weekend/overnight gaps for stock, index, or commodity perpetuals versus the cash close, with checkpoint-level distance, venue disagreement, and next-open realised gap. It clearly distinguishes this query from a broad board query, but does not explicitly name a sibling alternative to differentiate from.

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 trigger: 'Call this when the user asks what a stock, index or commodity perpetual did over the weekend or overnight while the cash market was closed...' This is clear context, but it does not state when not to use the tool or name a preferred alternative among the many get_* siblings.

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), so the bar is lower, and the description goes well beyond them by disclosing the return structure: index in bps with dollar/crypto legs, 0-100 score with 50=world price, regime, 24h/7d averages, same-sign streak, five reference prices, per-venue status, spread and depth. It does not state rate limits or freshness beyond 'live', keeping it at 4.

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

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

It is front-loaded with the usage trigger before the return description, which is the right order, and every clause carries content. The single long second sentence is dense and slightly run-on for a two-parameter tool, so it is not a clean 5.

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 a trivial input schema, the description carries the full burden and discharges it: it enumerates the board contents, the scoring scale, the aggregation windows, and the optional history mode. An agent has everything needed to call it and interpret the result.

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. The description only restates that passing pair and history_days yields '15-minute history of one pair', which the schema already says, adding no new syntax, defaults, or interaction semantics. 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 names a specific resource (the Turkey Premium Index / lira buyer premium) and its scope, and lists the exact triggers (BTC/ETH/USDT lira prices, USDT/TRY rate, dollar premium, which Turkish venues trade rich/cheap). It implicitly distinguishes itself from the nearby get_coinbase_premium sibling by being Turkey/lira-specific, so an agent can route without opening the schema.

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

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

It gives explicit, enumerated when-to-use triggers ('Call this when the user asks about...'), which is strong context. It stops short of naming an alternative or a when-not condition (e.g. use get_coinbase_premium for US premium), so it earns a 4 rather than 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 mark it readOnlyHint and openWorldHint, so no need to restate safety. The description adds useful behavioral context: it returns 10-minute snapshots, polls perpetual and spot feeds, includes a coverage field, and can return per-venue rows for a symbol. This goes beyond the annotations and helps the agent anticipate the response structure.

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

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

The description is three sentences, front-loaded with the when-to-call guidance, then the output nature, then the symbol usage. No wasted words, every sentence earns its place. The structure is logical and easy to parse.

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

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

For a read-only tool with two optional parameters and no output schema, the description covers the key aspects: what it returns, the data freshness (10-minute snapshot), and the coverage field. It doesn't describe the exact response schema, but that's acceptable without an output schema. Minor gaps: it doesn't state default behavior when both parameters are omitted, but that's implied.

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 descriptions already cover both parameters fully (symbol and history_days). The tool description adds meaning: symbol 'for one coin's per-venue rows' clarifies the filtering behavior, and history_days is explained as 'instead of the snapshot' with the exact aggregates returned (total, DEX share, OI-weighted funding). This adds significant 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 clearly identifies the tool's function: returning snapshot aggregates of OI, volume, funding, and stablecoin pegs across all exchanges. It lists specific use cases (total OI, venue ranking, DEX/CEX share, funding dispersion) that distinguish it from a generic OI tool. It doesn't explicitly name a sibling, but the scope 'across every exchange we snapshot' sets it apart.

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 explicit triggers: 'Call this when the user asks about...' followed by concrete scenarios. It also explains the two modes (snapshot vs. history via history_days) and the symbol parameter's effect. However, it doesn't mention when NOT to use it or suggest alternatives, though the sibling list implies other tools exist.

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 the useful behavioral detail that omitting the venue returns the list of recorded venues rather than failing, and it gives a sense of response breadth without promising a specific format.

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, and the long enumeration of returned content is relevant and specific, not filler. It is dense and somewhat long, but every clause informs the agent about what the profile contains.

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 one optional parameter and no output schema, the description provides a thorough inventory of the tool's return content and the no-argument fallback. It does not describe response structure or error cases, but those are less critical given the tool's descriptive scope.

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