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

Annotations already cover readOnlyHint=true and destructiveHint=false, so the safety profile is disclosed. The description adds the multi-timeframe behavioral aspect and parameter constraints, but does not reveal return format or other operational details. This is acceptable given annotation coverage, 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?

The description is appropriately concise: one purpose sentence followed by an Args list. Every line carries useful information and it is front-loaded with the core purpose.

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

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

The description covers purpose and all parameters, but lacks return-value information (no output schema exists) and does not distinguish itself from sibling tools like multi_timeframe_analysis. These gaps are notable given the absence of structured output documentation.

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

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

Schema description coverage is 0%, but the description's Args section provides clear explanations for all five parameters, including concrete examples and ranges (e.g., 'BINANCE, KUCOIN', '5m, 15m, 1h, 4h', '2-4'). This fully compensates for the schema's lack of 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 tool performs 'advanced candle pattern analysis using multi-timeframe data,' which is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like consecutive_candles_scan or multi_timeframe_analysis, so it misses full 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 gives some context ('using multi-timeframe data') implying when this tool is appropriate, but it offers no explicit when-to-use/when-not-to-use guidance or references to alternatives. This is enough for an implied usage but not clear directional guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it lists strategy options, notes warmup requirements for specific strategies, and explains that include_trade_log and include_equity_curve control additional outputs. This goes 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?

The description is efficiently structured: a one-sentence purpose statement followed by a clean list of arguments with defaults and inline constraints. Every line adds useful information, and the format is front-loaded with the tool's 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?

With 9 parameters and no output schema, the description covers all parameters and includes important constraints and examples. It mentions 'institutional-grade metrics' as the primary output, and the optional trade log/equity curve flags imply the default return shape. Missing return format details are a minor gap, but overall the description is complete enough 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 description coverage is 0%, so the description must compensate. It does so by explaining every parameter: symbol format examples, allowed strategy values, period options, interval options, and the meaning of commission_pct, slippage_pct, and booleans for additional outputs. This adds meaning well beyond the schema's bare property listings.

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

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

The description states the tool's function clearly: 'Backtest a trading strategy on historical data with institutional-grade metrics.' It uses a specific verb (backtest) and resource (strategy on historical data). It distinguishes from siblings like compare_strategies and walk_forward_backtest_strategy primarily by the singular focus on one strategy, though it doesn't explicitly name alternatives.

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

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

The description implies usage for performing a single-strategy backtest but provides no explicit guidance on when to choose this tool versus alternatives like compare_strategies or walk_forward_backtest_strategy. It does include parameter-level constraints (e.g., rsi_pullback and triple_ema need period >= '1y' for SMA200 warmup), which gives some context but not tool-selection guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior context beyond that by detailing the return structure (bitcoin, dominance, total_market, assessment) and the risk assessment labels, which is not present in the 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 front-loaded with a clear one-line purpose, followed by a usage rationale and a structured return summary. Every section contributes meaningfully, and the length is justified by the richness of what the tool returns.

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

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

Given the tool has no inputs and no output schema, the description fully compensates by enumerating all return fields and risk labels. It also provides usage context and alternatives, making the tool self-contained and well-understood.

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

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

The tool has zero parameters, so the baseline for this dimension is 4. The description adds no input semantics because none are needed; instead it clarifies the output format, which is appropriate for a no-input tool.

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

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

The description clearly states the tool's function with a specific verb ('Single-call BTC macro context') and enumerates its components: price, dominance, total market cap, and risk assessment. It distinguishes itself from sibling tools by emphasizing that it provides macro context for any crypto analysis, contrasting with per-coin or other market tools.

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

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

Explicitly instructs when to use: 'Use this WHENEVER analyzing any cryptocurrency' and provides a concrete scenario (BTC dumping vs. alts leading). It also names an alternative approach (chaining yahoo_price + manual reasoning) that this tool replaces, making the usage boundary clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it scans a whole exchange, works with crypto and stocks, and returns a structured error envelope on any failure. It also clarifies the canonical name to avoid tool confusion. This adds significant transparency 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 well-organized with a clear intro, differentiation note, example, argument descriptions, and return behavior. Every sentence adds value, and despite the length, it remains focused and front-loaded with the core purpose. No redundancy or filler.

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

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

Given the tool's complexity (4 parameters, multiple exchange categories, thresholds, sibling relationships), the description fully covers purpose, usage, parameters, return types, and error behavior. The presence of an output schema does not require explaining return values, but the description does so anyway, making it 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 has 0% description coverage, so the description carries the full burden and excels. It explains each parameter: exchange lists supported venues for crypto/stocks, timeframe enumerates valid values with typical squeeze thresholds, bbw_threshold defines the filter meaning and default, limit specifies maximum rows. An example call further clarifies usage.

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

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

The description clearly states the tool's purpose: 'Scan for assets with low Bollinger Band Width (squeeze detection).' It specifies the resource (assets), the action (scan), and explicitly differentiates from a sibling tool: 'For the Bollinger read of ONE symbol, call coin_analysis instead.' This is a specific verb+resource+scope with clear sibling 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?

Provides explicit when-to-use guidance: scans a whole exchange for squeezes, not a single symbol. It names the alternative tool for single-symbol analysis ('coin_analysis'). Also supplies typical threshold values per timeframe, giving concrete usage context. This goes beyond minimal guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. The description adds valuable behavior context: it is the canonical single-symbol readout, includes detailed error handling for symbol-exchange mismatches, and clarifies the return type (all indicators and metrics). It doesn't mention rate limits or output format specifics, but for a read-only analysis tool, 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?

