WhaleScope MCP

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

Annotations already mark the tool as read-only and closed-world, and the description adds meaningful behavior beyond that: it rejects inputs when the time windows do not overlap enough, relies on caller-supplied data, and warns that low-liquidity window guidance is extrapolated rather than independently validated. 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 front-loaded: the first sentence states the core operation and input constraint, while the second covers the rejection condition and window recommendations. It is somewhat dense, but the extended caveats about validated vs extrapolated assumptions are directly relevant to correct use.

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

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

It covers prerequisites, input provenance, overlap rejection behavior, and important reliability caveats, which is strong for a complex analytical tool. The lack of an output schema means the return shape is not described, but the schema and description together give enough context for an agent to 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 coverage is 100%, and every parameter already has rich descriptions, including minOverlapRatio and neutralThresholdPct with validation caveats. The description only reinforces the caller-supplied source and the overlap rejection behavior; it adds little meaning beyond what the schema already provides.

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

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

The description uses a specific verb ('Bandingkan' / compare), names the exact resources (CVD between Spot and Futures), and states the required input source (agg-trades supplied by the caller). It also distinguishes itself from data-fetch siblings by explicitly saying 'BUKAN fetch sendiri'.

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

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

It gives clear usage instructions: pass results from binance_get_agg_trades and binance_get_spot_agg_trades, and do not fetch internally. It also defines the overlap rejection rule as a gating condition. However, it does not explicitly contrast this tool with other analysis siblings under alternative scenarios.

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

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

Annotations include readOnlyHint and openWorldHint, and the description adds valuable behavioral context: risk calculations are approximate and treat all positions as isolated-margin regardless of actual margin mode. It also discloses the circuit-breaker statuses. This goes beyond the annotations without 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?

Two sentences efficiently convey the tool's purpose, key analysis components, behavioral caveat, and output statuses. Every element earns its place, and the description 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?

For a complex analytical tool with no output schema, the description provides a solid overview of the analysis dimensions and resulting statuses. It could have elaborated on the exact output format or dependencies between parameters, but given full schema coverage and annotations, it is sufficiently complete for an agent to understand scope.

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 all parameters are individually documented. The description does not add additional meaning to specific parameters beyond what the schema provides, such as relationships or calculation impact. Baseline 3 is appropriate given full 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 the tool analyzes Binance Futures long-grid risk and lists specific components (core grid math, Market Regime context, Top-Trader/OI squeeze risk, dynamic stress, circuit-breaker decision). It distinguishes from sibling data-retrieval tools by describing a composite risk analysis with explicit outcome statuses.

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 for long-grid risk analysis but provides no explicit guidance on when to use vs alternatives or when not to use. It lacks references to alternative tools or exclusions, leaving the agent to infer context from the title and description.

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 and openWorldHint, so the safety profile is covered. The description adds useful behavioral detail beyond the annotations by disclosing that six tools are combined via Promise.all, and it lists what data is included. It does not, however, explain rate-limit impact or output shape/rounding.

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

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

The description is two sentences with no filler: the first fronts the composite concept and lists the components, the second adds the longer-history alternative. Every part earns its place and it 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 composite tool has moderately high complexity with six aggregated outputs and no output schema, yet the description does not explain the return shape/format at all. It conveys what is aggregated and when to choose an alternative, but an agent might not know how results are organized or what the 'overview' looks like.

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

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

Schema coverage is 100%, and the symbol parameter's description already includes the pattern, examples, and a requirement that the pair be a listed Binance USDS-M perpetual. The tool description adds no extra parameter semantics, 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 this tool provides an overview of one pair in a single call and enumerates six concrete data components: funding/basis, 6h OI trend, 4h top-trader, 4h taker volume, order book, and 24-candle 1h price bias. It also distinguishes itself from individual sibling tools by explicitly naming the composite Promise.all aggregation.

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 for longer history, use the individual tools (e.g., binance_get_open_interest_history), which is a clear when-not and alternative-to guidance. The composite purpose is also evident: quick multi-signal overview in one call.

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

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

Annotations provide readOnlyHint and openWorldHint, which the description does not contradict. The description adds value by explicitly stating that confidenceScore is NOT a calibrated probability and points to documentation for threshold limitations. It also discloses the output conditions (LONG_LIQUIDATION_RISK, etc.), which helps set expectations beyond the schema.

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

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

The description is dense yet structured: first sentence states core purpose and variables, second clarifies what it is not, third lists output conditions, and fourth adds a confidenceScore caveat. No wasted words, but it is slightly long. Still, each sentence adds meaningful information.

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

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

The tool is complex (5 input variables, composite score, condition output), and there is no output schema. The description compensates by explaining the score type, conditions, and the non-calibrated nature of confidenceScore, plus a doc reference for further limits. It covers the essential context an agent needs to interpret results correctly.

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

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

Schema description coverage is 100% (the single parameter symbol has a clear description with pattern and examples). The tool description does not add additional parameter guidance, but since the schema already covers it, 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 computes a divergence score between smart money and retail using five specific variables listed. It explicitly distinguishes itself from price manipulation detection, saying it measures directional divergence. This is a specific verb-resource-purpose and differentiates from sibling tools like 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 explicitly clarifies what the tool is NOT for ('BUKAN deteksi manipulasi harga'), which implicitly guides against using it for that purpose. It provides a doc reference for threshold limitations, but does not name an alternative tool or state explicit when-to-use scenarios. Still, the exclusionary statement gives clear contextual guidance.

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

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

The description goes well beyond the readOnly/openWorld annotations by disclosing that forward returns are computed on-demand from historical klines, that each row triggers two kline lookups, that results are limited to the 50 newest rows, and that data is populated by a Cron job every 5 minutes. This gives the agent a strong understanding of cost, freshness, and limitations.

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 well-structured: it front-loads the core purpose, then explains the computation model, limits, and data source. Every sentence adds value and there is 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?

For a read-only backtest tool, the description covers inputs, processing logic, output metrics, and constraints. It does not describe the exact output shape or what happens when no signal history exists, but it names the aggregate metrics and the absence of an output schema reduces the obligation.

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 adds useful context around the signal selection threshold (score >= 0.6) and the forward-return concept, but it does not add meaningful semantics beyond what the input schema already provides for symbol, startTime, endTime, signalType, and forwardWindow.

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: empirical validation of binance_detect_mm_activity signals, including the specific process of taking signal snapshots, computing forward returns, and aggregating win rate, avg return, and max drawdown. It uses a specific verb ('Validasi empiris') and resource, and is easily distinguishable from the sibling detector 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 gives clear context on when this tool is appropriate: it backtests previously stored signals from binance_detect_mm_activity rather than detecting or fetching live signals. It also states important constraints like watchlist-only symbols and the 50-row limit, though it does not explicitly say 'use X instead when...'.

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 adds meaningful behavioral context: it verifies against exchangeInfo, returns status values, and emphasizes 'BENAR-BENAR listed' to signal authoritative verification. It does not contradict the annotations.

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

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

The description is two focused sentences, with the core action and status values front-loaded. Every part adds value: the source endpoint, the statuses, and the usage guidance. 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?

For a single-parameter, read-only tool with no output schema, this is nearly complete: it explains what is checked, where data comes from, what statuses are relevant, and when to use it. It stops short of describing the exact return shape or what happens for an unlisted symbol, but that is a minor gap.

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

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

Schema coverage is nominally 100%, but the schema's symbol description is inconsistent with the tool purpose: it describes 'Binance Futures' and 'perpetual pair' while the tool is about Spot listing. The tool description does not clarify the correct symbol format or correct this mismatch, undermining 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 uses a specific verb+resource+scope: it checks whether a pair is truly listed on Binance Spot and returns its trading status (TRADING/BREAK/HALT), directly from exchangeInfo. It also distinguishes itself from the many spot-data sibling tools by framing itself as a pre-flight listing verification, not a market-data retrieval.

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 other Spot tools when listing is uncertain, and to avoid guessing from 'Invalid symbol' errors. This gives clear when-to-use context and an alternative, though it does not state explicit when-not-to-use conditions.

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 is rich with behavioral details: 2-snapshot order-book mechanics, ~1-2 second latency, Binance sampling rate, confidence differences, fallback behavior, and evidence text. However, it states that snapshots are also saved every 5 minutes to D1, which is a write side effect and directly contradicts the readOnlyHint: true annotation. Per the rubric, this is an annotation 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 main purpose is front-loaded in the first clause, and the subsequent dense sentences carry substantive caveats about data sources, latency, fallback, and confidence. It is long, but the complexity of a six-signal detector justifies most of the detail; a slightly tighter edit would earn a 5.

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

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

The description specifies the composite output (score, tier, evidence text) and directs the agent to documentation for full limitations, which covers most operational needs. However, with no output schema present, it does not spell out the exact response structure or tier thresholds, leaving some ambiguity.

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 100% coverage for the single symbol parameter, including pattern, length, and example values. The description does not add any additional parameter-specific 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 verb 'Gabungkan' and the exact resource: six MM/whale signals combined into one score plus a tier. It also separates this tool from single-signal siblings by noting it replaces 5-6 manual tool calls and explicitly says it is not a trading recommendation.

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 consolidation use case ('ganti 5-6 tool call manual') and a negative boundary ('BUKAN rekomendasi trading'). It does not name specific sibling alternatives or provide explicit when-to-use versus when-not-to-use criteria, so it falls just short of full 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 and openWorldHint, so the read-only nature is covered. The description adds that it uses the official rolling window, which is useful context, but it does not disclose any other behavioral aspects like rate limits or return format. It adds moderate value beyond 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 concise with two sentences, front-loading the key information (what it returns, source) and ending with a brief use-case hint. No unnecessary words or repetition.

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

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

