WhaleScope MCP

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

Annotations already declare readOnlyHint=true, and the description complements this by explaining the tool internally calls six tools via Promise.all, making it a composite read-only snapshot. It also cautions that it's a 'brief snapshot, not a substitute for in-depth analysis', setting expectations about scope. No contradictions with annotations.

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

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

The description is front-loaded with the core value proposition ('quick overview in one tool call'), then lists contents, then gives usage guidance. It is somewhat dense but every sentence adds useful information; 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?

Despite having no output schema, the description enumerates the key components of the returned overview (funding rate/basis, OI trend, top-trader positioning, taker volume, order book snapshot, price bias) along with their time windows (6h, 4h, 24 1-hour candles). This gives an agent sufficient expectation of what the tool returns while noting it's a snapshot, not deep analysis.

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 covers the single parameter (symbol) with a clear description including examples and constraints (perpetual pair on Binance USDS-M Futures). The description adds no additional parameter semantics beyond what the schema provides, but this is acceptable given 100% schema coverage.

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

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

The description clearly states it provides a 'quick overview of one pair in ONE tool call' and enumerates the specific metrics: funding rate & basis, OI trend, top-trader positioning, taker volume, order book snapshot, and price bias. It explicitly distinguishes itself from sibling tools by noting it aggregates six tools and directs users to individual tools for deeper analysis.

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

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

It explicitly says it's suitable for questions like 'how is pair X now' without needing to call tools one by one, and explicitly instructs for longer history or per-angle detail to use individual tools such as binance_get_open_interest_history and binance_get_klines. This provides clear when-to-use and when-not-to-use 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 declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral context: signals are stored score>=0.6 in D1, populated by a Cron job every 5 minutes, forward returns are computed on-demand from historical klines, limited to 50 rows per call with 2 kline lookups each, and only watchlist symbols are supported. This greatly exceeds the annotations' minimal safety hints.

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 dense sentences that efficiently cover purpose, data flow, limits, and constraints. It is well-structured and front-loaded with the main purpose, though it uses domain jargon (D1, Cron, MM) that might require familiarity with the platform's internal architecture.

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

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

With no output schema, the description appropriately indicates the return metrics (win rate, avg return, max drawdown) and explains the calculation method. It covers constraints, data source, and filtering rules, making it fairly complete for a read-only backtest tool, though the exact output structure is not specified.

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 parameters are fully documented in the schema. The description adds some contextual meaning (e.g., the 0.6 score threshold, on-demand forward return calculation, and 50-row limit), but it doesn't materially enrich parameter-specific semantics beyond the schema's own 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 clearly identifies the tool's purpose: empirically validating binance_detect_mm_activity signals by fetching stored snapshots, computing forward returns, and aggregating win rate/avg return/max drawdown. It explicitly references the sibling detection tool, distinguishing this backtest/validation role from signal detection.

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 implicitly conveys when to use the tool (for validating stored MM detection signals) and states a clear restriction (only fixed watchlist symbols with stored signal history). It does not explicitly compare against alternative tools or state when-not-to-use conditions, but the context is reasonably clear.

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

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

The annotations (readOnlyHint=true, openWorldHint=true) already declare the operation as read-only and external-world-aware. The description adds meaningful context by stating the data source (Binance native exchangeInfo) and the specific status values returned (TRADING, BREAK, HALT, etc.), which goes beyond the annotations. No contradictions exist.

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

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

The description is compact and front-loaded. The first sentence states the core function and output statuses; the second sentence adds usage guidance with emphasis (caps) on key caveats. Every word contributes to purpose or usage, with no filler.

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

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

Given the tool's simplicity (one parameter, no output schema, read-only annotations), the description is nearly complete. It explains the input relationship (Futures symbol to Spot check), the source, and the output status types. The only minor gap is not explicitly stating the return format (e.g., availability plus trading status), but this is inferable from the description and purpose.

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 provides 100% coverage for the single 'symbol' parameter, including pattern, length, example (BTCUSDT, ETHUSDT), and enforcement of it being a Binance USDS-M Futures perpetual. The description text adds no additional parameter-level detail beyond what the schema covers, 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 clearly states the tool's purpose: to check whether a pair is actually listed on Binance Spot and its current trading status (TRADING, BREAK, HALT, etc.), sourced directly from Binance native exchangeInfo. It uses a specific verb ('Mengecek apakah') and resource ('Binance Spot'), and distinguishes itself from sibling spot tools by being the pre-check for listing existence.

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 use this tool BEFORE calling other Spot tools for pairs whose listing status is uncertain, and notes that many Futures pairs (especially new/small coins) lack a Spot listing altogether. It also contrasts this with guessing from 'Invalid symbol' errors in other tools. While it names no specific alternative tool, the category 'tool Spot lain' and the error-guessing approach provide clear usage context.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds behavioral context by explaining the sorting behavior ('diurutkan dari yang paling ekstrem') and warning that open_interest is a raw snapshot not notional USD, which is a crucial nuance. This goes beyond basic read-only disclosure and provides meaningful usage warnings.

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 and front-loaded with the core function. Each phrase carries information: metric list, symbol count limit, sorting behavior, and sibling comparison. It is a bit dense but not wasteful; every sentence earns its place. Minor deduction for slight run-on structure, but overall 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?

While there is no output schema, the description covers the key aspects: what it compares, which metrics are available, sorting behavior, and the important OI notional warning. It also situates the tool among siblings. It doesn't detail return format, but for a comparison utility with these annotations and schema, the description is sufficiently complete 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?

Schema description coverage is 100%, so the baseline is 3. The description enhances this by explaining what each metric represents (e.g., funding_rate as 'funding terkini', top_trader_ratio as 'long% top trader terkini, by size posisi'). It also clarifies that symbols must be perpetual pairs and gives an example symbol list, adding practical meaning beyond the schema's basic 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 uses a specific verb 'Bandingkan' (compare) and clearly identifies the resource: multiple Futures pairs. It states exactly what it does: compares 1 selected metric across 2-10 user-chosen symbols, sorted by extremity. It also distinguishes itself from sibling binance_scan_funding_extremes by clarifying that this tool is for user-selected pairs, not market-wide scanning.

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 contrasts with binance_scan_funding_extremes: 'Beda dari binance_scan_funding_extremes yang scan SEMUA pair di market -- ini untuk pair yang sudah kamu tentukan sendiri.' This provides a clear alternative and when to use this tool. It also enumerates the selectable metrics and includes a caution about open_interest being raw OI, not USD notional, which prevents misuse.

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 far beyond the readOnlyHint and openWorldHint annotations. It discloses critical behavioral traits: the tool is not a trading recommendation, spoofing/stop-hunt scores are heuristic and lower confidence, basis arbitrage depends on watchlist history, and snapshots are saved to D1. This is exactly the kind of context that helps an agent use the tool correctly and understand its output.

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

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