Although the description is moderately long, it is well-structured with an intro, canonical note, alternatives, example, Args section, and Returns. Every sentence serves a purpose—no fluff—and the first sentence immediately states the tool's function. The format is front-loaded and 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 tool has 3 parameters, no enums, and no output schema, so the description carries significant weight. It covers all parameter formats, an example, error handling, and a return summary. However, the return description ('Detailed analysis with all indicators and metrics') is vague; including a hint about what metrics are returned would push this to a 5.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains symbol with concrete examples (BTCUSDT, COMI, THYAO, etc.), enumerates exchange values for both crypto and stocks, and lists all valid timeframes. This goes far beyond the bare schema (type string) and gives agents everything needed to fill parameters correctly.

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 'Get detailed analysis for a specific asset on specified exchange and timeframe' with a specific verb and resource. It explicitly distinguishes from siblings by noting this is the canonical single-symbol readout and there is no 'get_technical_analysis' or 'get_technical_summary' tool, making purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool vs alternatives: use multi_timeframe_analysis for trend alignment across timeframes and combined_analysis when news sentiment is needed. It also gives practical error handling advice (the error's listed_on field names exchanges) and an example invocation.

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 destructiveHint=false, and the description adds context beyond that: it is a 'POWER TOOL' that combines three data sources, and it notes that coin_analysis is 'faster' for indicators only, implying this tool may be slower or heavier. It does not disclose output format or potential rate limits, but given the strong annotation coverage, 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 well-organized with a clear purpose statement, usage guidance, example, and Args section. It is front-loaded and avoids unnecessary fluff, though the 'POWER TOOL:' prefix is slightly informal but still serves to emphasize the tool's composite nature.

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 tool combining TA, sentiment, and news, the description explains what it does and its parameters, but it does not describe the return value or output structure. With no output schema, this is a notable gap. It also omits any mention of supported symbol types beyond the exchange list, which is partially inferred.

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

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

Schema descriptions are absent (0% coverage), but the description compensates fully by explaining each parameter: symbol must be a 'bare ticker, no exchange prefix', exchange lists valid values, and timeframe lists valid intervals. The example call also clarifies usage, which is especially valuable for the symbol 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 states the tool's function: 'TradingView technical analysis + news sentiment + financial news.' It explicitly says 'Use this when you want TA AND sentiment AND news for one symbol in a single call,' and distinguishes from siblings by naming coin_analysis for indicators-only and multi_timeframe_analysis for cross-timeframe alignment.

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 usage guidance: 'Use this when...' and names alternatives with specific conditions. It also gives an example call and lists accepted exchanges and timeframes, making it very clear when to choose this tool over others.

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

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

Annotations already declare this as a safe, read-only operation. The description adds valuable behavioral context, such as the consequence of using shorter periods ('otherwise they contribute zero trades'), which is not apparent from 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 well-structured with a concise action sentence followed by a clean Args list. Every sentence provides necessary information, and there is no redundant or vague wording.

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

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

For a read-only analysis tool with clear parameters and caveats, the description is nearly complete. It lacks details on the exact ranking metrics in the returned leaderboard, but this is not essential for selecting or invoking the tool correctly.

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

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

Schema coverage is 0%, so the description carries the full burden. It explains every parameter: symbol with examples, period with allowed values and a warmup caveat, initial_capital with default, and interval with '1d' vs '1h'. This fully compensates for the schema's lack of 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 tool's function: 'Run all 9 strategies... and return a ranked leaderboard.' It enumerates the exact strategies, making it highly specific and distinct from sibling tools like backtest_strategy or multi_agent_analysis.

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

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

The description provides clear context for parameter usage, especially the recommendation that 'period >= "1y"' is needed for rsi_pullback and triple_ema to complete SMA200 warmup. However, it does not explicitly compare this tool to alternatives or state when to choose it over similar backtesting 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 destructiveHint=false, which matches the description's 'Scan' action. However, the description adds minimal behavioral context beyond the annotations, such as return format or pagination behavior. It is consistent and safe, but does not enrich the annotation-provided 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 and front-loaded with the core scanning purpose, followed by a clearly formatted Args block. Every sentence provides necessary information without redundancy or fluff, making it efficient and easy to parse.

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

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

The description covers the tool's purpose and parameter semantics well, and annotations provide safety context. Since there is no output schema, the description could better explain the exact return structure, but 'Scan for coins' and 'limit' implying a list of matching coins is sufficient for a straightforward read-only scanner. Overall, it is fairly 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?

With 0% schema description coverage, the description compensates by providing meaningful Arg descriptions for all 6 parameters. It explains pattern_type values ('bullish'/'bearish'), gives a range for candle_count (2-5), defines min_growth as percentage, and clarifies timeframe and exchange names. This adds significant value beyond the empty schema 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 'Scan for coins with consecutive growing/shrinking candles pattern' uses a specific verb and resource, clearly indicating this tool scans for coins based on a specific candle pattern. This distinguishes it from siblings like volume breakout scanners or advanced candle pattern tools, which focus on different detection logic.

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 scanning consecutive candle patterns but does not explicitly state when to use this tool versus alternatives. No mention of exclusions, prerequisites, or alternative tools is provided, leaving the usage context implied by the tool name 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds parameter options (lookback, timeframe) but does not disclose output format, calculation methodology, or other behavioral traits beyond the structured 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 succinct, consisting of a one-sentence summary followed by a clean, structured args list. No redundant information is present, and each line adds value.

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

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

Parameter documentation is thorough, and the tool is straightforward. However, the description does not mention what the analysis returns (e.g., retracement levels or a chart), and there is no output schema to fill this gap, leaving a minor completeness issue.

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 description explains all three parameters in detail, providing examples for symbol, valid values for lookback and timeframe, and defaults. Since the input schema has 0% description coverage, this fully compensates for the missing schema-level 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 'Fibonacci retracement analysis for EGX stocks,' which is a specific verb+resource combination. This distinguishes it from sibling tools like egx_market_overview and egx_sector_scan, none of which mention Fibonacci.

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 Fibonacci analysis on EGX stocks but provides no explicit guidance on when to choose this tool over alternatives. It does not mention exclusions or alternative tools, leaving the context partially 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=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds parameter constraints and mentions 'full indicators' as output, but it does not disclose details like pagination, data delays, or the specific indicator names, which would be useful 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 extremely concise: one sentence explaining the purpose followed by a structured args list. Every word earns its place, with no fluff or redundancy. It is front-loaded with the core purpose and then provides parameter specifics.

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's mention of 'full indicators' gives a high-level view but lacks specifics on return structure (e.g., fields like price change, volume, weight). However, the tool is relatively simple with all parameters explained, and annotations cover safety. It is adequate for an agent to understand the tool's purpose and usage, though a bit more output detail would make it fully 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 0%, but the description fully compensates by enumerating valid index values (EGX30, EGX70, EGX100, SHARIAH33, EGX35LV, TAMAYUZ), valid timeframes (5m, 15m, 1h, 4h, 1D, 1W, 1M) with a default of 1D, and explaining the limit parameter as 'Number of stocks to show in detail (max 100)'. This adds complete semantics beyond the bare schema.

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

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

The description states 'Analyse an EGX index showing constituent performance with full indicators', providing a specific verb (analyse), resource (EGX index), and output scope (constituent performance with indicators). This clearly distinguishes it from sibling tools like egx_market_overview or egx_sector_scan, which focus on broader market or sector views.

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

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

The description implies usage through the specification of index, timeframe, and limit, but it does not explicitly state when to use this tool versus alternatives. It lacks guidance such as 'use this for index-level constituent analysis instead of market overview' or any exclusionary 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, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds no behavioral details such as data source, real-time nature, or pagination behavior, beyond the fact that it returns an overview. Thus it provides little value 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 compact and well-structured, leading with a one-sentence purpose followed by an 'Args:' block listing each parameter with its semantics. No filler or redundant statements, making it highly efficient.

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

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

Given the tool has no output schema, the description should at least hint at what the response contains, but it doesn't. There's no mention of what categories are included, whether it returns indices, top movers, or other data. The tool is simple enough that this lack may be tolerable, but it still leaves the agent guessing about the return format.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation in the schema. It does this by explaining the allowed values for timeframe (5m to 1M) with a default, and stating that limit is the 'Number of stocks per category' with a max of 20. This gives the agent sufficient semantic understanding of both parameters, though it doesn't explain how they affect the output.

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 'comprehensive overview of the Egyptian Exchange (EGX) market,' which is a specific verb and resource. It distinguishes itself from sibling tools like egx_sector_scan or egx_index_analysis by focusing on the overall market rather than a specific segment. However, it doesn't enumerate exactly what 'overview' includes, so it's not maximally 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 offers no guidance on when to use this tool versus alternatives. It merely states the tool's function and its parameters, without mentioning exclusions or related tools like market_snapshot or egx_sector_scan. Even implied usage context is absent.

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

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

Annotations already declare readOnlyHint=true, and the description adds behavioral nuance like 'Shows available sectors if none specified' and 'Max results per sector (max 50)'. These add value beyond annotations, though it doesn't describe output format or error behavior.

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

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

The description is concise, starting with a clear one-liner, then a helpful conditional note, followed by a structured args block. Every sentence earns its place; 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 read-only scan tool with fully documented parameters, the description is nearly complete. It could mention the return format, but given no output schema, it's not necessary. The parameter coverage is strong.

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

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

Schema description coverage is 0%, so the description bears full burden. It enriches all three parameters: lists sector examples, specifies exact timeframe values (5m, 15m, 1h, 4h, 1D, 1W, 1M), and imposes a max limit of 50. This fully compensates for the schema's lack of 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 'Scan EGX stocks by sector' with a specific verb and resource. However, it does not differentiate from the closely-named sibling 'egx_sector_scanner', so it falls short of 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 provides usage context (e.g., 'Leave empty to list all sectors') but does not explicitly mention when to use this tool over alternatives like egx_sector_scanner. The usage is implied rather than explicitly contrasted.

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 destructiveHint=false, covering the safety profile. The description adds the operational scope (hot/cold sectors, top picks) and parameter ranges, but does not disclose any additional behavioral traits such as output format, data source, or limitations. No contradiction with annotations exists.

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

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

The description is a single succinct sentence followed by a clean, readable args list. Every element serves a purpose; 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?

The description covers the tool's purpose and all four parameters comprehensively. It lacks an explicit description of the return value/output structure, which is notable given there is no output schema. However, the read-only annotations and thorough parameter documentation make the tool well-specified for an agent to 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 input schema has 0% description coverage, and the description fully compensates by explaining each parameter: timeframe with allowed values (5m, 15m, 1h, 4h, 1D, 1W, 1M), top_n_sectors (1-18), top_n_stocks (1-10), and min_stock_score (0-100). This adds significant meaning beyond the schema's type/default information.

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 'Sector rotation scanner for EGX — identifies hot/cold sectors and top picks,' providing a specific verb ('identifies') and resource (EGX sectors). It clearly conveys the function but does not distinguish from the similarly named sibling 'egx_sector_scan', so it stops short of full clarity.

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?

No usage context or alternatives are mentioned. The description does not state when to use this tool versus similar siblings like 'egx_sector_scan' or 'egx_market_overview'. The only implied usage comes from the tool's name and opening sentence, which is insufficient.

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 destructiveHint=false, so the description only needs to add context. It adds parameter constraints (timeframe options, min_score range, limit max 50) and emphasizes production readiness, which is useful beyond annotations. However, it does not describe output structure or rate limits, though this is a minor gap given the annotation coverage.

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

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

The description is concise and well-structured: a single front-loaded purpose statement followed by a clean args block. Every sentence and line provides necessary information without redundancy.

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

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

For a tool with four optional parameters, no output schema, and simple annotations, the description is nearly complete for selection and invocation. It covers purpose, all parameters, and constraints. The only minor gap is not explicitly stating the return format (e.g., a list of stocks with scores), but this is reasonably implied.

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

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

The schema has zero description coverage, but the tool description explicitly explains all four parameters with allowed values, defaults, and constraints. It adds significant meaning beyond the bare schema (e.g., index_filter values, max limit of 50, score range 0-100).

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 'Production stock ranking engine for EGX' with the specific action of finding 'strong stocks with actionable setups.' This distinguishes it from generic market overview tools or price lookups by focusing on ranking and trade setups.

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 use for screening EGX stocks by timeframe, score, and index, but does not explicitly state when to use it versus alternatives like egx_market_overview or stock_screener. No exclusion criteria or alternative references are provided.

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 destructiveHint=false, so the safety profile is known. The description adds no behavioral details such as output format, latency, data sources, or what 'full trade plan' entails beyond the name. It neither contradicts annotations nor enriches the agent's 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 compact and front-loaded: the first sentence states the purpose, followed by a tight args list. Every sentence earns its place, with 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?

The tool is simple (2 params, no output schema), and the description covers the core essentials of what it does and how to call it. However, the phrase 'full trade plan' is vague—the description does not clarify what the returned plan contains (e.g., entry/exit levels, risk guidelines, or analysis), which would be useful for an agent deciding how to use the result and whether this tool meets the user's request.

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 schema description coverage at 0%, the description fully compensates. It provides concrete EGX symbol examples ('COMI', 'TMGH', 'FWRY') and explicitly enumerates valid timeframe values (5m, 15m, 1h, 4h, 1D, 1W, 1M) with a default, making parameter selection unambiguous and greatly exceeding the schema's bare string types.

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 'Generate a full trade plan for a specific EGX stock,' using a specific verb ('generate'), a distinct resource ('full trade plan'), and explicit scope (EGX stock). This differentiates it from sibling tools like egx_market_overview or egx_sector_scan, which focus on overviews or screens.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or why an agent should pick this over sibling tools such as multi_agent_analysis or backtest_strategy. The usage context is only implied by the purpose statement.

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 destructiveHint=false, so the safety profile is covered. The description adds the source (Marketaux) and licensing, but does not disclose details like rate limits, response format, or pagination. It meets the baseline but adds limited behavioral context.

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

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

The description is concise and front-loaded, with the core purpose in one sentence followed by a compact argument list. Every line adds value without unnecessary verbosity.

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 purpose and parameters, and annotations cover safety. It lacks any mention of return format or output structure, which is a minor gap given there is no output schema. Overall, it is nearly complete for a simple news-fetching tool.

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

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

The schema has 0% description coverage, so the description compensates by explaining each parameter: symbol filter, category options, and limit meaning. It provides meaningful context beyond the schema's bare types and defaults, though details could be slightly richer (e.g., symbol format).

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 real-time financial news via Marketaux, which is a specific resource and source. This distinguishes it from sibling analysis and scanning tools, 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 implies usage for financial news retrieval but gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions, though the tool's unique news focus makes the context somewhat obvious.

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

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

Annotations already declare read-only and non-destructive behavior. The description adds useful transparency by specifying that it returns OHLCV quotes for front-month contracts from a standard watchlist, with example symbols. This goes beyond the safety profile.

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

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

The description is well-structured with Args and Returns sections, front-loads the main purpose, and every sentence adds value, including examples. It is appropriately sized 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 tool with no output schema, the description is complete: it documents the parameter values, the return format (OHLCV), and the scope (front-month, standard watchlist). The example symbols further clarify expected output.

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 only defines an unconstrained string with a default, and has 0% schema description coverage. The description compensates fully by listing all acceptable category values and providing example output symbols, effectively giving enum-like guidance.

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

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

The description clearly states that the tool quotes all major front-month contracts in a specific futures category. It lists valid categories and provides example symbols, making it distinct from sibling tools like futures_market_overview or futures_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 provides clear context for when to use this tool: when needing quotes for a specific futures category, with an explicit list of categories. However, it does not mention alternative tools or specific exclusion scenarios, so it lacks full comparative guidance.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds return behavior (a dict with count and OHLCV data) and sorting by volume, providing some context beyond annotations. However, it does not disclose details like pagination, potential rate limits, or exact sort direction.

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

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

The description is concise and well-structured with a clear purpose sentence followed by Args and Returns sections. Each parameter is documented on its own line with meaningful details, and there is no wasted text.

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 overview tool with four optional parameters and no output schema, the description provides essential information: parameters, defaults, and return structure. It lacks an example or note on sort direction (descending assumed), but is otherwise sufficient 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 0%, so the description carries full responsibility for parameter explanations. It provides detailed semantics for all four parameters: category with enumerated values, exchanges with region breakdowns, limit with default, and volume_min with filter behavior. This fully compensates for the schema's lack of 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 opens with 'Top futures contracts sorted by trading volume,' clearly indicating the tool's scope and primary function. It lacks an explicit verb like 'get' or 'list,' and while it distinguishes itself through category/exchange filters, it does not explicitly differentiate from sibling tools like futures_top_movers.

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

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

No guidance is provided on when to use this tool versus alternatives such as futures_top_movers or futures_category_snapshot. The parameter list implies usage scenarios (e.g., filtering by category or exchanges), but there is no explicit context or exclusion criteria.

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

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

Annotations declare readOnlyHint and destructiveHint=false, so the safety profile is clear. The description adds behavioral context beyond annotations by explaining that volume_min filters illiquid contracts and that the return includes OHLCV data ranked by percentage change. It does not mention pagination or rate limits, but for a read-only list tool 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 well-structured with clear Args and Returns sections, using concise wording. Every part serves a purpose with no redundancy or filler, making it easy to scan and parse.

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

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

The description provides a complete picture for a straightforward data-retrieval tool: purpose, parameter semantics, and return format. It lacks some advanced context like pagination or edge-case behavior, but given the tool's simplicity and the presence of annotations, it is sufficiently complete.

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

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

With 0% schema description coverage, the description fully compensates by documenting all four parameters: direction (gainers|losers), exchanges (us|global), limit (max results), and volume_min (minimum volume filter default 10, filters illiquid contracts). This adds meaning beyond the schema's basic type and default information.

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 futures contracts with the biggest percentage moves today, using a specific verb and resource. It distinguishes from non-futures top movers but does not explicitly differentiate from all sibling tools like futures_watchlist or futures_category_snapshot, though the focus on top percentage movers is unique.

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 no guidance on when to use this tool versus alternatives such as futures_market_overview or top_gainers. It does not state exclusions or provide context for choosing this over other futures or market-scanning tools, so usage context is left entirely implicit.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the behavior is safe/read-only. The description adds that it returns the 'full categorized list' of 'well-known' symbols, giving insight into the scope and nature of the data, which goes beyond the annotation metadata.

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 concise sentences. The first states the core function, and the second lists categories and provides usage guidance. 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 zero-parameter tool with no output schema, the description is fully adequate. It states what is returned, the categories included, and suggests next steps for deeper analysis. No important information is missing.

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

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

The tool has zero parameters, and schema description coverage is 100% (effectively complete). No parameter explanation is needed, so the baseline of 4 applies.

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

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

The description clearly states the tool returns a full categorized list of well-known front-month futures symbols. It uses a specific verb ('return') and resource ('futures symbols'), and distinguishes itself from sibling analysis tools by being a list/symbol source.

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

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

The description provides clear context for when to use it: as a source of symbols for deeper analysis with futures_category_snapshot or coin_analysis. It names alternatives and suggests follow-up usage, though it doesn't explicitly state when not to use it compared to other market overview 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 destructiveHint=false, so the tool's safety profile is clear. The description adds some context by mentioning the licensed Marketaux data source, but it does not describe output format, rate limits, or other behavioral traits. With annotations covering the safety aspects, this is 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?

The description is extremely concise, with a one-sentence purpose followed by a clean Args list. Every sentence earns its place, and the structure is front-loaded and scannable. No superfluous 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 simple with three parameters and no output schema. The description covers the basic purpose and parameters, but it does not explain what the sentiment output looks like (e.g., a score, classification, or text) or how to interpret it. It also lacks usage context. Given the simplicity, it is minimally adequate but leaves the return format ambiguous.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by providing example symbols, enumerating category values, and explaining limit as 'Max articles to analyse'. This adds meaningful semantics beyond the bare schema, though it could be more detailed (e.g., format expectations or defaults).

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 news sentiment for stocks and crypto, with the specific detail of being a licensed Marketaux entity sentiment. It distinguishes from sibling tools like financial_news by focusing on sentiment rather than raw news. However, it uses a noun phrase rather than an explicit verb like 'get' or 'analyze', which slightly reduces clarity.

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 no guidance on when to use this tool versus alternatives. It only lists arguments and does not mention any exclusions or preference over sibling tools like financial_news or market_snapshot. No context on typical use cases is provided.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that it is 'Powered by Yahoo Finance,' which is useful context about the data source. However, it doesn't provide additional behavioral details like data freshness, rate limits, or the scope of 'global' (e.g., which exchanges are included). Thus, it adds some value beyond annotations but not extensive behavioral 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 two concise sentences, front-loaded with the core purpose and supported by a data-source attribution. Every word earns its place, and there is no redundancy or fluff. It is well-structured and 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?

For a zero-parameter, read-only tool with no output schema, the description is fairly complete: it specifies the asset classes and the data provider. However, it could be more complete by mentioning the return format, update frequency, or the fact that this is a broad snapshot versus a detailed analysis. Given the simplicity of the tool, the current description is nearly sufficient.

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

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

There are zero parameters, and schema description coverage is 100% (since there is nothing to describe). The baseline for a zero-parameter tool is 4. The description doesn't need to explain parameters, and it doesn't. It does mention the output scope (what asset classes are covered), which partially compensates for the lack of parameters.

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

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

The description clearly states the tool provides a global market overview with specific asset classes (indices, crypto, FX, ETFs). It uses a specific verb ('overview') and resource ('global market'), making the purpose clear. However, it doesn't explicitly distinguish itself from sibling tools like egx_market_overview or futures_market_overview, so it loses a point for lack of sibling differentiation.

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 no guidance on when to use this tool versus alternatives. There is no mention of when to choose market_snapshot over egx_market_overview, futures_market_overview, or other market analysis tools. The description simply states what it does without offering context on selection criteria 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 destructiveHint=false. The description adds context by explaining the debate process and the return value (a structured debate with a final trading decision). It does not mention side effects or rate limits, but for a read-only analysis tool, this is sufficient 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?

The description is well-structured with a clear purpose sentence, an Args block, and a Returns line. Every sentence adds value, with no fluff. It is appropriately sized for the tool's complexity and front-loads the main action.

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

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

Given the tool's complexity (multiple exchanges, timeframes, agent types) and the lack of an output schema, the description provides sufficient detail on inputs and outputs. It explains what the user gets back and gives enough examples to understand the parameters. The description is complete for an agent to select and invoke the tool appropriately.

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

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

Schema description coverage is 0%, so the description fully compensates. The Args section provides concrete examples for symbol ('BTCUSDT', 'COMI', 'THYAO', etc.), lists valid exchange values, and specifies allowed timeframes. This goes well beyond the bare schema type definitions, giving the agent sufficient semantic detail to invoke the tool correctly.

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 ('Run'), a concrete resource ('a multi-agent debate'), and the exact agent types (Technical, Sentiment, Risk) for a given symbol. It is distinct from sibling tools that focus on single indicators or market scans, so it clearly differentiates its function.

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

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

The description implies when to use it: when a comprehensive multi-agent debate on a symbol is desired. It does not explicitly name alternatives or exclusions, but the context is clear and the tool's purpose is sufficiently unique among siblings. It lacks a 'when not to use' note, which prevents a perfect score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: the exact timeframe chain, that it operates on ONE symbol only, the canonical name warning (avoiding the incorrect 'get_' variant), and the supported exchanges/markets. It does not describe output format or pagination, but the safety profile is well covered by annotations, and the added details are valuable.

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

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

The description is longer than average but every sentence serves a purpose: purpose, sibling alternatives, a working example, and parameter semantics. It is well-structured with an 'Args' section, avoids filler, and front-loads the key takeaway. No redundant text is present.

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 and no return value documentation, the description adequately covers what the tool does, when to use it, and how to call it with valid parameters. It could be enhanced by summarizing the expected output shape (e.g., alignment signals per timeframe), but the core selection and invocation context is complete enough for an agent to use 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 descriptions cover 0% of the parameters, but the description fully compensates by explaining `symbol` with concrete crypto and stock examples (e.g., 'BTCUSDT', 'COMI', '600519') and `exchange` with explicit lists for both crypto and stock exchanges. This provides far more meaning than the raw schema, making the invocation precise and reducing guesswork.

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 performs multi-timeframe alignment analysis with specific timeframes (Weekly to 15m). It explicitly distinguishes this from `coin_analysis` and `combined_analysis`, making the tool's purpose unambiguous even among many siblings.

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

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

The description gives direct usage guidance: use for cross-timeframe trend alignment on one symbol, with explicit alternatives for single-timeframe deep dive (`coin_analysis`) and combined TA+sentiment+news (`combined_analysis`). It also provides a concrete calling example, clearly telling the agent when and how to invoke.

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 destructiveHint=false, so the safety profile is established. The description adds useful behavior about the return type (list[dict]) and the error envelope on failure, which goes beyond annotations. However, it does not elaborate on what the dicts contain or any further behavioral details, so a mid-range score is appropriate.

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

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

The description is concise and well-structured, using an Args section to list parameters and a separate line for the return and error envelope. Every sentence is informative and there is no wasted text, making it easy to parse quickly.

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 (4 params, no required fields, no enums), the description covers all necessary aspects: it explains each parameter, the return type, and the error format. Even though an output schema exists, the description's note about list[dict] and the error envelope is sufficient for the agent to understand expected outcomes.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter: exchange with examples, timeframe with allowed values, rating with the BB scale, and limit with a max. This adds significant meaning beyond the bare schema, making it easy to select correct argument values.

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

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

The description clearly states the tool filters coins by Bollinger Band rating, specifying the verb ('Filter'), resource ('coins'), and scope ('by rating'). However, it does not distinguish this from sibling tools like bollinger_scan, which likely also operate on Bollinger Bands, so it falls short of 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 provides no guidance on when to use this tool versus alternatives. It only explains the arguments and return behavior, leaving the agent to infer usage context from the name and description. No exclusions or alternative recommendations are mentioned.

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

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

Annotations already establish read-only safety (readOnlyHint=true, destructiveHint=false). The description adds useful behavioral details beyond annotations, including the return type (list[dict]) on success and the structured error envelope on any failure. It also documents valid values for rsi_range, which clarifies expected behavior.

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

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

The description is well-structured with a one-line summary, an Args list, and a return/error note. It is concise and every line provides value, though the summary could be more precise about the exact screening criteria. Overall, it is appropriately sized without 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?

The tool has 5 optional parameters, all explained in the description. The output schema exists, so return details are sufficiently covered. The description also discloses failure behavior. However, it lacks specifics about supported exchanges or a typical use case, but these are minor gaps given the annotations and parameter explanations.

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 provides only names, types, and defaults with no descriptions (0% coverage). The description's Args section gives clear, meaningful explanations for all five parameters, including explicit value ranges for rsi_range ('oversold' <30, etc.). This fully compensates for the lack of schema 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 states it is a 'Smart volume + technical analysis combination scanner,' which clearly identifies the tool's action (scanning) and resource (volume/technical data). It distinguishes from siblings like 'volume_breakout_scanner' by explicitly mentioning technical analysis (RSI, price change), though it doesn't name alternatives directly.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only lists parameters and return behavior, leaving the agent to infer usage from the tool name and parameter semantics. There are no explicit exclusions or scenario recommendations.

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, but the description goes far beyond: explains the most recent valid print per session window, null behavior for post_market during regular hours, weekend/holiday behavior, and computed % changes. This gives agents a precise mental model of the tool's behavior 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?

Well-structured with a purpose statement, usage context, behavioral notes, and a clear Returns bullet list. No wasted sentences; every part adds value and the text is front-loaded with the most important info.

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 is thorough for a one-parameter tool with no output schema. It documents return fields, null handling, session windows, and holiday behavior. It fully covers what an agent needs to know to invoke and interpret results correctly.

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

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

With 0% schema description coverage, the description compensates by explaining the symbol parameter with examples (AAPL, NVDA, TSLA, SPY, ^GSPC) and limiting to US symbols. It does not exhaustively cover edge cases like crypto or international formats, but for this simple param it is adequate.

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

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

The description opens with a specific verb+resource: 'Real-time pre-market and after-hours prices for a US stock symbol.' This clearly distinguishes it from sibling tools like yahoo_price or stock_prices, which likely focus on regular hours. Use-case examples further cement its purpose.

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

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

Explicitly tells when to use: 'when the user asks about a stock outside the regular 9:30am-4pm ET session' with concrete scenarios. It implies not to use for regular hours but does not name alternate tools directly. Clear context, but lacks explicit 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 declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral detail: the nearest-expiry default, error handling when expiry doesn't match, and a full return structure breakdown. 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?

Well-structured with clearly labeled sections (Args, Returns). The purpose is front-loaded, and every sentence adds value—no filler. Length is justified by the tool's complexity.

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

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

With no output schema, the description provides a comprehensive return shape including underlying price, expiry handling, counts, and detailed option fields. This makes the tool fully actionable for an agent without additional lookups.

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

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

Schema description coverage is 0%, but the description fully compensates with an Args section explaining symbol (with examples) and expiry (ISO format, must match available_expiries). This is exactly the needed semantics 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 opens with a specific verb and resource: 'Full options chain (calls + puts) for a US stock symbol and one expiry.' This clearly differentiates from siblings like stock_options_unusual_activity, which focuses on unusual activity rather than the full chain.

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

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

Explicitly states when to use with concrete examples ('when the user asks...') and provides fallback behavior for missing expiry. While it doesn't name alternatives, the context is strong enough to guide selection among siblings.

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

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

Annotations already mark this as read-only and non-destructive. The description goes well beyond by detailing the scan behavior: 'Scans the soonest few expirations, filters out illiquid strikes (under min_volume), and returns the top-N sorted by V/OI descending.' It also explains the V/OI interpretation and aggregate bias, offering rich operational context.

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

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

The description is longer than a single sentence but is well-structured into a summary line, usage context, and Args/Returns sections. Every sentence adds value, though the V/OI interpretation paragraph could be seen as slightly verbose for a tool description.

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

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

With no output schema, the Returns section exhaustively lists all fields returned, including the nested unusual contracts structure. Combined with parameter documentation, usage guidance, and algorithmic explanation, the description fully equips an agent to invoke the tool and interpret results.

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

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

The input schema contains only titles and defaults, with zero description coverage. The description's Args section fully documents all four parameters, including examples (symbol: AAPL, NVDA) and semantics (min_volume prevents noise, expiries covers weeklies + monthlies), effectively compensating for the schema gap.

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

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

The description opens with a clear, specific statement: 'Top strikes by volume / open-interest ratio — institutional positioning signal.' It then lists concrete user intents ('any unusual options activity on X?', 'where is the smart money positioned on NVDA before earnings?'), which sharply distinguishes it from siblings like stock_options_chain, volume_breakout_scanner, and smart_volume_scanner.

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

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

Provides explicit when-to-use scenarios and explains the V/OI screening logic. It does not explicitly state when not to use it or name alternatives, but the user-intent examples and the clear focus on unusual activity effectively guide selection.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds meaningful transparency by detailing the return envelope structure (fields like price, open, high, low, change_percent) and the not_found list behavior. It also mentions the single upstream request at full size, which is useful operational context.

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

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

The description is efficiently structured with clear 'Args' and 'Returns' sections. Every sentence provides necessary information: the core purpose, param format, constraints, and return shape. 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?

Despite lacking an output schema, the description fully documents the return envelope (fields listed) and error/edge-case behavior (not_found list). It also covers the key usage constraints, making it complete for a simple read-only data retrieval tool with strong annotations.

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

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

The input schema has 0% description coverage, but the description fully compensates by specifying the parameter format (comma-separated EXCHANGE:SYMBOL), providing a concrete example ('NASDAQ:NVDA, NASDAQ:TSLA, KRX:005930'), and noting the max length (2000). It also explains why the exchange prefix is necessary.

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

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

The description clearly states the tool's function: 'Current price + daily % change for specific stock symbols.' It uses a specific verb ('Current price') and identifies the resource ('specific stock symbols'), distinguishing it from broader market overview tools like market_snapshot or egx_market_overview.

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

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

The description provides clear usage context: it requires a specific EXCHANGE:SYMBOL format, mentions the maximum of 2000 tickers, and explains that the exchange prefix is required. It does not explicitly name alternative tools or exclusions, but the context is sufficiently clear for an agent to decide when to use it.

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

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

Annotations already convey a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds substantial behavioral detail: limit is capped at 2000 with a single upstream request, sort_by applies server-side over the entire market, exclude_otc affects venue interpretation for 'america,' compact mode reduces payload, and returns include total_matches and local-currency pricing with daily bar semantics. This goes well beyond structured annotation info.

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

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

The description is well-organized into Args and Returns sections, with each parameter explained in a single dense line. The purpose sentence is front-loaded, and every sentence adds meaningful detail without filler. Minor redundancy (market-cap ranking mentioned twice) doesn't distract.

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

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

With no output schema, the description fully specifies the return envelope (total_matches, returned, rows), row fields, and price/currency semantics, including daily bar definitions. It also covers constraints like the 2000-row upstream limit and OTC exclusion behavior, making the tool's behavior predictable. Despite the lack of error/rate-limit info, the core context is complete.

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

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

The schema provides zero descriptions for all six parameters, so the description carries full burden. It explains each parameter with examples (country list), options (stock_type, sort_by), defaults, and behavioral effects (exclude_otc, compact). This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Screen stocks by share type,' positioning it as the API twin of TradingView's common/preferred stock filter. It clearly distinguishes this global screener from sibling tools like egx_stock_screener or top_gainers by emphasizing share-type filtering across multiple markets and market-cap ranking.

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 for when to invoke this tool—when common/preferred stock screening across countries is needed, especially with sort_by whole-market semantics like dividend yield or price. It does not explicitly name alternative tools or exclusionary conditions, but the purpose and parameter details make the intended use obvious.

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 destructiveHint. The description adds valuable behavioral context: the Bollinger Band analysis methodology, the structured error envelope on failure, and a guarantee of never throwing a raw exception string. This goes 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 well-organized with an opening sentence followed by Args and Returns sections. It is concise, front-loaded, and every sentence provides useful information without redundancy.

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

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

The tool has only 3 parameters, all fully documented in the description. Return values and error behavior are also specified. The description is complete for effective use, even with an output schema 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?

The schema has no parameter descriptions (0% coverage), but the description compensates fully by documenting each parameter: valid exchange values, valid timeframes, and the limit maximum. This is complete and adds meaning far 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 the tool's function: 'Return top gainers for an exchange and timeframe using Bollinger Band analysis.' This specifies a concrete verb, resource, and methodology, distinguishing it from sibling tools like top_losers.

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 purpose implies when to use (screening top gainers), but there is no explicit guidance on when not to use it or which alternative might be better suited. With many sibling screener tools, explicit differentiation would strengthen this dimension.

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 destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: returns list[dict] on success and a structured error envelope on any failure, which is 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 and front-loaded with the core purpose in the first sentence, followed by a compact return type and error envelope specification. Every sentence provides value 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?

The tool is a simple 3-parameter screener with an output schema (not shown but referenced). The description covers the main functionality, supported markets, return type, and error handling. It lacks specification of how 'losers' are calculated, but this is likely domain-standard and the output schema handles return details.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by enumerating supported exchange values (KUCOIN, BINANCE, MEXC, EGX, BIST, NASDAQ), but it does not explain 'limit' or possible 'timeframe' values beyond the default '15m'. This is helpful but incomplete for 3 parameters.

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

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

The description clearly states the tool returns top losers for a given exchange and timeframe, with a specific verb ('Return') and resource ('top losers'). It also lists supported exchanges, distinguishing it from sibling tools like top_gainers.

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 screening losers) and lists supported exchanges, but it does not explicitly state when to use this tool versus alternatives or provide any exclusionary guidance. No explicit when/when-not conditions 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?