For a simple single-parameter tool with no output schema, the description lists the main fields returned (last price, change %, high/low, volume) but does not specify the exact return structure or any additional limitations. The schema covers the symbol constraints, so the description is adequate but not exhaustive.

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 documentation for 'symbol' is 100% covered, including the requirement for perpetual pairs on USDS-M Futures. The description does not add any additional parameter meaning beyond what the schema already 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 it provides a 24-hour statistics summary including last price, percentage change, high/low, and volume. It mentions 'native ticker/24hr' and 'official rolling window,' which specifies the source. However, it does not explicitly differentiate from the sibling binance_get_spot_ticker_24hr, though the schema's mention of USDS-M Futures implies the distinction.

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 says 'Quick overview before deeper analysis,' which gives contextual guidance on when to use it. However, it does not explicitly state alternatives or when not to use it, such as 'use binance_get_spot_ticker_24hr for spot pairs.' The guidance is implied but not explicit.

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

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

Given annotations already declare readOnlyHint and openWorldHint, the description adds valuable behavioral context: the 30-minute update cadence, the aggregate symbol-level scope, and the non-real-time nature. This goes beyond the annotations and clarifies important limitations.

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

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

The description is two sentences, front-loaded with the result values and core scope, then a critical caveat. Every sentence earns its place with no redundancy.

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

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

For a simple one-parameter read-only tool with no output schema, the description is complete: it states the return categories (LOW/MEDIUM/HIGH), scope, source, and update limitation. No essential behavioral or usage context is missing.

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

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

The schema fully describes the single 'symbol' parameter with pattern, length limits, and examples, so the description does not need to add much. The description's 'per pair' phrasing aligns with the schema but adds no new semantic detail.

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

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

The description uses a specific verb and resource: 'Rating risiko Auto-Deleveraging (ADL) LOW/MEDIUM/HIGH per pair' directly from Binance. It also distinguishes the tool by clarifying it is symbol-level aggregate risk, not position-level, separating it from other analysis tools.

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

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

The description provides clear usage context by stating the data updates every 30 minutes and is for general risk context, not precise execution decisions. It effectively communicates when not to rely on it, though it does not explicitly name alternative tools.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so safety is already covered. The description adds meaningful behavioral context: the default returns a concise summary with CVD and the last 15 trades, while detail:'full' returns the raw trade array, and the 200 limit makes it unsuitable for long periods. This goes beyond basic annotation coverage, though it does not detail exact trade field structure.

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

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

The description is a single dense paragraph with every sentence serving a purpose: purpose, use cases, distinction from sibling tool, limitation, and output mode defaults. It is front-loaded with the core function and avoids redundant repetition of schema content.

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 lightweight read-only tool with only 3 parameters and no output schema, the description adequately covers purpose, typical use cases, limitations, and both output modes. It does not mention trade ordering or exact timestamp boundaries, but those are minor given the schema and tool simplicity.

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

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

Schema description coverage is 100%, so the schema already fully documents symbol, limit, and detail parameters, including defaults, constraints, and enum meanings. The description adds no new parameter semantics beyond referencing detail:'full' and the 200 limit, which are already present in the schema.

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

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

The description begins with a specific verb and resource: 'Trade individual terbaru (aggregate trades), granular per-trade, termasuk sisi buy/sell aggressor.' It clearly distinguishes itself from binance_get_taker_volume_ratio by contrasting per-trade granularity with per-hour aggregation, making its unique purpose evident.

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 this tool: to detect absorption ('harga stagnan tapi volume besar searah') or sudden aggression spikes ('lonjakan agresi mendadak'). It also provides exclusions ('bukan untuk periode panjang') due to the 200-limit, and names an alternative tool, giving the agent clear decision 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 set readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: frequent rate limiting and error-handling advice. It doesn't contradict the annotations and enriches the agent's expectations about 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?

Two concise sentences pack the core purpose, the main caveat (rate limiting), the error-handling advice, and the exclusion of a sibling. No filler, front-loaded with the most important information.

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

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

For a read-only market-wide data tool, the description covers the critical caveats (rate limit, not a substitute) and the schema documents parameters and the detail output format. It could mention return structure explicitly, but the schema's detail description references docs, 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 description coverage is high (80%), and the 'detail' parameter's meaning (summary vs full) is already explained in the schema. The description does not add parameter-specific semantics but doesn't need to given the schema coverage; baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Histori liquidation / force orders market-wide') and explicitly names the sibling it is not ('Bukan pengganti data liquidation-by-price'). This makes it clearly distinguishable from the dozens of sibling tools without needing to inspect schemas.

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

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

It provides explicit guidance: cautions that the endpoint is often rate-limited ('endpoint ini sering dibatasi Binance'), advises handling errors well, and clarifies it is not a substitute for liquidation-by-price data (which is WAF-blocked). This tells the agent when to use it and when to avoid it, with a clear alternative.

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

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

The annotations (readOnlyHint=true, openWorldHint=true) are consistent with the description (a read-only data fetch). The description adds valuable context: the default summary mode returns derived metrics and at most 10 points to save tokens, and the 'detail: full' option provides raw levels. It also warns about potential output size. The openWorldHint is not elaborated, but the description covers the main behavioral aspects.

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 front-loaded with the core purpose and endpoint. It uses an em-dash to break up the content, which is a stylistic choice. The use cases and differentiation appear early, and the default/detail explanation is efficient. Slightly verbose but no redundant 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 simple read-only tool with full schema documentation and no output schema, the description covers the essential distinctions from siblings and the key behavior modes. There is no mention of pagination or exact output structure, but the summary/full detail is explained and references a docs file. The tool is not complex, and the description is adequate for correct invocation.

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

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

Schema coverage is 100%, so parameters are already fully documented. The description adds context for the 'detail' parameter (summary vs full) and explains the token-saving benefit, which goes beyond the schema's description. The 'symbol' parameter description mentions it is sent as 'pair' to Binance, adding useful API mapping. However, since the schema already covers most semantics, a 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 explicitly states the tool fetches historical basis data from Binance's official endpoint, distinguishing it from the sibling binance_get_basis_history. It clearly specifies the resource (futures data basis endpoint), the measured quantity (futures price vs index price), and the period intervals. The distinction from the sibling is crisp: this tool is the source of truth for historical premium/discount, while the sibling uses a snapshot D1 cron with a fixed watchlist.

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 names the sibling tool explicitly and explains the key difference (snapshot D1 cron vs official endpoint), making it clear when to choose one over the other. It also lists specific use cases: detecting extreme premium, mean-reversion basis, and confirming funding lag. No exclusionary conditions are mentioned, but the use cases and differentiation are strong.

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 provide readOnlyHint=true and openWorldHint=true. The description adds that data comes from 5-minute Cron snapshots rather than live quotes, which is a meaningful behavioral disclosure beyond the annotations. No contradictions.

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?

Description is brief, front-loaded with the core purpose, and every sentence adds distinct information: what the tool returns, how it's produced (cron snapshots), how it differs from live, and the compressed vs. full output modes.

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

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

There's no output schema, so the description must partially cover what the tool returns. It mentions 'metrik turunan + <=10 poin terbaru' vs. 'array/level mentah lengkap', which gives some shape. However, it references a separate doc (docs/tool_response_reference.md) and assumes familiarity with 'basis history' concepts. For a tool with 3 params and no output schema, this is adequate but not exhaustive.

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 covers all 3 params with good descriptions. The description adds semantic context: it explains the time-series nature by noting the 5-minute snapshot cadence, and clarifies the 'detail' param leads to different output sizes ('hemat token'). This adds value beyond the schema's type/constraint info.

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

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

The description clearly states a specific verb, resource, and scope: it returns historical basis derived from 5-minute Cron snapshotsapp, and explicitly contrasts itself with the live sibling tool binance_get_basis. An agent can immediately identify this is the historical variant, not the live one.

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

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

It names the alternative (binance_get_basis) and specifies that this is NOT live, which tells an agent when to prefer it (historical analysis vs. current snapshot). It doesn't list broader when-not-to-use conditions, but the core distinction is present.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds meaningful behavior beyond that: it reveals that omitting symbol returns all pairs and warns about potentially large payloads. It also notes the endpoint. This is useful context that annotations do not provide, so a score of 4 reflects the added value.

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 highly compact, front-loading what the tool returns and then providing the endpoint and caveat. Every sentence carries value, though the mix of Indonesian and English may slightly reduce clarity for some agents. Still, it is appropriately concise and well-ordered.

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 one-parameter read-only tool with no output schema, the description covers the main usage, the empty-symbol behavior, and a payload caution. It doesn't describe the return structure, but that's acceptable given the absence of an output schema. It is complete enough for correct invocation, with the only minor gap being lack of explicit response 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?

Schema coverage is 100% and the schema describes the symbol parameter thoroughly. The description adds critical semantic detail: specifying that an empty symbol returns all pairs, which is not stated in the schema. This goes beyond the schema, improving 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 it returns the best bid/ask price and quantity, specifies the exact endpoint (GET /fapi/v1/ticker/bookTicker), and distinguishes itself as 'very light compared to full depth', which differentiates it from depth-related siblings like binance_get_order_book_depth. It also notes the behavior when symbol is empty, 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?

The description explicitly contrasts with 'full depth' (implying an alternative depth tool) and warns about the large payload when symbol is empty, guiding when to use it vs. alternatives. It lacks a direct 'use when you need light data' statement or explicit exclusions, but the context and caution provide clear 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?

description adds critical behavioral context: it returns empty/error for non-index symbols, clarifying expected failure modes. Annotations include readOnlyHint=true (safe read) and openWorldHint (may return unknown data), which aligns; the description enriches this by specifying scope. No contradiction, and it improves transparency.

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

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

The description is concise: two sentences, front-loaded with the core value, and the warning section is brief but essential. No filler or repetition.

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

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

Given the tool's simplicity (1 optional param, no output schema, annotations present), the description fully covers purpose, usage scope, and failure behavior. The lack of return details is acceptable because no output schema exists, but the description's warning is sufficient given the tool's narrow focus.

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 covers the symbol parameter fully (pattern, optional, description). The description reinforces the parameter relevance (only for composite index) but does not add new syntax or format details. Since schema coverage is 100%, baseline is 3, but the description's clarification that it's optional and for all indices when omitted adds a small increment.

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 composite index information (base assets and weights) for a specific symbol, and notably distinguishes it from regular pairs (BTCUSDT) by warning they return empty/error. This is a specific verb (get/info) plus resource, effectively differentiating it from sibling tools like get_index_constituents.

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

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