The description is a single dense paragraph with clear logical flow: main function, caveat, important limitation, and a pointer to a related tool. While relatively long, every sentence adds essential information; there is no redundant padding, though it could be slightly tightened.

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

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

For a complex composite-score tool with no output schema, the description covers nearly all necessary context: what it aggregates, how it computes (heuristics, z-score), what it returns (score + tier), key limitations, and a validation path. It also notes the side-effect of snapshot storage, making it highly 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 input schema already fully describes the symbol parameter with format and example. The description adds behavioral nuance—that the symbol's presence on a watchlist affects the basis arbitrage calculation (z-score vs. simple threshold). This goes beyond the schema, enhancing parameter understanding.

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 combines 6 specific market signals into a single score and tier, explicitly framing it as a replacement for 5-6 manual tool calls. This distinguishes it from sibling tools that merely fetch raw data, making its unique 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 provides strong context for when to use the tool: when a composite of 6 signals is needed in one call. It also references binance_backtest_signal for historical validation, implying an alternative for validation. However, it doesn't explicitly state when NOT to use it (e.g., for true spoofing detection requiring multiple snapshots), leaving the exclusion partly implicit.

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

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

Annotations already mark it as read-only and open-world, so the bar is lower. The description adds valuable behavioral context: it pulls directly from Binance's native 24hr ticker endpoint using the official rolling window rather than aggregating 24 hourly candles, which explains the underlying data source and computation method.

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 action and key data fields. The second sentence adds a clear use-case statement without unnecessary 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?

For a low-complexity tool with one fully documented parameter and no output schema, the description covers the returned fields, data source, and intended usage. It could mention explicit return structure, but the field list suffices for a quick-overview tool.

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

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

With 100% schema coverage, the schema fully documents the `symbol` parameter including pattern and example. The description does not provide additional parameter semantics beyond the output fields, so baseline 3 applies.

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

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

The description uses a specific verb ('Mengambil' = retrieve) and identifies the exact resource: a 24-hour statistics summary including last price, change %, high/low, and volume. It also distinguishes itself from candle-based approaches by explicitly stating it uses Binance's native ticker/24hr rolling window, which differentiates it from sibling tools like get_klines.

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 the tool is suitable as a quick overview before deeper analysis, giving a clear use case. It also contrasts the native rolling-window method with the old 24-candle approach, implying when not to use it (when candle-based computations are needed), though it does not name specific sibling 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 state readOnlyHint=true and openWorldHint=true. The description adds behavioral context: data is granular, limit is strictly constrained, and the tool is unsuitable for long-period analysis due to the nature of the data. Also mentions the proxy relay data source. No contradiction.

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

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