The annotations (readOnlyHint, openWorldHint, destructiveHint) already establish the tool as a safe, read-only scanner. The description adds valuable context about return behavior: the empty list means 'no matches today', error envelopes for total upstream failure, and explicit treatment of rate-limit cliffs. This goes beyond the annotations and provides meaningful behavioral disclosure.

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

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

The description is logically structured: a one-line summary, parameter explanations, and a return-value note. It is concise without being truncated, but the parameters section slightly duplicates schema defaults (e.g., default 2.0) which is not strictly necessary. Still, it remains efficient and easy to scan.

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

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

The description covers the tool's purpose, all parameters, output format, and error handling. Given the 5 parameters, zero required fields, and the presence of an output schema (which likely documents return fields), the description is sufficiently complete. It could add a note about crypto-only applicability, 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 description coverage is 0%, so the description carries the full burden of explaining parameters. It provides detailed semantics for every parameter: exchange examples (KUCOIN, BINANCE), timeframe options, clear definitions for volume_multiplier ('How many times'), price_change_min ('Minimum price change percentage'), and a max constraint for limit. This fully compensates for the lack of schema 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 tool's function with a specific verb and resource: 'Detect coins with volume breakout + price breakout.' It is clear and unambiguous, but it does not explicitly differentiate from sibling tools like smart_volume_scanner or volume_confirmation_analysis, which may overlap in purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like 'use for screening coins' or explicitly exclude other scanners. The usage context is only implied through the parameter descriptions, but no explicit recommendations or exclusions are 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 declare readOnlyHint=true and destructiveHint=false, but the description adds no additional behavioral context such as output format, data sources, or limitations. It remains a bare statement with no disclosure beyond the purpose.

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 a front-loaded purpose sentence followed by a clearly labeled Args block. Every sentence contributes value, though the sparseness leaves some aspects under-specified.

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

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