It explicitly states when to use it (only for composite index symbols) and when not (regular pairs), which is strong guidance. However, it does not mention alternatives like get_index_constituents or when to use those instead, so it lacks full alternative differentiation.

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

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

Annotations include readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds useful context such as the token-saving `summary` mode (which returns fewer points) and the availability issue for dated contracts, going 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 two sentences, well-structured: first states purpose and key distinction, second provides critical usage note. It front-loads the most important information and has zero wasted words.

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 key aspects: purpose, input format, availability constraints, and token-saving behavior via `detail`. It references docs for output details, which is acceptable given openWorldHint. It adequately handles a 7-parameter tool with 3 required ones.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant semantic value by explaining the `pair` format (no margin suffix) and the importance of `contractType`, as well as the behavior of `detail` (summary vs full). These clarifications are not fully obvious from the schema alone.

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

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

Description clearly states it provides candlesticks for perpetual/current/next quarter contracts from underlying pairs, and distinguishes from regular klines by emphasizing pair+contractType instead of symbol. The verb 'get' and resource 'continuous klines' are specific and differentiate from sibling 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?

Provides explicit guidance on using `pair` without margin-asset suffix and `contractType` instead of the usual symbol, which is critical for this tool. It also warns that dated contracts may not be available for all pairs. While it doesn't explicitly state when to use this over alternatives, the important note makes usage clear.

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

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

Annotations already declare readOnlyHint=true, and the description is consistent with it (status-change reads). The description adds useful behavioral context beyond annotations: the data originates from a !contractInfo stream buffered in a gateway VPS, and there is a 30-day window buffer that constrains data availability. It does not disclose what happens on empty results or how pagination beyond 'limit' works, though no output schema exists to cover this. 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 compact — a couple of parenthetical-laden sentences in Indonesian — and front-loads the core purpose. But it packs in technical noise (the VPS gateway buffering detail) alongside the key facts, making it slightly dense. Adequate but not elegant; every sentence earns its place roughly.

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 tool (2 optional params, no output schema), the description explains the event types and the source stream, and partially disambiguates from exchangeInfo polling. However, with no output schema present, it does not describe the return shape, does not define what 'bracket changes' or 'jadwal settlement' produce, and does not clarify how the 30-day window affects query behavior. Reasonable but with clear gaps.

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 50% — symbol has a description but limit does not, and its semantics (maximum returned events) are implied only by name/default. The tool description itself mentions no parameters and does not compensate for the undocumented limit field. For a parameter-poor tool with partial schema coverage, the description should at least clarify the limit behavior; it adds nothing.

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

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

The description states a specific function: tracking USDS-M contract status changes from the !contractInfo stream, and enumerates the event types (listing, delisting, settlement schedule, bracket changes). It differentiates itself by naming the alternative mechanism (polling onboardDate in exchangeInfo) and the advantage (faster). It does not explicitly name the closest siblings (e.g. binance_get_quarterly_settlement_price, binance_get_trading_schedule), leaving some differentiation to inference, so not a 5.

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

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

The description gives implicit guidance: it is better than polling exchangeInfo for spotting new pairs, and notes 'Event jarang' (events are rare) with a 30-day buffer window, implying this is a sparse-output tool. However, it never explicitly states when to use this tool versus related siblings (settlement price tool, trading schedule tool) or lists when-not-to-use conditions. Guidance is contextual rather than explicit.

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

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

The description adds useful context beyond annotations: if `symbol` is provided, only one pair is returned; otherwise the full exchange info is returned. It also lists the categories of information returned. The readOnlyHint and openWorldHint annotations are consistent with this read-only, externally-dependent 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?

Each of the three sentences earns its place: the first states what the tool returns, the second explains optional symbol behavior, and the third gives a concrete pre-trade use case. There is no filler or redundant restating of the tool name.

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

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

For a simple one-parameter read-only tool with no output schema, the description is sufficiently complete. It names the main return categories and the optional scope behavior, though a tiny bit more detail about what happens when no symbol is sent could make it fully self-contained.

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

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

Schema description coverage is 100%, and the schema already explains the `symbol` parameter. The description only restates the same optional-filter behavior, adding no extra detail like format, edge cases, or validation beyond what structured data already provides.

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

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

The description clearly identifies the resource and scope: full Binance Futures exchange info including pair status, filters, precision, and contract type. It is distinct enough from the large set of price/history/funding siblings, though it does not explicitly name a sibling it differs from.

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

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

It gives a concrete use case: check tick size, min qty, and trading status before opening a grid or order. It does not explicitly state when to use another tool instead, but the context is clear enough for an agent to route to this tool.

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

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

The readOnlyHint and openWorldHint annotations already cover the safe/read-only nature. The description adds that the tool returns structural funding information rather than a current or historical rate, but it does not disclose behavior such as what happens when the optional symbol parameter is omitted.

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 short, front-loaded, and communicates the core content in two concise sentences. The final sentence is useful but partially restates the value of funding interval and cap/floor, making it slightly redundant rather than fully compact.

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 one-parameter, read-only tool, the description adequately lists the main return concepts: funding interval, cap/floor, and interest rate. It does not explain what happens if symbol is omitted or explicitly mention why this tool is preferable over similar funding-related tools, which is a minor completeness gap.

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

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

Schema description coverage is 100%, and the schema already fully documents the symbol parameter with an example and constraints. The description only adds the term 'per symbol' and the expected funding fields, so it provides little additional parameter-level meaning.

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

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

The description clearly states what the tool does: it provides funding structure info per symbol, including funding interval, adjusted funding rate cap/floor, and interest rate. However, it does not explicitly differentiate itself from closely related siblings like binance_get_funding_rate or binance_get_funding_rate_history.

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

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

The description implies usage: it is useful for knowing how often funding settles and the rate limits. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as binance_get_funding_rate for current funding rate data.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral context beyond this: it reveals the funding rate is the native premiumIndex (source of truth), includes basis calculation, and highlights that the index price is a weighted average of multiple exchanges, which could be noisy for small/new pairs. This enriches the agent's understanding without contradicting annotations.

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

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

The description is dense but every sentence adds value: it specifies the data source, the basis, contrarian interpretation, a caveat about noisy index, and default thresholds. It is front-loaded with the core purpose, though the mixed Indonesian-English phrasing and length could be slightly tighter.

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 required parameter) and the absence of an output schema, the description covers key operational details: the native source, basis, interpretation guidance, threshold defaults, and a related configuration tool. It does not describe the exact return structure, but for a single-symbol data fetch this is not a significant 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?

There is only one parameter (symbol), and the input schema already provides full coverage (description, pattern, example, and condition that it must be a Binance USDS-M perpetual pair). The tool description itself does not add any further parameter meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool fetches the current funding rate (native premiumIndex, source of truth) along with basis (mark vs index price). The verb 'Ambil' (get) and the resource are explicit, and the 'TERKINI' (latest) qualifier differentiates it from historical funding rate tools, though it does not name a sibling explicitly.

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

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

The description provides context on when to interpret the data (e.g., contrarian signals for crowded longs/shorts) and warns about noise for small/new pairs, but it does not explicitly state when to use this tool versus alternatives like the funding rate history tool. It mentions a related configuration tool (binance_set_pair_threshold) but no direct alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which the description supports by stating it retrieves historical data. It adds value by explaining the default summary behavior (average, trend, <=10 points) and that period is ignored, which goes 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 concise (two sentences) and front-loaded with the primary purpose. It efficiently explains the default vs full modes without excessive detail, making it 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?

Despite no output schema, the description explains what the user gets in summary vs full mode. It notes the native Binance settlement interval and references docs for full detail. For a relatively simple historical data tool, this is adequate coverage.

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

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

Schema coverage is 100%, with each parameter having a description. The tool description adds little beyond the schema except clarifying the summary vs full output for the detail parameter. The baseline of 3 applies since the schema already provides comprehensive parameter info.

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 settled funding rate history from Binance native to analyze leverage crowding trends. It uses a specific verb (get/histori) and resource (funding rate history), and distinguishes from siblings like binance_get_funding_rate (current rate) and binance_scan_funding_extremes (scanning extremes).

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 explains when to use the default summary mode vs full detail mode, and notes that the period parameter is ignored for this tool. While it doesn't explicitly name alternative tools, the context makes its purpose clear and distinct from 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 declare readOnlyHint=true and openWorldHint=true, which the description does not contradict (no contradiction). The description adds valuable behavioral context: it indicates that this tool is useful for anomaly detection by comparing price differences across exchanges, a nuance not captured in annotations. It doesn't detail rate limits or data freshness, but given the annotations, 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 a single concise paragraph with three focused sentences: what it returns, applicability, and an example of use case (anomaly detection). No filler, and the most important information is front-loaded.

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

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

For a simple tool with one parameter and a clear return concept, the description fully covers the operational context. It explains why the tool exists and provides an example use case, which is sufficient for agent decision-making. No output schema exists, but the tool's output is implied by the description ('exchange + price + weight'), so no further detail is necessary.

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% (the schema fully describes the 'symbol' parameter with expected format and example). The description does not add further parameter-level meaning beyond what schema provides, such as additional constraints or usage notes for the symbol. Baseline 3 is appropriate because schema covers everything.

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 this tool lists spot exchanges, prices, and weights that compose the index price for a trading pair, and explicitly notes it applies to regular perpetual pairs, not just composite indices—distinguishing it from the similar binance_get_composite_index_info. The verb 'list' with concrete output elements (exchange, price, weight) makes the purpose specific.

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

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

The description provides clear usage context: it is used when needing the index constituents for a regular perpetual pair, but does not explicitly mention alternatives or when not to use it. Since it contrasts with composite index info, an implicit hint is there, but no explicit 'when-not' or alternative tool names are given.

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, which the description aligns with (read operation). It adds context about the data source (blended spot exchanges) and the critical distinction from transaction prices. It does not disclose rate limits or pagination behavior, but the readOnlyHint covers safety. The description adds value beyond annotations by explaining the underlying data 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 concise, two sentences, with a critical warning upfront and an example. It is front-loaded with the most important usage distinction (pair vs symbol). Slightly under-structures the parameter hints, 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?