The description is three sentences long, well-structured, and front-loaded with the primary purpose. The excessive capitalization and parenthetical explanation add some noise, but each sentence contributes meaningful information, so it remains concise enough.

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 gives a decent sense of what the response contains (each trade's buy/sell aggressor status) and why the tool exists. It does not enumerate all typical fields (price, quantity, timestamp), but for a simple fetch tool with strong usage guidance, it is adequately complete 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?

Schema coverage is 100% and both parameters (symbol and limit) have descriptive text. The description reinforces the limit's strict maximum but does not add new parameter-level semantics beyond the schema, 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 clearly states the tool retrieves latest individual aggregate trades from Binance, including buy/sell aggressor info. It also explicitly distinguishes itself from binance_get_taker_volume_ratio by granularity, making the 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?

Provides explicit when-to-use guidance (detecting absorption or sudden aggression spikes) and when-not-to-use (long-period analysis), directly naming the alternative tool binance_get_taker_volume_ratio for longer timeframes. This is model usage 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=true annotation, the description discloses that data comes from 5-minute snapshots, not live queries, and that history starts gradually only after deployment. It also states storage in D1 (not Workers KV) and the lack of pruning/retention, giving the agent essential expectations about data availability and growth.

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 and slightly verbose, but every sentence carries important caveats (data source, watchlist restrictions, deployment lag, storage details). The structure is front-loaded with the core purpose and then adds critical constraints. Repeated all-caps emphasis (BUKAN, HANYA) aids clarity but adds minor noise.

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 parameters and no output schema, the description covers data freshness, availability limits, and storage behavior comprehensively. It lacks an explicit description of the response format, but given the straightforward time-series nature, the context is sufficient for an agent to understand the tool's behavior and constraints.

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 context about 5-minute snapshot frequency but does not provide additional parameter details beyond what the schema already documents for symbol and hours. No explanation of output format or data shape is given.

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 reads 'histori basis futures-vs-spot' from 5-minute Cron Trigger snapshots, providing a specific verb (baca/read) and resource. It also distinguishes itself from live calls like binance_get_spot_price and enumerates the fixed watchlist, making its scope 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?

The description explicitly states when to use it: for detecting 'basis melebar lalu kembali dalam waktu singkat' (basis widening then reverting) and contrasts with live calls like binance_get_spot_price. It also clearly warns that only fixed watchlist symbols are available, providing exclusion criteria. However, it doesn't explicitly name alternative tools for other scenarios, so it falls 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 description discloses the source (native premiumIndex), the return includes basis, and it explains the weighted average nature of the index price with a noise warning for illiquid pairs. It also reveals alignment with threshold configuration via Workers KV. These details go well beyond the readOnlyHint annotation and provide valuable context about data reliability and interpretation.

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 longer than typical, but every sentence adds value: core function, interpretation, caveat, and threshold override. It is front-loaded with the primary purpose ('Mengambil funding rate TERKINI') and structured logically. While a bit verbose, it remains concise relative to the amount of useful guidance packed in.

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 covers everything needed: what it returns, how to interpret, warning about noise, and how to adjust thresholds. It also distinguishes its data source from Coinalyze, making it a complete reference for correct invocation and interpretation.

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 describes the 'symbol' parameter with format and example. The description adds no extra parameter-level semantics beyond reiterating that it's a Binance Futures pair. Since schema coverage is 100%, the baseline of 3 is appropriate; the description doesn't add 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 the tool gets the latest funding rate and basis for a Binance Futures pair, explicitly distinguishing it from Coinalyze as the native source of truth. It also separates it from history and scan tools by emphasizing 'TERKINI' (latest). The verb+resource+scope is specific and informative.

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 context on how to interpret the output (contrarian signals, threshold levels), warns about data quality for small pairs, and points to binance_set_pair_threshold for overriding thresholds. It does not explicitly contrast with sibling tools like the history or scanner, but the 'TERKINI' and pair-specific scope clearly imply when to use this tool. Overall, it gives practical usage guidance beyond a simple getter.

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 readOnlyHint and openWorldHint. The description adds valuable behavioral context: data is settled, sourced directly from Binance native, and intended for sentiment/crowding analysis. This goes beyond the annotations, although it omits pagination and rate-limit behavior.

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

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

Two concise sentences deliver the purpose, source, and use case without repetition. The key verb and object are front-loaded, making the tool easy to scan and understand.

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 historical data tool, the description covers source, data status, and use case. With no output schema, it does not explain return format, but this is a minor gap given the straightforward nature and strong 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% and the schema descriptions are detailed, including the period parameter being ignored, symbol patterns, and limit constraints. The description does not add parameter-level meaning, so the baseline 3 applies.

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

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

The description opens with 'Mengambil histori funding rate (yang sudah settled)' — a specific verb ('Mengambil') + resource ('histori funding rate') + qualifier ('sudah settled'). It clearly distinguishes from sibling tools like binance_get_funding_rate by emphasizing historical/settled data and from Coinalyze-based tools by stating it is native Binance.

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 a clear use context: to track leverage crowding trends over time and detect recent changes. It also disambiguates from Coinalyze data by declaring Binance native as the source of truth. However, it does not explicitly name alternative tools or state when not to use it.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behaviors: default returns latest candles, startTime fetches from that point forward, limit max 1500, manual pagination required, and token-saving summary mode (only includes full candle array when includeCandles is true). It also estimates token cost for 500 candles, providing valuable operational insight.

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 well-structured and front-loaded with the core purpose. It contains no filler, but it is somewhat long with dense Indonesian text. Still, every sentence contributes meaningful detail, making it appropriately sized for the tool's complexity.

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

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

With no output schema, the description adequately explains the return behavior: default returns a summary (bias, swing high/low, 15 recent candles) and full candles only when includeCandles is true. It also covers pagination, token costs, and the source distinction. This is a well-rounded description for a tool with 6 parameters and complex pagination.

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?

While the input schema already has 100% parameter descriptions, the description adds crucial semantics: startTime behavior ('returns candles from startTime forward'), pagination technique, and the reasoning behind includeCandles (token savings). This goes beyond the schema's parameter-level explanations, enriching the agent's understanding of how to use startTime and limit together.

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 it provides Candlestick OHLCV data for a pair per timeframe, and explicitly distinguishes itself as 'native Binance, bukan Coinalyze' (source of truth). It also lists concrete use cases (bias direction, swing high/low, psychological levels) and clarifies it refers to Binance Futures via the schema. This distinguishes it from sibling tools like binance_get_spot_klines.

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

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

The description gives clear context on when to use it: for direction bias, swing high/low, psychological levels, and backtesting with startTime. It also explains pagination for ranges >1500 candles. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, though it does differentiate from Coinalyze and implies futures vs spot via schema.

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 indicate readOnlyHint and openWorldHint. The description goes far beyond by disclosing that the data is lagging/reactive, that it only contains totals per time window with no price field, and that interpretation requires additional confirmation from other indicators. This is rich behavioral context that significantly aids the agent in understanding the tool's limitations and semantics.

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 longer than typical, but every sentence serves a purpose: main function, critical lagging-data warning, interpretation guidance, and usage caveat for stop hunts. It is adequately structured and front-loaded with the core purpose. Slight redundancy in the long interpretation sentences could be trimmed, but overall it earns its length.

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

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

Given there is no output schema, the description compensates well by explaining the response contains only totals per time window and no price field, plus enough interpretation guidance for long/short liquidation dominance. It references the mm_detection_framework doc for stop hunt usage. It stops short of detailing the exact response shape (e.g., list of timestamps), but the provided context is sufficient for an experienced agent.

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

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

Schema description coverage is 100%, with each parameter already explained (symbol format, limit bounds/default, period enum). The description adds minimal parameter-specific detail, only implicitly referencing the time window and per-window totals. Since the schema carries the heavy lifting, a baseline of 3 is appropriate; the description does not introduce new parameter meaning.

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

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

The description opens with a specific verb+resource statement: "Mengambil histori nilai liquidation (long dan short yang kena force-close) untuk sebuah pair Binance Futures dalam rentang waktu tertentu" — clearly distinguishing it as a historical liquidation data fetcher. It further differentiates from siblings by noting the data source (Coinalyze) and explicitly stating the response lacks price fields, setting it apart from price-centric tools like binance_get_klines.

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

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

The description provides clear context for when to use the tool: it emphasizes the data is lagging/reactive, not a forward signal, and advises confirming with funding rate/OI/price action. It also explicitly recommends cross-checking with binance_get_klines for stop hunt detection, effectively naming an alternative. However, it does not formally state 'use this instead of X' or outline when not to use it, so it's strong but not 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?

Annotations declare readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context: it specifies the data source (Binance native globalLongShortAccountRatio, not via Coinalyze) as the 'source of truth', explains the interpretation (ratio > 1 means more/bigger long positions), and discloses that the ratio is a blended aggregate. This goes beyond annotations, though it does not mention rate limits or exact return shape.

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

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

The description is compact and information-dense, with a clear opening verb, followed by key details (source, interpretation, limitation) and an alternative pointer. Every sentence contributes value, and the structure is easy to scan.

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

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

The description covers the core purpose, data source, interpretation, limitation, and alternative tool. Since there is no output schema, it partially addresses return content ('beserta tren dari waktu ke waktu') but does not specify the response structure (e.g., fields like timestamps, longAccount, shortAccount). Still, for the tool's complexity, it is sufficiently complete.

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

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

Schema description coverage is 100%, with each parameter well-documented (e.g., symbol pattern, period enum, limit range). The description does not add param-specific details beyond the schema, but it reinforces the meaning of 'pair Binance Futures' and mentions 'trend over time' which relates to period/limit. Baseline 3 is appropriate when schema fully documents parameters.

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

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

The description clearly states the tool's function: retrieving the aggregate long vs short position ratio for a Binance Futures pair (global/all accounts) including trend over time. It uses a specific verb ('Mengambil') and resource ('rasio posisi long vs short agregat'), and explicitly distinguishes itself from the sibling tool binance_get_top_trader_ratio.

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 a limitation: the ratio is a blended aggregate, not a separate retail vs top-trader breakdown, and directs users to use binance_get_top_trader_ratio for pure top-trader data. This provides clear when-to-use and alternative guidance beyond simply describing the function.

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 (readOnlyHint=true) already signal a safe read operation, and the description adds context about data source ('LANGSUNG dari Binance native') and price precision behavior ('presisi harga menyesuaikan magnitude pair'). It does not contradict annotations and provides additional behavioral detail beyond them, though it stops short of describing return structure or potential errors.

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 sentence that efficiently packs key information: output, timeframes, alternative tool, data source, and example use. It is somewhat dense with parentheticals, but every part earns its place and there is 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?

Given the tool's simplicity (one parameter, no output schema), the description covers essential aspects: what it returns (bias for 5 timeframes), how it operates (native Binance), and a typical use case. It lacks an explicit return format, but the bias values are named, making it complete enough for an agent to invoke the tool with confidence.

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 the single 'symbol' parameter with examples and constraints, so schema coverage is 100%. The description reinforces the example (BTCUSDT) but adds no additional parameter-specific meaning beyond the schema, warranting the baseline score of 3 for high-coverage situations.

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 function: obtaining directional bias (Bullish/Bearish/Sideways) across 5 specific timeframes in a single call. It distinguishes itself from the sibling tool binance_get_klines by explicitly mentioning that it avoids repeated kline calls, making the purpose and differentiation unambiguous.

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

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

It provides a clear use case: answering 'what is the bias of BTCUSDT across all timeframes right now'. It also implicitly contrasts with binance_get_klines by stating this tool avoids repeated calls, but lacks explicit exclusions (e.g., when raw kline data is needed instead). This is clear context but not exhaustive 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 annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds valuable behavioral context by explaining the data source (Binance native vs Coinalyze) and how to interpret OI changes relative to price, which is beyond the annotation scope. No contradiction with annotations is present.

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

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

The description is a single, front-loaded paragraph that directly states the tool's purpose first, then adds interpretative guidance. Every sentence carries useful information, though the interpretation section could be seen as slightly verbose for a simple getter, but it earns its place for context.

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 simple single-parameter read-only nature with strong annotations, the description is largely complete for selection and invocation. It explains the source and interpretation but does not explicitly mention the output format (e.g., unit of OI), which would be helpful since there is no output schema, but overall it is 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 input schema already fully describes the parameter 'symbol' with a pattern, example, and constraint that it must be a Binance USDS-M perpetual. The description does not add additional parameter-specific meaning beyond what the schema provides, 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?

The description clearly states that the tool retrieves the current Open Interest for a pair, with the specific qualifier 'TERKINI' (current) and 'LANGSUNG dari Binance native' (directly from Binance native). It distinguishes itself from siblings like binance_get_open_interest_history by emphasizing it provides the current snapshot, not historical data.

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

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

The description implies usage by focusing on current data and providing trading interpretations, but it does not explicitly mention when to use this tool over alternatives like binance_get_open_interest_history. It notes that the data comes directly from Binance as the source of truth, which hints at preference, but formal exclusions or alternative guidance are absent.

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

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

Annotations (readOnlyHint=true, openWorldHint=true) already indicate a safe read operation. The description adds meaningful context by emphasizing this returns historical trend data directly from Binance (not via Coinalyze) and explains the relationship between OI and price movements, going 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 concise and front-loaded, starting with the core action, then providing when-to-use guidance and interpretation rules in a compact sequence. Every sentence adds value—no fluff or redundancy—making it an efficient and well-structured description.

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

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

The tool has no output schema, so the description should ideally explain the return structure. It sufficiently conveys that it returns a history of OI values, but it does not detail the output shape (e.g., array of timestamps with OI values), currency units, or how limit/period affect the range. The interpretation guidance adds completeness, but the missing return format is a notable gap.

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

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

The input schema has 100% coverage with descriptions for all three parameters (symbol, period, limit). The description does not add significant parameter-level detail beyond what the schema already provides; it only implicitly references the period parameter when suggesting to combine with klines on the same period. No contradiction or gap.

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

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

The description uses a specific verb+resource: 'Mengambil histori Open Interest' (retrieves Open Interest history) and explicitly contrasts with a snapshot ('bukan cuma snapshot'), distinguishing it from the sibling binance_get_open_interest. It also clarifies the data source as native Binance ('source of truth'), making 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 clearly states when to use it: to answer 'apakah OI sedang naik atau turun hari ini'. It also provides usage context by recommending combination with binance_get_klines for valid interpretation. It does not explicitly name the snapshot alternative but implies it through the contrast, so it stops 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behavioral traits: it is an instantaneous snapshot that changes rapidly, walls can disappear due to spoofing/fake orders, and a single snapshot should not be treated as a definite signal. This adds substantial context about the data's volatility 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 front-loaded with a clear purpose, but it then includes a lengthy warning paragraph about spoofing and MM detection rules. While the warnings are valuable, they add verbosity and could be condensed. Overall it is somewhat wordy for a simple snapshot 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?

With no output schema, the description covers the main use case, the real-time nature, and the limitations of a single snapshot. It does not explicitly describe the return structure, but it provides enough context for the agent to understand what the tool does and how to interpret results. The guidance about not overinterpreting adds completeness.

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 covers both parameters (symbol and limit) with 100% description coverage, including allowed values and examples. The description does not add any additional parameter semantics, so the baseline score 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?

The description clearly states the tool's function: 'Mengambil snapshot order book (bid/ask) real-time dengan size per level harga' (take a real-time order book snapshot with size per price level). It is specific about the resource (order book) and distinguishes itself from siblings like binance_get_order_book_imbalance or binance_detect_mm_activity by focusing on the raw snapshot itself.

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 usage context, noting it is useful for seeing large walls, spread, and liquidity. It also warns against overinterpreting a single snapshot and directs users to the mm_detection_framework for more systematic spoofing/absorption detection, offering a rule of thumb about requiring 3 aligned signals. This gives clear when-to-use and when-not-to-use guidance, though it does not name a specific sibling tool as an alternative.

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

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

The description reveals that the tool provides a live, time-sensitive snapshot from Binance via a proxy relay and warns that order book data changes rapidly. This adds meaningful behavioral context beyond the readOnlyHint and openWorldHint annotations, though it doesn't cover error behavior or rate limits. No contradiction with annotations.

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

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

The description is a single paragraph but well-structured: it starts with the core function, differentiates from the sibling tool, and ends with an important caveat. It is compact and informative, though slightly repetitive in its closing comparison to binance_get_order_book_depth.

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 explains the return content well: ratio and bias label (BULLISH/BEARISH/BALANCED) per depth level, plus the cumulative calculation across three depths. It also covers the transient nature and the direct-from-Binance aspect, providing sufficient context for an agent to use 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 schema already provides full parameter descriptions (100% coverage) for the single 'symbol' parameter, including examples and the requirement for a Binance USDS-M perpetual pair. The tool description does not add new parameter semantics, but per the rubric, the baseline of 3 applies when schema coverage is high.

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 calculates cumulative bid-ask volume imbalance percentages at three depth levels (5, 10, 20) in a single call. It explicitly distinguishes from the sibling binance_get_order_book_depth by noting it provides a raw snapshot while this tool delivers the ratio and bias label, making the purpose unambiguous and well-differentiated.

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 the agent when to use this tool instead of binance_get_order_book_depth (for imbalance ratio and bias rather than raw order book data). It also provides a critical usage warning: the result is a momentary snapshot and should not be overinterpreted, which is strong, actionable guidance.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that the tool checks for custom vs. default settings, but it does not disclose expected return values, error behavior (e.g., symbol not found), or whether it queries local state or the exchange. It adds minimal behavioral context beyond the annotations.

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

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

The description is a single, clean sentence that immediately conveys the tool's function and key distinction. No wasted words, appropriately 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 ideally should specify the return format (e.g., boolean, threshold value, or both). The tool is simple with one parameter, and the purpose is clear, but the absence of any return information leaves a gap. It is adequate but not complete.

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

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

Schema description coverage is 100%, with the 'symbol' parameter well-documented including format and valid pair requirements. The tool description adds no additional parameter semantics, 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?

The description clearly states the tool's purpose: to check whether a symbol has a custom funding/basis threshold set via binance_set_pair_threshold or uses the global default. The verb 'cek' (check) is specific, the resource is 'threshold custom per pair', and it directly distinguishes from sibling data-fetching tools by focusing on custom settings.

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

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

The description provides clear context for when to use the tool: when you need to determine if a pair has a custom threshold versus the global default. It explicitly references the companion setter tool (binance_set_pair_threshold), giving a complementary usage signal. However, it does not mention explicit exclusions or alternative tools for other threshold-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 already declare readOnlyHint=true and openWorldHint=true, so the description adds value beyond those by explaining the calculation method, the dual output format (annualized and per-period percentages), and the rationale behind it. This goes beyond the baseline and provides context about the tool's behavior, though it doesn't cover potential caveats like rate limits.

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

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

The description is three sentences with no fluff: it states the purpose, methodology/formula, and a practical use case. Each sentence earns its place, is front-loaded with the primary function, and the technical details are presented efficiently without being overly verbose.

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 the absence of an output schema, the description explicitly mentions both display formats (annualized and per-period), the timeframes, and the interpretation of high RV. It also relates the tool to the broader Grid Advisor workflow. This provides enough contextual completeness for an agent to use and understand the tool's results.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the 'symbol' parameter beyond what the schema already provides (example formats and requirement for perpetual pairs). No further parameter explanation is needed, hence a 3.

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 calculates historical realized volatility for a Binance Futures pair, specifying two timeframes, the data source (Binance native klines), and the calculation formula. This specific verb+resource+method distinguishes it from all sibling tools, none of which offer realized volatility directly.

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 a clear use case: cross-checking the i_atrMult input in the Pine Script Grid Advisor when calibrating grid range width. It implies when to use this tool, though it does not explicitly name alternatives or when-not-to-use conditions. This earns a 4 rather than 5 due to the absence of explicit exclusionary guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the CVD interpretation (real vs leverage buying pressure), but does not mention pagination, historical depth, or other behavioral constraints. It does not contradict 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 the core action and resource. The secondary sentence adds the spot-vs-futures distinction and a practical comparison use case, with no unnecessary filler.

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

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

For a simple read-only tool with two parameters and strong annotations, the description is reasonably complete. It does not mention return format or pagination, but these are less critical given the tool's simplicity. The misleading schema description is a minor deduction.

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%, but the schema incorrectly describes the symbol parameter as being for Binance Futures (e.g., 'Harus pair perpetual'). The description itself does not clarify the symbol format or the limit parameter, leaving the agent with a misleading schema. This is a significant gap for correct invocation.

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

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

The description clearly states the tool fetches recent individual aggregate trades from Binance spot, including buy/sell aggressor side. It explicitly differentiates itself from the futures version (binance_get_agg_trades), making it distinct among 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 provides explicit guidance by naming the sibling futures tool and suggesting a use case: comparing spot CVD with futures CVD for the same pair. This tells the agent when to prefer this tool over the futures alternative.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: it explains the averaging window (last few minutes, typically 5), the 'mins' field in the response, and that it's used in Binance's internal risk calculations. 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 concise at two sentences, with the first covering the core function and the second adding a comparative use case. Every sentence serves a purpose, and it is well-structured for quick scanning.

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 tool, the description explains the main behavior, computation, and use case, but the mismatch between the tool's SPOT focus and the schema's Futures description leaves an unresolved completeness gap. The description would be complete if not for this conflicting schema text.

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 parameter is described, but the description is incorrect: it says 'Binance Futures' and 'perpetual' while the tool is specifically for SPOT. The tool description does not add or correct this, leaving the agent with contradictory and misleading parameter guidance.

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

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

The description clearly states it retrieves the current moving average price in Binance SPOT market, computed by Binance from recent trades. It explicitly distinguishes itself from the sibling tool binance_get_spot_price by highlighting stability and the 'mins' field, making its 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?

The description provides a direct comparison with binance_get_spot_price, explaining that it is more stable for price references that shouldn't be spiked by outlier trades. This gives clear guidance on when to prefer this tool, though it does not explicitly state when not to use it.

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

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

Annotations already mark the tool read-only and open-world; the description adds useful context by emphasizing real-time data, the lightweight nature compared to the full order book, and the interpretive meaning of a widening spot spread. This goes beyond the structured annotations, though it does not detail exact response fields or error behavior.

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

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

The description is front-loaded with the action and contains two tightly packed sentences with no filler. Every clause earns its place: the primary action, the comparison to the alternative, and the practical use case.

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 1-parameter, no-output-schema tool, the description adequately conveys the data returned (best bid/ask price + quantity), the real-time nature, and the decision-relevant use case. It could mention the exact key names of the response object, but the current description is sufficient for selection and basic 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 schema already documents the single 'symbol' parameter with 100% coverage, so the baseline is 3. The main description clarifies that the market is SPOT Binance, which is helpful, but it does not explicitly correct the schema's misleading description that says the symbol must be a Binance Futures perpetual pair, leaving some ambiguity for the agent.

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 action ('Mengambil best bid/ask price + quantity real-time di pasar SPOT Binance') and clearly identifies the resource (spot best bid/ask). It also distinguishes itself from binance_get_spot_order_book by noting it is lighter/faster and avoids full depth.

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

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

Explicit guidance is provided: use this tool when only an instantaneous spread is needed, and use binance_get_spot_order_book when full depth is required. Additionally, it suggests a concrete cross-check workflow with binance_get_order_book_depth for spot vs futures spread analysis, naming specific alternatives.

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 crucial behaviors: default returns only a summary (bias, swing high/low, last 15 candles) unless includeCandles is true, default returns latest candle when startTime/endTime are absent, and manual pagination for large ranges. These details are vital for an agent to correctly interpret output and manage token usage.

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 and well-structured, with each sentence serving a distinct purpose: stating the core function, comparing with the sibling tool, explaining default behavior, describing historical retrieval, clarifying pagination, and disclosing token-saving output. It is front-loaded and avoids 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 the absence of an output schema, the description adequately explains the default summary vs full candle array behavior, pagination, limit differences, and spot-vs-futures interpretation guidance. It covers all critical aspects an agent needs to use the tool correctly and safely.

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 has 100% parameter coverage with clear descriptions. The description adds context on how startTime enables deep historical retrieval, how limit interacts with pagination, and the distinction from the futures tool. However, the schema's symbol description incorrectly references 'Binance Futures' instead of spot, and the description doesn't explicitly correct this, so it doesn't fully clarify all 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?

The description explicitly states it retrieves candlestick OHLCV data from Binance spot market per timeframe, using a specific verb ('Candlestick OHLCV') and resource ('pasar SPOT Binance'). It also distinguishes itself from the sibling 'binance_get_klines' (Futures), making its scope immediately 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?

It provides clear when-to-use guidance by contrasting spot vs futures klines for volume/bias comparison, and explains when to use startTime for historical backtests. It also notes the pagination requirement for ranges >1000 candles and the difference between spot (1000) and futures (1500) limits, giving practical direction for selecting and invoking the tool.

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

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

Beyond the readOnlyHint annotation, the description adds that the snapshot is 'SESAAT' (momentary) and the order book changes quickly, warning users about the transient nature. It also notes the data comes 'LANGSUNG dari Binance native', indicating real-time, direct source—useful behavioral context not in the annotations.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a use-case rationale and a brief caution. The middle sentence is slightly long but contains valuable comparative insight. Overall, it is concise enough without redundant phrasing, earning a 4.

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 snapshot tool with two parameters and no output schema, the description provides sufficient context: market (spot), real-time nature, and the analytical rationale for comparing with futures. It lacks explicit return-format details, but the order book structure (bids/asks) is conventionally implied, making it reasonably complete.

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

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

Schema coverage is 100%, but the schema's symbol description incorrectly refers to Binance Futures/perpetual pairs. The description corrects this by clarifying the tool operates on the SPOT market and is the spot counterpart to the futures version, adding crucial semantic meaning beyond the schema's misleading text. The limit parameter is not elaborated, but the schema already specifies allowed values.

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 takes a real-time order book (bid/ask) snapshot on Binance SPOT, with a specific verb ('Mengambil snapshot') and resource. It distinguishes itself from the sibling tool binance_get_order_book_depth (Futures) by explicitly naming it and labeling this as the 'Spot version.'

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 an explicit use case: comparing wall/liquidity between spot and futures, with reasoning about leverage vs. real holder commitment. It names the alternative (futures version) and implicitly directs users to use this tool for spot analysis, making the choice 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?

Discloses important behaviors beyond annotations: it is a snapshot, fails on futures-only pairs with a clear error (explicitly not a bug), and uses direct spot price rather than multi-exchange index. Even though annotations already declare readOnlyHint=true, the description adds operational nuances like temporal limitations and failure modes.

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

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

The description is moderately long but every sentence adds value: purpose, key distinction, application, warning, alternative tool reference. It is front-loaded with the main function and organized into logical chunks. Slight verbosity in the middle section but 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?

With no output schema, the description covers the tool's purpose, use cases, caveats, and alternatives well. It lacks explicit details about the output shape (e.g., whether basis is in absolute price or percentage), but given the simplicity and clear focus on one snapshot, the information provided is sufficient for effective use.

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 provides a full description of the 'symbol' parameter (pattern, examples, requirement for perpetual pairs). The description enriches this by noting that some futures pairs may not have spot listings and gives example watchlist symbols (BTCUSDT/ETHUSDT/SOLUSDT), adding practical guidance 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?

Description clearly states the tool fetches Binance SPOT price (not futures) plus a real basis against futures mark price, explicitly differentiating it from funding rate tools and history tools. The verb 'Mengambil' (take/retrieve) plus resource 'harga SPOT Binance' is specific and 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?

Provides explicit guidance: use this snapshot for detecting basis widening as early warning, check binance_check_spot_listing first if unsure about futures-only pairs, and switch to binance_get_basis_history for time-series analysis. It also contrasts with binance_get_funding_rate by explaining the calculation difference (direct spot vs index average), giving clear when-to-use context.

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

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

Annotations already declare readOnlyHint, so the description adds value by detailing the native Spot ticker source, the data fields returned, and the error semantics for invalid symbols. It also includes a useful interpretation note about spot vs futures volume driving price moves. No contradiction with annotations.

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

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

The description is compact and front-loaded with the primary action and market type. It follows with an alternative tool reference and an important error note. The listing of fields is slightly redundant but still earns its place for clarity.

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

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

For a single-parameter read-only tool, the description covers purpose, data fields, error handling, and comparison with alternatives. However, the mismatch between the schema's 'Futures' symbol description and the tool's Spot focus creates a clarity gap that the description does not fully resolve. No output schema exists to clarify return structure.

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 description incorrectly says the symbol is a Binance Futures perpetual pair, which directly contradicts the tool's Spot purpose. The tool description only indirectly implies the symbol should be a spot symbol through the 'SPOT' mention and the 'futures-only' error note, but it does not correct or compensate for the misleading schema parameter documentation.

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

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

The description clearly states it retrieves 24-hour statistics for the Binance SPOT market ('Mengambil ringkasan statistik 24 jam di pasar SPOT Binance'), lists specific fields (last price, change %, high/low, volume, VWAP, trades), and distinguishes itself from the sibling futures tool by name.

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 binance_get_24hr_ticker as the Futures alternative, says 'bukan Futures' (not Futures), and gives guidance on interpreting spot vs futures volume/change. It also explains the 'Invalid symbol' error as indicating a futures-only pair, which helps the agent decide when to use the tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds context about the data being a proxy for aggressive pressure and that it comes directly from Binance's native takerlongshortRatio. It doesn't describe return format or rate limits, but with annotations covering the safety aspect, this is adequate.

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 and front-loaded with the primary purpose. It includes useful distinctions and source information, though the parentheticals and Indonesian phrasing make it slightly less concise than ideal. Every sentence earns its place but could be tightened.

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 simple 3-parameter tool, the description explains the concept and data source but does not mention what the response contains (e.g., historical ratio values, timestamps). It is adequate for understanding the tool's purpose but incomplete for fully predicting the return value, especially 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 description coverage is only 33%, with only 'symbol' having a description. The tool description does not explain 'limit' or 'period', nor does it add any parameter meaning. Since coverage is below 50%, the description should compensate but fails to do so, leaving parameter semantics under-specified.

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 it retrieves the taker buy/sell volume ratio, serving as a proxy for aggressive market order pressure. It explicitly distinguishes itself from the long/short ratio which is based on open positions, and mentions the data source (Binance native takerlongshortRatio). This is a specific verb+resource with clear differentiation from 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 provides context on when to use the tool: as additional confirmation of whether current market execution pressure leans buy or sell. It also contrasts with long/short ratio, implying when not to use it. However, it does not explicitly mention alternative tools or exclusions beyond that, 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?

Beyond the readOnlyHint, the description discloses that names and descriptions are auto-generated from the tool registry and always accurate, and that 'uncategorized' means the tool hasn't been manually curated, with useCase potentially truncated. This is valuable context about data reliability and fallback behavior that the annotations do not cover. No contradiction with annotations.

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

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

The description is only two sentences, with the first precisely stating the tool's output and the second providing usage guidance and caveats. Every clause carries information, with no filler or redundancy. It is front-loaded with the core purpose.

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 simple schema (one optional param), read-only annotations, and no output schema, the description compensates well by stating what the catalog contains and how to use it effectively. It also warns about potential data quirks (uncategorized/truncated), covering the main questions an agent might have. The absence of an output schema makes the description's return-value summary essential, and it delivers.

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 fully documents the 'category' parameter with an enum and description. The description adds further meaning by explaining why filtering matters (to identify relevant use-cases and composite tools) and clarifying the 'uncategorized' edge case. This goes beyond the schema's literal definition.

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 lists all WhaleScope MCP tools with categories, token cost, use-case, and dependencies, which differentiates it from the data-fetching sibling tools. Verb 'Daftar' (list) and resource 'tool WhaleScope MCP' make the function explicit and unmistakable. It also notes the catalog is useful before calling individual tools, reinforcing its meta-purpose.

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

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

It explicitly says 'Berguna sebelum manggil banyak tool individual' (useful before calling many individual tools), giving a clear trigger for use. It advises checking relevant categories and use-cases to avoid mistakes and to discover composite tools. It doesn't provide explicit when-not-to-use or alternative tools, but the guidance is sufficient for this catalog function.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, but the description adds significant behavioral context: data comes directly from Binance via a proxy relay (not Coinalyze), and is a snapshot periodical rather than tick-by-tick. It discloses the limitation that the 'top trader' threshold is not published by Binance, and explains how mode affects interpretation (account count vs position size weight). This complements the annotations and adds depth.

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 essential purpose and mode distinction, then proceeds to limitations and usage guidance. It is longer than ideal but every sentence carries unique information; the structure makes it skimmable. The use of CAPS/emphasis helps key points stand out, though the length slightly reduces conciseness.

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 complexity (two modes, data source, limitations, integration with a detection framework) and no output schema, the description is remarkably complete. It tells the agent exactly what the data means, how to interpret it, and what pitfalls to avoid. The sibling context is addressed via the explicit comparison to binance_get_long_short_ratio.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds interpretive meaning for 'mode' by explaining the relevance of position-size weighting, but the schema already describes the values. No additional parameter syntax or format details are needed beyond what the schema provides.

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

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

The description clearly states it provides the top-trader long/short ratio specifically for Binance Futures, separated from retail, and distinguishes it from the blended binance_get_long_short_ratio. It explains both modes ('account' vs 'position') and explicitly contrasts with sibling tools, making the tool's unique 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 gives explicit when-to-use guidance, including the distinction from binance_get_long_short_ratio (blended vs top-trader) and its relevance to whale positioning. It also warns against using absolute thresholds and advises comparing relative to the pair's own history, referencing the mm_detection_framework. This is actionable and goes beyond generic context.

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

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

The description adds context beyond the annotations by disclosing the calculation method (ADX(14) from 1-hour klines, OI trend, CVD, volatility/volume spike ratio) and a key limitation (it does not use a persistent historical baseline because time-series storage is unavailable). This aligns with readOnlyHint/openWorldHint and provides behavioral insight not present in 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 a single, information-dense sentence followed by one usage sentence. It front-loads the classification and enumerates the regimes and inputs without redundant filler, and every phrase earns its place.

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

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

Given the tool's moderate complexity (one parameter, no output schema), the description covers the purpose, method, limitations, and usage context. It does not spell out the exact return format, but it states the output is one of six regimes, which is likely 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 input schema already includes a complete description of the `symbol` parameter (Binance USDS-M Futures perpetual pair with pattern and length constraints), covering 100% of the schema. The tool description adds no additional parameter information, so the baseline score 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?

The description clearly states the tool classifies current market conditions into one of six named regimes (TRENDING_UP, TRENDING_DOWN, RANGING, BREAKOUT, ACCUMULATION, DISTRIBUTION), and it specifies the data sources used. This distinguishes it from sibling tools that fetch raw data (e.g., binance_get_funding_rate) by presenting it as a synthesis/analysis tool.

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

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

The description explicitly says it is useful to provide macro context before reading individual signals like funding, OI, and order book, giving a clear usage recommendation. It does not mention exclusions or name specific sibling alternatives, but the 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 only provide readOnlyHint and openWorldHint, so the description takes on the burden of explaining behavior. It adds valuable context about the implementation (a single call to premiumIndex without symbol, not a per-pair loop, making it much cheaper), the sorting/return behavior, and the threshold. This exceeds the baseline but stops short of disclosing potential edge cases (e.g., behavior when no pairs exceed threshold).

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 first sentence explains the core functionality and performance advantage, the second gives the use case and relationship to a sibling tool, and the third notes the threshold. Every sentence adds value 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?

Despite lacking an output schema, the description conveys what the tool returns (the most crowded long and short pairs) and why it's efficient. It does not detail the exact output fields or behavior with the limit parameter, but the schema covers parameter semantics. Overall, it provides sufficient context for an agent to select and invoke 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?

Schema description coverage is 100%, with both parameters (limit and quoteFilter) having clear descriptions, defaults, and constraints. The tool description does not add additional parameter-level meaning beyond what the schema already provides, so the baseline score 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 clearly states the tool's function: scanning funding rates across ALL Binance Futures pairs in one call, then sorting and returning the most crowded long and short pairs. It uses a specific verb ('scan') and resource ('funding rate semua pair Binance Futures'), and explicitly distinguishes itself from binance_get_funding_rate which requires a symbol.

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 guidance: for questions like 'which pair has the most extreme funding right now' without needing to know a specific symbol. It names the complementary tool (binance_get_funding_rate) and even clarifies that the crowded threshold matches that tool (±0.03%), leaving no ambiguity about alternatives.

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 annotations (readOnlyHint=false, openWorldHint=true), the description discloses key behavioral traits: persistence ('Disimpan permanen di Workers KV sampai di-overwrite'), overwrite semantics, and the reset behavior ('Kirim tanpa salah satu parameter (undefined) untuk reset field itu balik ke default'). It also reveals that the thresholds affect other tools by replacing their defaults, giving the agent a complete understanding of side effects.

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 long and every sentence earns its place: the first states the core action, the second explains the rationale, and the third covers persistence and reset. It is front-loaded with the primary operation, avoids fluff, and is appropriately sized for the tool's complexity.

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

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

For a low-complexity mutation tool with no output schema, the description is quite complete: it covers purpose, when to use, persistence, reset behavior, and the relationship to other tools. The only notable omission is the lack of explicit information about the return value/response format, which an agent would need to confirm success. Given the simplicity, this gap is minor but still 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% and each parameter already has detailed descriptions with examples and default values (e.g., basisThreshold: 'default (0.0005)', fundingThreshold: 'default (0.0003)'). The description adds the percentage equivalents (±0.03%, ±0.05%) and clarifies reset semantics, but these are largely redundant with the schema's 'kosongkan' instructions. Therefore, the description provides marginal additional 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 states the tool's action ('Simpan threshold funding rate dan/atau basis custom untuk sebuah pair') and identifies the resource (per-pair thresholds). It distinguishes itself from siblings by explicitly referencing the default thresholds used by binance_get_funding_rate and binance_get_spot_price and by complementing the getter binance_get_pair_threshold. The mention of 'menggantikan default hardcoded' makes the unique purpose obvious.

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 strong contextual usage guidance by explaining why custom thresholds are needed: 'pair volatil (altcoin kecil) dan pair stabil (BTC/ETH) punya rentang funding/basis normal yang beda jauh -- threshold universal bisa false-positive di pair volatil atau kurang sensitif di pair stabil.' This tells the agent when the tool is appropriate. It also describes how to reset fields to default, but it does not explicitly state when not to use the tool or name alternative setters (though none 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses valuable behavioral traits: automatic symbol mapping across exchanges, partial failure handling (rows marked unavailable without failing the whole call), and the ability to compare cross-exchange confidence. These add significant context 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 dense but front-loaded with the core purpose. It uses dashes to list additional capabilities. While every segment adds value, it is a long run-on sentence that could be more concise and structured, so it does not achieve a perfect score.

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 provides a reasonable mental model of the output: it mentions comparing metrics, detecting divergence, showing OI per exchange, and handling missing pairs row-wise. This is fairly complete for a one-parameter tool with good annotations, though it could be more explicit about the return format.

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

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

The schema description covers the parameter fully (symbol in Binance Futures format, examples given). The tool description adds extra insight by explaining the symbol is auto-mapped to each exchange's format, which is not in the schema, thus enhancing parameter understanding.

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 action: compare funding rate, last price, open interest, and 24h change for a single pair across Binance, Bybit, OKX, and Hyperliquid. It also distinguishes itself from sibling tools by being cross-exchange while siblings are Binance-specific, and explicitly references cross-confirming binance_detect_mm_activity.

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 a clear usage context: detect funding divergences, see OI concentration, and cross-confirm signals from binance_detect_mm_activity. It names the specific sibling tool to cross-confirm with, but does not explicitly state when not to use this tool or provide alternative exclusions, 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.