With no output schema and many sibling tools, the description fails to explain what the analysis returns or when to choose it over similar scanners. It is adequate for basic parameter understanding but lacks critical context for an agent to confidently 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?

The description compensates for the 0% schema coverage by explaining each parameter: symbol as a coin symbol with an example (BTCUSDT), exchange as an exchange name, and timeframe as a time frame. This adds baseline meaning, but it omits accepted values or formats (e.g., exchange defaults, timeframe notation).

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 performs 'Detailed volume confirmation analysis for a specific coin,' indicating a focused analysis tool. However, it does not differentiate from sibling tools like volume_breakout_scanner or smart_volume_scanner, so it lacks explicit sibling 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 provides no guidance on when to use this tool versus alternatives. It only mentions the scope ('for a specific coin') but does not state when volume confirmation is needed or when other scanners 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 destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations, such as the unsupported strategies due to SMA200 warmup exceeding typical fold size, the n_splits max of 10, and the per-fold capital semantics. It does not contradict annotations.

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

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

The description is front-loaded with a one-sentence purpose, followed by a tightly organized Args list. Every line provides operational value—no fluff or redundant information. It is appropriately sized for the parameter count.

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

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

Given the tool's complexity (9 parameters, no output schema), the description is complete: it covers purpose, usage constraints, alternative tools, and all parameter semantics. An agent can correctly select and invoke the tool based solely on this description.

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

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