Given the tool has a complex parameter (`pair` with special semantics) and no output schema, the description covers the essentials: what data is returned, how to specify the pair, and the detail parameter for output size. It lacks explicit mention of time range behavior (startTime/endTime) but those are optional and self-explanatory from the schema. Overall complete for the tool's complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds critical semantics for the `pair` parameter (explaining the difference from `symbol` and providing an example). It also clarifies the `detail` parameter (summary vs full, saving tokens) which goes beyond the schema. This justifies a score above baseline.

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

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

The description clearly states it returns candlesticks of the INDEX PRICE (blended spot exchanges, basis for premium index/funding), explicitly NOT futures transaction prices. It distinguishes itself from sibling tools like binance_get_klines and binance_get_mark_price_klines by noting the 'pair' vs 'symbol' distinction and the index price nature.

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 important usage guidance: use `pair` without margin-asset suffix (e.g., BTCUSD vs BTCUSDT), and distinguishes this from regular symbol trading. However, it does not explicitly state when NOT to use this tool versus alternatives like binance_get_mark_price_klines or binance_get_premium_index_klines, though the differentiation is implied.

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

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

Annotations already declare readOnlyHint and openWorldHint as true, so the description's burden is reduced. The description adds value by clarifying this is a periodic historical snapshot (not live), and explains the significance of a thick insurance fund buffer. 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 front-loaded with the core action, followed by context and usage caveats. It is efficient but includes explanatory detail about insurance fund buffer, which adds value without being verbose. Could be slightly tighter by removing the parenthetical about ADL, but overall concise.

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

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

Given the tool has only one optional parameter, good annotations, and no output schema, the description sufficiently explains the tool's purpose, data nature, and usage context. It covers what the tool returns and how to interpret it, making it complete for this level of complexity.

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 parameter is well-documented in the schema (optional filter for symbol). The description does not need to add much beyond what the schema provides, so a baseline of 3 is appropriate. It adds minimal extra meaning.

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

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

The description clearly states that the tool takes a snapshot of the Binance Futures insurance fund balance per margin asset, directly from Binance's native public endpoint. It distinguishes itself by noting it is a periodic historical snapshot, not live/real-time, which helps differentiate from other real-time tools in the sibling list.

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

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

The description explicitly notes that this is not a live/real-time balance, advising use for medium-to-long-term system health context rather than short-term signals. It does not, however, explicitly name alternative tools for real-time data or when not to use this tool.

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

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

The description adds valuable behavioral context beyond the annotations: it explains that default mode returns only the last 5 candles and derived metrics (token-saving), and that setting detail='full' or includeCandles=true returns the full candle array. It also notes the deprecated includeCandles parameter and the use of startTime for backtesting. The readOnlyHint annotation aligns with the read-only nature described, with no contradiction.

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

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

The description is compact and efficient: a couple of sentences that front-load the core purpose, then immediately cover default behavior and how to opt into full data. It avoids filler and every sentence adds meaningful information about tool operation.

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 provides a reasonable overview of what is returned (summary metrics, last 5 candles, or full array). It also covers limit and startTime for historical data. It could be more explicit about the exact structure of the summary output, but it is sufficiently complete for a read-only data-fetching tool with good annotation coverage.

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% (all 7 parameters have descriptions), so baseline is 3. The description adds extra value by clarifying the default behavior of the 'detail' parameter (summary vs full) and the deprecation of 'includeCandles', as well as emphasizing the backtest use case for 'startTime'. This goes beyond mere schema repetition.

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 returns native Binance OHLCV candlestick data ('Candlestick OHLCV native Binance'), and specifies it provides direction bias, swing highs/lows, and last price. It also distinguishes itself from Coinalyze as the source of truth, which helps differentiate from other data sources. This is a specific verb+resource with clear scope.

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

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

The description mentions 'native Binance (source of truth, bukan Coinalyze)' which implies this is the preferred tool for Binance Futures data, and it discusses the default summary mode versus full mode for token efficiency. However, it does not explicitly contrast with sibling tools like binance_get_spot_klines or binance_get_continuous_klines, though the mention of 'Binance Futures' in the symbol parameter provides context. This is clear on when to use it but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to repeat that. It adds value by disclosing the data source (native globalLongShortAccountRatio), the interpretation of ratio > 1, and the default behavior (summary with <=10 points). It doesn't mention rate limits or pagination, but given the annotations cover safety, this is sufficient.

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, front-loaded with the core purpose, and uses clear formatting (bold for key terms, parentheses for limitations). Every sentence adds value: purpose, interpretation, limitation, and default behavior. No fluff.

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

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

Given the tool's moderate complexity (4 params, 2 enums, no output schema), the description covers the essential aspects: what it does, how to interpret results, when to use alternatives, and default behavior. It doesn't describe return format in detail, but since there's no output schema, a brief mention of 'snapshot + tren + <=10 poin' is adequate. The reference to docs/tool_response_reference.md for full details is a good practice.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the 'detail' parameter's purpose ('HEMAT TOKEN') and the 'limit' default behavior, which goes beyond the schema. It also clarifies the 'symbol' pattern with an example. This is above the baseline 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 fetches the aggregate long/short ratio from Binance's native globalLongShortAccountRatio, with a specific verb ('get'), resource ('long/short ratio'), and scope ('all accounts/global'). It also distinguishes itself from the sibling tool binance_get_top_trader_ratio by explicitly noting it's a blended ratio, not a top-trader breakdown.

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 mentions when to use this tool versus the alternative: 'KETERBATASAN: rasio BLENDED, bukan breakdown top-trader (pakai binance_get_top_trader_ratio untuk itu)'. It also provides usage context for the 'detail' parameter, indicating when to use 'summary' vs 'full' to save tokens.

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 an important behavioral trait: volume/trade count is always 0 due to synthetic price. This is additional beyond what readOnlyHint and openWorldHint convey, but it doesn't cover other aspects like rate limits or pagination. Given the annotations exist and the description adds the synthetic-price warning, this is solid.

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: two sentences, front-loaded with key information (what it is, key caveat, recommendation, and detail parameter). Every sentence adds value; no fluff.

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

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

With 6 parameters, 100% schema coverage, and no output schema, the description provides the essential context: it explains the purpose, the main caveat (zero volume), and the alternative. It could mention the response format but it defers to docs. Given the complexity and that the schema is rich, this is nearly complete.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds semantics for 'detail' (summary vs full) and mentions the default, but doesn't significantly augment the parameter meaning beyond the schema. It does clarify that volume is zero, which relates to the data returned rather than parameters. Thus, a 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 identifies it as 'Candlestick dari MARK PRICE' (mark price candlesticks), explicitly notes it is not transaction price, and references the alternative sibling tool binance_get_klines. This distinguishes it from many similar klines tools in the sibling list.

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

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

It explicitly advises using binance_get_klines for normal market TA, and it mentions the use case for liquidation/funding reference. It also provides guidance on using the 'summary' default to save tokens versus 'full' detail, which guides parameter selection and 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 safety profile is covered. The description adds useful behavioral context by noting the data comes directly from Binance native and covers five timeframes, but it does not disclose how bias is calculated or what the exact response structure looks like.

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

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

The description is two sentences, front-loaded with the core outcome, and every sentence adds value. The use case and alternative are stated efficiently without unnecessary filler.

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

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

For a single-parameter, read-only tool, the description is mostly complete: it names the output values (Bullish/Bearish/Sideways), the timeframes, the data source, and a typical query. It lacks an explicit output schema or return-format description, but the absence is partially mitigated by the clear statement of what the tool provides.

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

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

Schema description coverage is 100% and the single 'symbol' parameter is well-documented in the schema with format, example, and listing requirements. The description itself adds no additional parameter semantics beyond the schema, so the baseline 3 applies.

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

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

The description clearly states the tool provides directional bias (Bullish/Bearish/Sideways) across 5 specific timeframes (1m, 5m, 15m, 1h, 1d) in one call. It also distinguishes itself from binance_get_klines by explicitly saying it replaces multiple manual kline calls.

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

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

The description gives an explicit use case ('Cocok untuk 'apa bias BTCUSDT di semua timeframe'') and names the alternative it replaces (binance_get_klines). It does not explicitly state when not to use the tool, 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 (readOnlyHint=true) already establish that the tool is a safe read operation. The description adds interpretative value about OI movements but does not disclose additional behavioral specifics such as response format, rate limits, or error handling. Since annotations cover the safety profile, a score of 3 is appropriate—it adds some context but not deep behavioral details.

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, with the first sentence stating the tool's core function. The subsequent interpretative sentences are valuable and without fluff. Every sentence earns its place, achieving high conciseness and structure.

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 tool with one parameter, read-only annotation, and no output schema, the description is quite complete. It explains what OI is, how to interpret it, and implicitly what the return value represents. It could explicitly mention the response type or error cases, but overall it provides sufficient context for an agent to use the tool effectively.

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 (100% coverage) with pattern and example. The description adds no further parameter semantics beyond what the schema provides, so it meets the baseline of 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 that the tool returns current open interest ('Open Interest TERKINI, LANGSUNG dari Binance native'). It distinguishes itself from the historical variant implicitly by emphasizing 'current', but does not explicitly name the alternative tool. The interpretative guidance further clarifies the tool's purpose in analyzing market sentiment.

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 concrete usage context by explaining how to interpret OI changes relative to price (e.g., 'OI naik + harga naik = tren didukung entry baru'). This implies when to use the tool for trend confirmation. However, it does not explicitly state when not to use it or compare it with alternatives like the history tool, so it lacks exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds meaningful behavior: the default response is a concise summary (trend + <=10 latest points), while detail='full' returns complete history respecting limit. This clarifies output shape and token-saving behavior beyond the annotations. No contradictions.

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 purpose, then usage and parameter behavior. Every sentence contributes; 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?

Despite lacking an output schema, the description explains the two output modes and their token implications, and provides an interpretation framework. It does not enumerate exact response fields, but the schema references docs/tool_response_reference.md for full detail. For a 4-parameter read-only tool, this is adequately complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the interaction between detail and limit, and clarifying that summary mode returns derived metrics plus a limited number of recent points. This goes beyond the schema's enum 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 as retrieving Open Interest history to observe up/down trends, explicitly distinguishing it from the current-snapshot sibling binance_get_open_interest by emphasizing 'histori' and 'TREN'. The phrase 'LANGSUNG dari Binance native' adds source specificity. The verb is implicit but the resource and analytical purpose are 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 explicitly instructs combining this tool with binance_get_klines at the same period and provides an interpretive rule (OI up + price up = new entry; OI down + price up = short covering). It also advises using the default summary to save tokens, implying full detail only when needed. It does not state exclusions or alternative tools, so it falls short of a 5.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, so safety profile is already covered. The description goes beyond by detailing the two-fetch latency penalty, the exact wall definition (consistent with the wall_tracking cron), and the spoofing detection logic (wall disappears/shrinks >70% without price crossing). It also explains the summary/full output modes. This is valuable behavioral context not present in annotations or schema.

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

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

The description is compact yet information-dense, front-loading the core action and then adding essential caveats. It avoids redundancy with the schema. The warning about latency is placed at the end, which is appropriate since it's a secondary concern. It could be slightly more structured (e.g., breaking into paragraphs), but it is effective.

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

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

For a tool with no output schema, the description gives a useful preview of return types (summary: derived metrics + ≤10 points; full: raw arrays) and references a documentation file for deeper details. It also clarifies the symbol requirement (perpetual futures) and the internal dependency. Missing details on exact metrics names or error handling are minor given the reference to docs. Overall, it is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so all four parameters (symbol, limit, detail, delayMs) are already documented with types, defaults, and ranges. The description adds no substantive parameter semantics beyond what the schema provides—it only references the summary/full distinction already in the 'detail' enum. With high coverage, 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 core function: it takes two orderbook snapshots ~1-2 seconds apart, compares walls (qty >= 2x median), and flags vanishing walls as a real spoofing indicator. It explicitly distinguishes itself from binance_get_order_book_depth (single snapshot) and names the tool it serves internally (binance_detect_mm_activity). The verb 'ambil... bandingkan' and the resource 'orderbook delta' are specific.

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 usage context: mentions it is used internally by another tool, notes the difference from the single-snapshot depth tool, and warns about added latency (~1-2s). However, it does not explicitly state when to use this over other orderbook analysis siblings like binance_get_orderbook_wall_persistence or binance_get_order_book_imbalance, leaving some ambiguity for an agent picking the best 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?

With readOnlyHint and openWorldHint annotations already present, the description adds meaningful extra behavioral context: the snapshot is instantaneous, large walls can vanish or be spoofed, and this tool alone is insufficient for market-maker detection. No contradiction exists between description and 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-loads the core purpose, then adds a crucial caveat and a concise summary/full explanation. It is slightly dense with mixed-language punctuation but every sentence earns its place.

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

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

There is no output schema, so the description carries the duty of giving an agent sense of the return. It explains the summary vs full return philosophy, warns about wall volatility, and references supporting docs. It doesn't fully explain all aggregated metrics, but the docs pointers help.

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

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

Schema description coverage is 100%, and the schema already documents defaults and enums. The description enriches semantics by explaining that summary mode returns roughly the top 10 levels plus the largest wall, while 'detail: full' returns all levels up to limit. This adds practical parameter understanding 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 uses a specific verb+resource: 'Snapshot order book (bid/ask) real-time' and immediately states the analysis purposes (wall besar, spread, likuiditas). It clearly differentiates itself from sibling order-book tools by emphasizing the snapshot nature, not persistence or imbalance.

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 caveats: snapshot is momentary, walls can disappear in seconds (potential spoofing), and at least 3 aligned signals are required before concluding market-making activity, with a docs pointer. It doesn't explicitly name alternatives like binance_get_orderbook_wall_persistence, but the snapshot caveat implies the distinction.

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

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

With annotation readOnlyHint=true and openWorldHint=true, the safety/read-only profile is already known. The description adds useful behavioral context—this is a momentary snapshot and should not be overinterpreted—but does not disclose deeper traits such as the exact calculation method or whether the bias thresholds are configurable. Acceptable but not rich.

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

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

Three short, information-dense sentences. Each sentence adds value: core output, sibling comparison, and a critical caveat. There is no fluff or repetition.

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

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

For a one-parameter read-only metric tool without an output schema, the description is complete enough for an AI agent to choose and call the tool correctly. It explains what the tool returns (percentages, depths, bias labels), distinguishes it from the raw order book snapshot sibling, and provides a caveat about 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 only parameter, 'symbol', is fully described in the input schema with pattern, length, and example. Schema description coverage is 100%, so the description does not need compensating parameter details. 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 defines the tool's output: cumulative Bid vs Ask imbalance percentages at three depths (5, 10, 20) plus bias labels, and explicitly distinguishes it from binance_get_order_book_depth. This makes the tool's purpose and differentiation from sibling tools 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?

The description gives clear usage context: it contrasts this tool with the raw-snapshot sibling and warns that the value is a momentary snapshot that should not be overinterpreted. It stops short of explicitly saying 'use this when you want a bias label' or naming additional alternatives, so it is clear but not overly prescriptive.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description adds meaningful behavior: wall_tracking is populated by a 1-minute cron, so persistence granularity is limited, and only watchlist symbols have history. The mention of >40% shrinkage as a spoofing signal is also useful context. It does not, however, resolve what happens for the many enum symbols outside the 10-symbol list.

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

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

Three compact sentences, each useful: the function, the data-source/availability warning, and the signal use cases. There is no fluff, though the symbol-scope inconsistency makes it less crisp than it could be.

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 clarify return behavior, but it does not. More importantly, the symbol scope is contradictory: the description claims only 10 symbols have stored history, while the schema enum exposes 50 symbols as valid. An agent cannot confidently decide whether calling with, say, TRXUSDT is valid, will return empty data, or will error.

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 adds light context such as 'N menit lalu' for lookback and 'wall kandidat' for priceLevel, but it does not materially expand beyond the schema's own parameter descriptions.

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

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

The description clearly states the function: checking whether a wall candidate at a price still persists compared to N minutes ago, using historical data from wall_tracking. This is distinguishable from sibling order-book tools like depth/delta/imbalance. However, the 'PENTING' line lists only 10 watchlist symbols while the schema enum contains 50, muddying the exact scope.

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

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

The description gives explicit use cases: verifying absorption signals and detecting spoofing via sudden wall shrinkage. It also gives a hard exclusion: symbols without stored history are not available. It does not name alternative tools for non-watchlist symbols, so it falls short of a 5.

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

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

Annotations already 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 include readOnlyHint=true, and the description aligns with that (no contradiction). The description adds interpretive behavioral context (premium ratio, not absolute price) beyond annotations, but it doesn't detail response structure or pagination. The 'detail' parameter's token-saving behavior is mentioned in the schema, not the description. Adequate but not rich.

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?

Description is two sentences: first states the tool's purpose and core semantics, second provides a cautionary interpretation note. Every sentence earns its place, no fluff, front-loaded with the critical distinction.

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

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

For a read-only data retrieval tool with 100% schema coverage and no output schema, the description covers the essential purpose and interpretation trap. It could be improved by noting that 'full' detail returns raw arrays, but that's in the schema. Overall adequate for the complexity.

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 adds semantic value by explaining the meaning of the data (premium ratio) which aids understanding of symbol/interval usage, but it doesn't add syntax details for parameters beyond the schema. The description's focus on interpreting results adds value beyond 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 it returns candlestick data for the PREMIUM INDEX (difference between mark and index price), a key funding rate component. It explicitly distinguishes the value as a premium ratio, not absolute price, differentiating it from siblings like binance_get_klines or binance_get_mark_price_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 implies usage for funding rate analysis (premium positive = funding tends positive) and notes the interpretation caveat, which helps agents decide when to use it. However, it doesn't explicitly name alternative tools or state when not to use it, but the 'jangan dibaca seperti candle harga biasa' gives clear 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 cover readOnlyHint and openWorldHint, so safety is clear. The description adds useful behavioral context: the symbol is optional and omitting it returns many pairs. It also notes the endpoint and lightweight nature, though it does not describe the response fields or size.

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 very short and front-loaded: it states the resource, the lightweight intent, and the optional parameter behavior in three tight clauses. Every sentence earns its place with no fluff.

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

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

For a simple one-parameter read-only price endpoint, the description covers the endpoint, the optional symbol behavior, and the lightweight nature. An output schema is absent, so describing the exact response fields would have been a small improvement, but the tool name and context are sufficient for correct 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 has full description coverage for the symbol parameter, but the tool description adds meaning by explicitly stating the symbol is optional and that an empty value returns multiple pairs. This is useful semantic guidance beyond the raw schema.

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

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

The description clearly states this tool returns only the latest price ('Harga terakhir saja') for Binance futures, with the exact endpoint GET /fapi/v2/ticker/price. It is clear enough to avoid confusion with richer tickers like the 24hr ticker, though it does not explicitly compare itself to a sibling tool.

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

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

The description implies the tool is for lightweight latest-price lookups, especially by saying 'Ringan' and noting that an empty symbol returns many pairs. However, it does not explicitly say when to prefer this over alternatives such as binance_get_24hr_ticker or binance_get_spot_price.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the safety profile is clear. The description adds meaningful behavioral context beyond annotations: it explains the data is historical delivery/settlement price at expiry, that it is quarterly-only, and that perpetual pairs are out of scope. It does not describe response structure, but the schema's detail parameter partially covers that.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then adds the critical scope restriction and pair-format instruction. 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?

For a two-parameter read-only tool with detailed schema descriptions and annotations, the description adequately covers what, when, and how. It explains the quarterly-specific nature and pair selection. It does not describe exact response fields or date-range behavior, but given the schema's detail enum and the tool's simplicity, the overall context 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?