The input schema has 0% description coverage, but the description thoroughly documents all 9 parameters: symbol format, allowed strategy values, period options with a recommendation, defaults, and constraints. It adds meaning beyond bare names, including units, max values, and per-fold context.

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: 'Walk-forward backtest to detect overfitting — validates strategy on unseen data.' This uses a specific verb and resource, and distinguishes it from sibling tools like backtest_strategy by emphasizing the walk-forward methodology and overfitting 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 provides explicit usage guidance, including which strategies are not supported (rsi_pullback, triple_ema) and directs users to an alternative: 'use run_backtest with period="2y"'. It also recommends '2y' for the period parameter, giving clear context for when to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds asset-class coverage and mentions 'real-time,' but doesn't disclose output format, latency, or rate limits. For a simple read-only tool, this is adequate but not enriched.

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 extremely concise: one sentence for purpose and one for parameters. It is front-loaded with the core action and includes only essential details, with no unnecessary 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?

Given the tool's simplicity (one required parameter, clear annotations), the description is nearly complete. It covers symbol syntax and asset types. The only minor gap is the lack of return-format details, but since this is a simple quote tool, the description is sufficient 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?

The schema provides only the parameter name 'symbol' with no description (0% coverage). The description compensates with a dedicated Args section that explains the symbol format and provides concrete examples (AAPL, BTC-USD, ^GSPC, THYAO.IS), giving the agent actionable guidance beyond the schema.

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

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

The description clearly states the tool's function: 'Real-time price quote from Yahoo Finance for any stock, crypto, ETF or index.' It uses a specific verb ('quote') and resource ('Yahoo Finance symbol'), and explicitly lists supported asset classes, making it distinct from historical data tools like stock_prices.

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

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

The phrase 'Real-time price quote' provides clear context for when to use the tool (immediate pricing needs). It doesn't explicitly mention when not to use it or name alternatives, so it falls short of a 5. However, the usage scenario is unambiguous.

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