Schema description coverage is 100%, so the schema already explains both parameters thoroughly. The description reinforces the pair format rule ('TANPA suffix margin-asset') and clarifies quarterly relevance, but does not add substantive new meaning beyond what the schema already provides. A 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 historical delivery/settlement prices for quarterly contracts, specifically the final price at contract expiry. It explicitly distinguishes the tool from perpetual-related tools by stating it does NOT apply to PERPETUAL contracts, and clarifies the correct pair format.

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 this tool: only for quarterly/dated listing pairs, and explicitly warns against using it for PERPETUAL contracts. It also instructs to use the pair without the margin-asset suffix. However, it does not name alternative sibling tools for when one should not use this tool, so it falls just short of the highest guidance level.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: it uses two timeframes, derives values from native klines, and returns both annualized and per-period percentages. It does not detail lookback windows or rate limits, but the safety profile is already covered by annotations.

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

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

The description is concise and front-loaded: three short sentences convey the metric, timeframe, data source, output format, rationale, and usage context without repetition or filler.

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

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

For a one-parameter, read-only tool with strong annotations, the description is complete: it explains calculation, timeframes, source, returned values, and intended use. No output schema exists, but the output composition is sufficiently 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?

The schema fully documents the single `symbol` parameter with pattern, length, and an example. The description adds no additional parameter-level detail, so the baseline of 3 applies given high schema coverage.

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

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

The description clearly identifies the tool as computing realized volatility from close-to-close log returns across two timeframes, sourced directly from Binance native klines. This distinguishes it from sibling kline/ticker/metric tools by naming a specific derived metric and its calculation basis.

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: cross-checking grid width calibration for the i_atrMult Grid Advisor. It does not mention when not to use the tool or name alternative tools, but the context is clear enough for a simple read-only metric lookup.

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?

Adds substantial behavioral detail beyond readOnlyHint/openWorldHint: feed is sampled by Binance (max 1/symbol/second), data is buffered on a gateway VPS, and in case of stream/gateway issues the tool still returns whatever data is available with a 'degraded' flag rather than silently returning empty. This is exactly the kind of contextual behavioral context that helps an agent trust and interpret results.

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

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

Four concise sentences: the first states the main function, followed by filtering capabilities, sampling caveat, distinction from REST tools, and degraded-mode behavior. No unnecessary text; all information is operationally relevant.

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?

Covers the essential invocation context: data source (WebSocket stream), freshness, filtering, sampling, and degraded behavior. The main gap is the absence of a description of the return shape/fields, but the 'detail' parameter in the schema references docs/tool_response_reference.md, and the parameter enum describes summary vs full output, mitigating this gap.

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

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

Schema describes 'detail' and 'symbol', and the description adds that filtering is per symbol and minimal notional, clarifying the purpose of those parameters. 'limit' and 'minNotionalUsd' are not explicitly described in the description, but their meaning is reasonably inferable from names/defaults. Description partially compensates for the 50% 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?

Description states a specific verb+resource: 'Likuidasi paksa (forced liquidation) terbaru market-wide dari WebSocket stream Binance'. It explicitly distinguishes this from REST tools by emphasizing it returns newly occurred events, not periodic snapshots. This differentiates it from siblings like binance_get_all_force_orders.

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

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

Gives clear usage context: this tool is for events that just happened (seconds-to-minutes ago), distinguishing it from periodic snapshot tools. It says 'Beda dari tool REST lain' and describes streaming-sourced real-time behavior, but does not explicitly name a specific alternative or give a when-not-to-use condition.

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, so the description doesn't need to restate safety. It adds valuable behavioral context beyond annotations: the default summary mode returns 'CVD + 15 trade terakhir' (Cumulative Volume Delta and 15 recent trades), and it highlights token efficiency. This supplements the schema and annotations meaningfully, though it could further clarify the exact structure of the summary vs full response.

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 three sentences with the key distinction (vs aggregated) front-loaded. It is efficient and avoids fluff. However, the structure could be improved by separating the default behavior into a clearer sentence or bullet, and the mixed-language phrasing ('Terbaru' repeated) slightly reduces clarity. Still, it earns a 4 for being succinct.

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

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

There is no output schema, so the description must explain the return format. It mentions the default summary returns 'CVD + 15 trade terakhir' and points to docs/tool_response_reference.md, but it does not specify the full structure of either 'summary' or 'full' modes, nor how the 'limit' parameter interacts with summary mode (does it cap at 15 regardless of limit?). An agent may struggle to parse the response without consulting the docs. This is a moderate gap, so a 3 is appropriate.

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 description coverage, the baseline is 3. The description adds extra meaning: it explains the trade-off between 'summary' and 'full' modes (token savings vs raw data) and mentions that summary includes CVD, which is not in the schema. It also discloses the default summary behavior, giving an agent context beyond the parameter enums. This added insight justifies a 4.

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 verb ('Trade individual terbaru'), the resource (individual trades from GET /fapi/v1/trades), and explicitly differentiates from the sibling tool binance_get_agg_trades which returns aggregated data. The phrase 'Lebih granular untuk analisis micro-structure' further clarifies its distinct purpose, leaving no ambiguity about what this tool does or how it differs from similar tools.

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

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

The description explicitly contrasts this tool with binance_get_agg_trades, implying it should be used when granular, non-aggregated trade data is needed for micro-structure analysis. It also indicates a default to summary mode to save tokens, suggesting when to stick with the default. It does not explicitly state 'do not use when X' but the comparison provides clear selection guidance. A more explicit 'use this instead of aggregated when you need individual trades' would push this to 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the base safety profile is known. The description adds useful behavioral context: the order book includes RPI orders, the sibling excludes them, and the default output is a summary (top 10 + wall). 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 compact and front-loaded, with the key RPI distinction in the first sentence. Every phrase earns its place: the endpoint, the sibling contrast, and the default output mode. No filler or redundancy.

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

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

There is no output schema, but the description plus the detail parameter explain the default summary behavior, the full raw mode, and point to the docs reference. Combined with 100% schema coverage and safe read-only annotations, this is sufficiently complete for an agent to invoke the tool correctly, though the exact summary fields are not fully described.

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

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

Schema description coverage is 100%, so the schema already documents symbol, limit, and detail thoroughly. The description's mention of 'default summary (top 10 + wall)' aligns with the detail parameter but adds no new parameter-level meaning 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 the tool returns an order book that INCLUDES RPI orders and explicitly contrasts it with binance_get_order_book_depth, which excludes RPI. This gives a specific verb, resource, and enough distinction to separate it from the main sibling tool.

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

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

It names the key alternative (binance_get_order_book_depth) and states the exact difference between them, which effectively tells the agent when to prefer this tool. However, it stops short of an explicit 'use this when / use that when' rule or any exclusion scenarios.

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 beyond readOnlyHint/openWorldHint by explaining CVD meaning, aggressor side, compact mode vs full raw trade array, and the token-saving purpose of 'summary'. The inconsistency between '15 trade' in the description and '<=10' in the schema, plus the pointed 'Binance USDS-M Futures' text on a spot tool, keeps this from a 5.

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

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

Very compact, front-loaded, every sentence adds value. Slightly penalized because the 15/10 mismatch could have been avoided; overall structure is good.

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

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

There is no output schema, so the description must explain the return shape. It gives summary vs full behavior, but does not define the exact summary fields or aggregate trade array structure, and the referenced docs only appear in the schema. For a moderately complex tool, that leaves gaps.

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 has 100% parameter description coverage for all 3 parameters, so the schema already carries most of the burden. The description adds spot-vs-fries framing but does not resolve the contradiction where schema says 'Binance Futures' for a spot tool, so parameter selection is less certain than it could be.

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 what the tool does: fetch recent SPOT trades with buy/sell aggressor, and explicitly identifies itself as the Spot version of binance_get_agg_trades. This distinguishes it from the many futures-oriented sibling tools.

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

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

The description tells the agent to compare spot CVD with futures CVD and names the futures equivalent. While it does not give explicit exclusions, the spot-vs-futures guidance makes the intended context 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?

With readOnlyHint and openWorldHint already present, the description adds useful behavioral context: the price is an aggregate over a short trailing window, usually around 5 minutes, rather than a single instantaneous trade. It does not describe output structure or edge cases, but the annotations cover the read-only safety profile.

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

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

The description is one concise sentence with the core definition front-loaded and a valuable clarifying contrast with the sibling tool. There is no wasted text or redundant repetition of the title.

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

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

For a single-symbol, read-only price tool, the description is mostly sufficient: it explains how the price is derived, why it is stable, and which sibling tool differs. However, it lacks output-format details, and the incorrect futures-symbol guidance in the schema makes the overall tool context incomplete and potentially misleading.

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 symbol parameter is fully documented in the schema, but the schema description is copy-pasted from a futures tool: it says the symbol must be a perpetual pair registered in Binance USDS-M Futures, which conflicts with this SPOT tool. The tool description does not correct this and adds no real symbol-level guidance; the parenthetical 'mins' is also not an actual input parameter.

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

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

The description clearly identifies the tool as a current SPOT moving-average price, computed by Binance from trades over the last few minutes. It also explicitly distinguishes itself from binance_get_spot_price, which is the instantaneous last-trade price, 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?

The description gives a clear usage signal: prefer this when a more stable recent SPOT price is needed than the last trade. It names binance_get_spot_price as the alternative, but it does not state explicit exclusions or when other price-related tools would be more appropriate.

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, lowering the bar. The description adds behavioral context by stating it's real-time and lighter than order book, and implies it only returns the top bid/ask, not a full depth. However, it doesn't detail output structure or rate limits, but given annotations and simplicity, this is sufficient.

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, front-loaded with the core purpose and followed by usage guidance. Every word earns its place, with no filler or redundancy. It efficiently conveys purpose and alternatives without unnecessary detail.

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

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

Given the tool's low complexity (one parameter, no output schema, annotations present), the description covers purpose, usage, and the returned data (price + quantity). However, the mismatch between the tool's 'SPOT' context and the schema's 'Futures' symbol description creates a critical gap that undermines completeness, leaving the agent uncertain about valid symbol formats.

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 has 100% coverage for the single 'symbol' parameter, but its description is contradictory: it says 'Simbol pair Binance Futures' and 'Harus pair perpetual yang terdaftar di Binance USDS-M Futures' (must be a perpetual pair on USDS-M Futures), while the tool name and description clearly indicate SPOT. The tool description does not correct this, so the parameter meaning is misleading, leaving an agent unsure whether to pass spot or futures symbols.

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

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

The description clearly states the tool returns the best bid/ask price and quantity for SPOT in real-time. It uses a specific verb ('get') and resource ('best bid/ask'), and distinguishes itself from the heavier binance_get_spot_order_book by emphasizing it is lighter, 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 explicitly tells when to use this tool: 'lebih ringan dari binance_get_spot_order_book kalau cuma butuh spread sesaat' (lighter than the spot order book if you just need a momentary spread). It also names an alternative for cross-checking spot vs futures (binance_get_order_book_depth), providing clear guidance relative to 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 declare readOnlyHint and openWorldHint, and the description does not contradict them. It adds behavioral context beyond annotations: the 1000-candle per call limit, default concise output, and options to request full candle arrays via detail or includeCandles. This helps the agent know exactly what to expect in terms of data volume and response format.

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

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

The description is two sentences long, with the core purpose and key differentiators front-loaded. Every phrase earns its place: it names the data type, the spot market, the comparison with futures, the limit, and the detail options. No fluff or redundancy.

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

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

Given the tool's moderate complexity and the absence of an output schema, the description partially covers return format by mentioning OHLCV and 'array candle penuh' for full detail. It also references documentation for the detail parameter, but the description itself could more explicitly describe the default summary structure. It covers essential constraints (max 1000) and options, so it's adequate but not exhaustive.

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 adds value by explaining the trade-off between summary and full detail, and by highlighting the deprecated includeCandles in favor of detail. However, it doesn't dive deeper into parameter syntax beyond what the schema already provides, so it earns a 4 rather than 5.

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

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

Description clearly states this tool fetches spot OHLCV candlestick data per timeframe, explicitly identifying it as the Spot version of binance_get_klines. It distinguishes itself from futures and other kline tools by noting the 1000 candle limit and the purpose of comparing spot vs futures for leverage 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 explicitly states when to use this tool: to access spot market data, and to compare with the futures version (binance_get_klines) to detect leverage-driven moves. It also differentiates the max limits (1000 vs 1500), giving concrete guidance on when this is the appropriate choice.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds that the snapshot is transient ('PENTING: snapshot SESAAT, order book berubah cepat') and explains the summary vs full behavior. This adds valuable behavioral context beyond annotations without 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 informative yet compact, with a clear intro, a differentiation note, and a prominent warning. It's not overly verbose and each sentence contributes value. The only minor issue is a slight redundancy with the schema for 'detail', but it's acceptable.

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

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

There is no output schema, but the description explains what summary vs full returns (top 10 + spread vs raw arrays) and references docs. For a real-time order book tool, this is adequate context; it could add more detail on exact data structure but is sufficient for agent 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?

Schema coverage is 100% with descriptions for all params. The description adds meaning by explaining the effect of 'detail' (summary saves tokens, full gives all levels up to limit) and ties limit to the full option. It clarifies the intended use of each parameter beyond the schema definitions.

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 it's a real-time SPOT order book snapshot, and explicitly distinguishes from the futures version (binance_get_order_book_depth) for comparing spot vs futures walls/liquidity. The verb 'Snapshot' and resource 'order book' are specific, and it differentiates 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?

Provides guidance on when to use (spot vs futures comparison) and how to use (summary vs full detail). It doesn't explicitly name alternatives beyond the futures version, but the context is clear enough for an agent to decide between spot and futures order books. It could be more explicit about when to avoid this tool, but overall conveys 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 indicate readOnlyHint=true and openWorldHint=true, so the description need not repeat safety traits. The description adds value by specifying that it uses Futures mark price (not index price) for basis calculation, and that it 'error jelas' (errors clearly) for futures-only pairs. This clarifies the tool's computational behavior beyond the schema and 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 compact sentences deliver the core, the key comparison, and an important caveat. The structure front-loads the primary purpose and highlights the 'PENTING' warning 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 simple one-param read-only tool with full schema coverage, the description is quite complete. It covers the output concept (spot price + real basis vs mark price), differentiates from an index-price alternative, and alerts about a failure mode with a countermeasure. It misses nothing major, though output shape details are left unmentioned.

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%; the symbol parameter is fully documented in the input schema with format, example, and constraints. The description adds no extra parameter detail, so baseline 3 is appropriate.

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

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

The description opens with the specific resource and operation: 'Harga SPOT Binance + basis riil vs mark price Futures', which clearly identifies this as a spot price and basis computation tool. It explicitly distinguishes itself from binance_get_funding_rate by stating 'bukan harga index price rata-rata' (not average index price), helping differentiate it from a sibling tool that could easily be confused.

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 when-to-use context: 'bedain leverage-driven vs demand riil' (differentiate leverage-driven vs real demand). It also gives a clear exclusion: many futures pairs are futures-only without spot listing, and advises checking binance_check_spot_listing first if unsure. This is practical usage guidance, though it doesn't offer formal when-not-to-use scenarios beyond the futures-only case.

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

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

Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds the return fields and window constraints, providing some behavioral context. However, it doesn't disclose potential caveats like symbol validity for spot, and there is a mismatch between the tool's spot nature and the schema's 'Futures' mention, though that's not a 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, information-dense sentence. It leads with the core purpose, lists outputs, names the sibling it differs from, and states the use case. No wasted words, though it could be split for readability without losing value.

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

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

For a read-only ticker endpoint with only two parameters and no output schema, the description covers the essential aspects: the custom window, default value, and the key alternative. It doesn't mention return format or pagination, but for this simple tool it's reasonably complete. The only gap is the symbol description mismatch, but that's not in the tool description itself.

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 describes symbol (though incorrectly as Futures) and leaves windowSize without a description. The tool description clarifies windowSize allowed values and default, which helps. However, it doesn't correct the symbol description's mention of Futures, potentially confusing an agent. With 50% schema coverage, the description only partially compensates for the missing 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 the tool provides SPOT statistics for a configurable rolling window, lists the returned fields (open/close, high/low, %change, VWAP, volume), and explicitly differentiates it from binance_get_spot_ticker_24hr. The purpose is unambiguous, though the verb is implicit and the schema symbol description mentions Futures, creating minor inconsistency.

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_get_spot_ticker_24hr (fixed 24h) and explains when to use this tool: to read spot momentum at a chosen timeframe without manual derivation from klines. This gives clear context, though it doesn't address every alternative among the many siblings, the key differentiator is covered.

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 read-only nature is covered. The description adds value by specifying that the tool returns a summary of spot data and compares it to futures, which helps the agent understand the data scope and the insight (volume disparity). It does not contradict annotations; it complements them. No destructive behavior disclosed because none exists; the safety profile is fully handled by annotations.

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

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

The description is two sentences: the first lists the content, the second gives a comparison hint and names the sibling. It is concise and front-loaded with the core purpose. It loses a point because the specific data points list is slightly verbose but still acceptable.

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 adequately summarizes what the tool returns (price, %change, high/low, volume, VWAP, number of trades). It also places the tool in context with the Futures sibling and explains the analytical use case. The tool is simple (1 param, read-only, well-covered schema), so the description is complete enough.

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 coverage is 100%: the symbol parameter includes a clear description, pattern, and example. The description text mentions the parameter only indirectly through the context of 'pasar SPOT Binance' but does not add much beyond the schema. Since the schema already explains the symbol format, the description's addition is minimal, hence a high score but not the maximum.

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 summary of 24-hour statistics for Binance SPOT market, enumerating the specific data points (price, %change, high/low, volume, VWAP, number of trades). It also explicitly distinguishes itself from the sibling binance_get_24hr_ticker for Futures, and the name/title accurately reflect the SPOT market scope.

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

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

The description explicitly tells when to use this tool vs the alternative: it names the Futures sibling tool directly and gives a concrete comparison use case (spot volume much lower than futures implies leverage-driven movement). This is explicit guidance on when to compare and what to look for, going beyond implied usage.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds valuable behavioral detail beyond this: default behavior returns only the current ratio plus up to 10 recent points, while detail:'full' returns complete history according to limit. It also discloses the native Binance data source and the summary/full output distinction, which is 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 compact and front-loaded with the core metric and its interpretation, followed by a contrast with the related ratio and output-mode guidance. It avoids fluff but is written as a single dense sentence; better punctuation or segmentation would improve scannability. Overall it is efficient and every clause earns its place.

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

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

For a relatively simple read-only market data tool with 4 parameters and no output schema, the description conveys the main output modes, the source, and the behavioral distinction from a sibling metric. It does not detail the full response shape or period behavior, but it references docs via the schema for full response details. The description is adequate 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 50%, with symbol and detail already described in the schema. The tool description adds some meaning by clarifying that 'detail: full' returns history according to limit and that the default summary is token-efficient. However, the period parameter has no explanation in either the schema or the description, and the limit semantics are only partially clarified. The description does not fully compensate for the missing 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 the tool returns the taker buy/sell volume ratio as a proxy for aggressive market-order pressure, sourced directly from Binance's native takerlongshortRatio. It also explicitly distinguishes this metric from the long/short ratio, which is based on open positions, successfully differentiating it from sibling tools like binance_get_long_short_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 provides clear usage context by framing the metric as aggressive buying/selling pressure and explicitly contrasting it with the open-position-based long/short ratio. It also gives practical guidance on choosing between the default summary output and the 'full' detail mode to save tokens. It does not enumerate all possible alternative tools, but the key distinction is covered.

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

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

Beyond the readOnlyHint annotation, the description discloses data provenance ('auto dari tool registry'), guarantees that names/descriptions are always accurate, and explains that 'uncategorized' means the tool was not manually curated with a fallback use-case from a truncated description. It does not describe response size or formatting, but the read-only catalog behavior is adequately transparent.

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

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

Two dense sentences front-load the core purpose and usage timing before the caveats. Every clause adds relevant information—what the tool returns, when to use it, why it prevents mistakes, and an important data-quality caveat—with no filler.

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

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

For a simple one-optional-parameter read-only catalog tool, the description covers the output fields, the usage context, and data-quality caveats well. A minor gap is that it does not warn about potentially large responses or truncation, which would be useful for this kind of catalog tool but does not block correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the enum by explaining the meaning of the 'uncategorized' category and the fallback behavior of useCase. It also reinforces that 'all' is the default filter, which is useful context for an agent deciding whether to pass the parameter at all.

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

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

The description names a concrete verb–resource pair ('Daftar semua tool WhaleScope MCP' = list all WhaleScope MCP tools) and enumerates the returned fields (category, estimated token cost, use-case, dependencies). This makes the tool's role as a meta-catalog unmistakable relative to the many data-analysis sibling tools.

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

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

The description gives explicit usage timing: 'Berguna sebelum manggil banyak tool individual' (useful before calling many individual tools), and explains the decision benefit of checking categories/use-cases to avoid wrong tool selection or missing composite tools. It clearly names composite tools as an alternative but does not state an explicit when-not-to-use condition.

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, setting a safety baseline. The description adds valuable behavioral context: the undisclosed threshold, output behavior for summary vs full mode (token-saving), and the existence of a detailed reference doc. 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?

A single well-structured Indonesian sentence/paragraph packs purpose, differentiation, mode guidance, limitation, and default behavior without redundancy. Every clause adds value, and it's not overly verbose for the information conveyed.

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

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

For a tool with 5 params, 1 required, no output schema, the description covers all necessary aspects: what it returns (summary vs full), default values, the critical threshold limitation, and a documentation pointer for further details. It addresses the complexity and provides actionable context for an agent.

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

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

Schema covers 100% of parameters with descriptions. The description adds practical semantics: explains mode 'position' as more relevant for large capital, clarifies detail='summary' as token-efficient with derived metrics, and describes the default limit of 10 points. It goes beyond schema's basic enum 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 specifies it provides the top-trader long/short ratio, distinct from retail, and sourced directly from Binance (not Coinalyze). It distinguishes from sibling tools like binance_get_long_short_ratio by emphasizing 'top trader' and 'separate from retail', giving a specific verb+resource+scope.

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

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

Provides explicit guidance on when to use mode='account' vs 'position' (position more relevant for large capital), and highlights a key limitation: Binance does not publish the top-trader threshold, advising relative comparison to the pair's own history rather than absolute thresholds, with reference to documentation section. This clearly informs usage.

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 bieten schon readOnlyAngle und openWorldSnap. Die Beschreibung ergänzt Informationsumfang: Abdeckung bestimmter Märkte sowie Relevanz für TradFi-Perpetuals. Sie fügt keine Details zu Zeitform, Zeitzone oder Ausgabeformat hinzu, was für den vollen Kontext abverlangt wäre.

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?

Zwei Sätze ohne redundante Information. Der Hauptgegenstand ist vorgelagert, die Relevanz-Aussage ist wie zusätzliche Semantik plaziert ohne Ballast.

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?

Für ein parameterloses, einfaches Get-Teile ist die Beschreibung ausreichend vollständig: Sie nennt zugrunde liegende Asset-Märkte und den Anwendungsfall. Es fehlt keine Parameter- oder Ausgabe symbol nötig; nur ein konkretes Format der Rückgabe wäre noch eventuell erwünscht.

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?

Das Tool hat keine Parameter, damit die Schema-Abdeckung ist 100 %. Die Beschreibung muss daher keinen Parameter-Kontext liefern. Die notwendige Abstraktion ist erreicht.

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?

Beschreibung legt Gegenstand klar fest: Handelszeiten/Handelszeiten für Basiswerte aus US, Korea, Hongkong, China und Rohstoffe. Der Verwendungszweck wird deutlich vom Toolnamen unterschieden, auch wenn kein explizites Listenausführungsverb vorhanden ist.

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?

Die Angabe 'Sangat relevan untuk TradFi perpetual' liefert expliziten Kontext, wann dieses Tool nützlich ist. Alternativen werden nicht benannt/ausgeschlossen, aber für ein parameterloses Planungs-Symbol ist keine förmliche Abgrenzung nötig.

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 dan openWorldHint=true sudah menandakan operasi aman; deskripsi menambah nilai dengan mengungkapkan metodologi penting, yaitu perhitungan spike volatilitas/volume dibandingkan 10 candle sebelumnya pada timeframe yang sama, bukan baseline historis persisten. Tidak ada kontradiksi dengan 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?

Deskripsi hanya dua kalimat, langsung menyampaikan tujuan, indikator, output, dan caveat penting. Tidak ada pengulangan informasi schema atau kata mubazir; setiap bagian berkontribusi.

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?

Deskripsi cukup lengkap untuk tool 2-parameter tanpa output schema: menyebutkan daftar output, input, metodologi, dan perilaku per-timeframe. Kekurangan kecil adalah tidak menjelaskan format/struktur nilai kembalian, tetapi daftar regime sudah cukup untuk penggunaan dasar.

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 100% dan kedua parameter sudah didokumentasikan lengkap dengan enum, default, dan contoh. Deskripsi menambah makna bahwa interval menentukan regime independen, sehingga agent tahu untuk memanggil ulang dengan interval berbeda. Ini melampaui informasi skema.

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?

Deskripsi menyatakan secara spesifik bahwa tool mengklasifikasikan 1 dari 6 regime pasar (TRENDING_UP/DOWN, RANGING, BREAKOUT, ACCUMULATION, DISTRIBUTION) menggunakan ADX, tren OI, CVD, dan spike volatilitas/volume. Ini membedakannya dari sibling-sibling yang fokus pada data mentah atau analisis spesifik lainnya, tanpa tautologi.

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?

Deskripsi memberikan panduan eksplisit untuk memanggil ulang dengan interval berbeda guna mendapatkan regime independen per timeframe. Konteks penggunaan cukup jelas, meskipun tidak menyebutkan kapan tidak menggunakan tool ini atau alternatif yang lebih cocok.

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

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

Annotations already indicate readOnlyHint=true, and the description adds meaningful behavior beyond that: it uses a single premiumIndex call without a symbol rather than looping per-pair, and it ranks pairs into crowded long/short buckets. This is useful operational context not present in annotations or schema.

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

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

Three dense sentences, each earning its place: purpose/scope first, implementation detail second, sibling contrast and threshold third. No fluff 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?

Without an output schema, the description explains the key return concept (ranked crowded long/short pairs) and all behavioral caveats (single call, all pairs, threshold). It does not specify exact output fields, but the agent can select and invoke the tool correctly with the information given.

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%: both limit and quoteFilter are fully described with defaults, ranges, and meaning. The description itself adds no param-specific information beyond tool-level context, so it stays at the baseline for a fully schema-documented tool.

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

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

Description uses a specific verb + resource + scope: it scans funding rates for ALL pairs at once via one premiumIndex call, then ranks crowded long and short pairs. It also explicitly distinguishes itself from sibling binance_get_funding_rate, which requires a specific 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?

Explicitly names the alternative tool (binance_get_funding_rate) and explains the difference: this tool scans all pairs, the sibling needs a specific symbol. It also clarifies the crowd threshold (±0.03%), giving concrete selection criteria.

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

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

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds substantial behavioral context beyond that: data lags several days, weekly release cadence, no real-time capability, and the requirement of a paid data vendor for real-time basis. These are exactly the behavioral traits an agent needs to know and they contradict nothing 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 core value is front-loaded ('net long/short Leveraged Funds + Asset Managers, plus perubahan vs minggu lalu') before the critical caveat about data lag and non-intraday nature. Every clause earns its place and the caveat is essential. Slightly dense with parentheticals and informal register, but nothing is wasteful — a tight, informative block.

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 report tool with a single enum parameter, the description covers the data provided, the two fund categories, week-over-week change, data lag timing, and scope limits (no real-time vs Binance). The annotations cover safety and the schema covers the parameter fully. The only gap is return-format details, but no output schema exists and the description compensates well otherwise.

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 single coin parameter is already fully documented with its enum (BTC/ETH) and a description. The tool description's mention of Bitcoin/Ether aligns with the schema but adds no new parameter-specific meaning beyond what the schema provides. The baseline 3 is appropriate when the schema does the heavy lifting for a single well-documented parameter.

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

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

The description states a specific resource (CFTC Commitment of Traders weekly report for CME Bitcoin/Ether contracts) and what it delivers (net long/short for Leveraged Funds and Asset Managers, plus week-over-week change). It clearly differentiates this from the many Binance intraday tools in the sibling list by positioning it as a lagged weekly institutional-positioning report, so an agent can tell it apart without opening any schema.

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

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

The description explicitly says when NOT to use it: 'BUKAN sinyal intraday' (NOT an intraday signal) and 'gak ada real-time basis vs Binance' (no real-time basis vs Binance), giving clear exclusion context. It explains the data cadence (released Friday, positions as of Tuesday). It doesn't name a specific alternative tool to use instead, which keeps it from a 5, but the temporal caveats strongly steer appropriate use.

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

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

Beyond readOnlyHint=true and openWorldHint=false, the description discloses the full OLS method, the additional maxStepDelta statistic, dependency on injected history, and the absence of categorical labels. This adds substantial behavioral context and 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 dense sentences front-load the core purpose and follow with essential caveats about input injection and output format. No wasted words.

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 computation method, input requirement, and raw-number output. However, with no output schema, the exact returned fields (e.g., slope, maxStepDelta) are not explicitly enumerated, leaving slight ambiguity for an agent.

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

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

Schema description coverage is 67%; the description compensates for the undocumented fundingHistory parameter by specifying it must come from binance_get_funding_rate_history. Symbol and velocityWindowIntervals semantics are already covered by the schema, so the added value is moderate.

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

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

The description states a specific computation: OLS regression over the last funding window to produce per-hour velocity, plus maxStepDelta for spike detection. It clearly differentiates from sibling fetch/classification tools by stating history is caller-injected and output is raw numbers, not categorical labels.

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

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

Explicitly instructs the agent to pass the result of binance_get_funding_rate_history rather than fetching internally, defining a clear prerequisite and complementary sibling. It also explains why the metric matters (capturing spike-then-reversal when net slope is near zero), though it does not enumerate exclusions versus other analysis tools.

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