TradingMCP

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds little beyond that: it does not say what a 'pattern' result looks like, whether it scans the whole market or a specific symbol, or how the multi-timeframe claim is realized when only base_timeframe is a parameter. With annotations doing the safety work, this is a thin contribution.

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 purpose sentence is correctly front-loaded and the Args block is compact, but it is a raw docstring dump with no structure around the most decision-relevant information. Nothing is wasted outright, yet the format does not prioritize the scoping and symbol-selection facts an agent needs first.

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

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

For a five-parameter, default-everything, no-output-schema tool, key facts are missing: there is no symbol parameter, so it is unclear what universe is scanned; 'multi-timeframe' is promised while only base_timeframe exists, which is a possible conceptual inconsistency; and the described return shape ('number of results') is never explained. The defaults are also never surfaced in the text, so an agent may not realize it can call this with no arguments.

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, and it does list all five parameters with meaning: exchange (with examples BINANCE, KUCOIN), base_timeframe (with values 5m/15m/1h/4h), pattern_length (range 2-4), min_size_increase, and limit. This compensates well, though min_size_increase as 'minimum percentage increase in candle size' leaves units and baseline ambiguous (percent of prior candle? of average?).

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 opening sentence names a resource ('candle pattern analysis') and a data scope ('multi-timeframe'), but 'advanced' is an empty qualifier and nothing distinguishes it from siblings like consecutive_candles_scan or multi_timeframe_analysis, which plausibly do overlapping work. An agent cannot tell from this text which of those three to pick.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative. The Args block is a parameter enumeration, not usage guidance. The agent must infer the use case (pattern scanning) and the routing against sibling scanners entirely on its own.

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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds meaningful behavior beyond that: the result is rendered inline as an interactive chart, the specific outputs produced (equity curve, drawdown, return/win-rate/Sharpe), and a fallback `summary` field for non-interactive clients.

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

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

Front-loaded with the verb and outcome, then the necessary enumerations. The strategy list is long but earns its place because the schema carries no enums; only the client-fallback sentence feels slightly bolted on.

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

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

With readOnly annotations covering safety and no output schema, the description does the heavy lifting by describing what is returned (chart, stats, summary fallback). It is close to complete; gaps are symbol format, initial_capital semantics, and any determinism/latency notes.

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 and largely does: it enumerates all nine strategy values plus valid period and interval values, none of which the schema exposes as enums. It leaves `symbol` format and the `initial_capital` parameter (default 10000) unexplained, so it is strong but not complete.

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

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

The description states a specific verb and resource ('Run a strategy backtest and render its equity curve as an interactive chart') and even names the visual outputs (capital growth, drawdown, stats). It implicitly distinguishes itself from backtest_strategy by promising an interactive chart, but it never names that sibling, so the differentiation is left to inference.

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

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

There is one concrete usage cue — clients without interactive app support should read the `summary` field — which is a genuine routing hint. However, it never says when to prefer this over backtest_strategy, walk_forward_backtest_strategy, or compare_strategies, nor any exclusions or prerequisites.

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, so the safety profile is covered. The description adds real behavioral context beyond that: the SMA200 warmup constraint for two strategies and the fact that trade log and equity curve payloads are opt-in (default False). It does not disclose cost/rate behavior or what 'institutional-grade metrics' actually contains.

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 one-sentence purpose is front-loaded before the structured Args block, and every arg line earns its place by adding format or default detail absent from the schema. It is on the long side, and the defaults duplicated from the schema could be trimmed, but there is little waste.

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

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

With 9 parameters and no output schema, the description covers inputs thoroughly but leaves the return shape vague ('institutional-grade metrics') and gives no guidance on selecting this versus compare_strategies or walk_forward_backtest_strategy. Adequate for invocation, thin for deciding whether this is the right backtest tool.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it delivers: symbol format examples (AAPL, BTC-USD, THYAO.IS, ^GSPC), the full strategy list, allowed period and interval values, and the unit/meaning of each numeric default (USD capital, per-trade commission %, slippage %). Enum-like allowed values are supplied nowhere else, so this is essential compensation.

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

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

States a specific verb and resource ('Backtest a trading strategy on historical data') plus an output quality signal ('institutional-grade metrics'). An agent can tell it apart from adjacent tools like backtest_chart or simple scanners, but the description never explicitly contrasts itself with siblings such as compare_strategies or walk_forward_backtest_strategy.

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?

Usage is implied rather than stated: the reader infers this is the single-strategy backtest tool, but there is no explicit when-to-use/when-not, and no routing to siblings like compare_strategies or walk_forward_backtest_strategy. One genuine conditional is provided (rsi_pullback and triple_ema require period >= '1y'), which is a concrete usage constraint.

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, destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the exact return shape and the enumeration of assessment labels (HIGH_RISK / ALT_RISK / ALT_FAVORABLE / OPPORTUNITY_WITH_CAUTION / NEUTRAL), which tells the agent what interpretation it will get back. No data-freshness or latency caveats are given.

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

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

Front-loaded with the core purpose in the first sentence, then usage, then a structured returns list. Slightly verbose in the mid-paragraph ('Calling this once gives Claude the macro context to provide Bitcoin-aware commentary...'), which restates the already-clear value proposition, but nothing is truly wasted.

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

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

With no parameters and no output schema, the description carries the full burden, and it does so: it names each returned field group (bitcoin, dominance, total_market, assessment) and describes the assessment reasoning. An agent can call this correctly and interpret the result without any further 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no inputs are needed ('Single-call... in one shot').

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

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

States a specific verb+resource ('Single-call BTC macro context: price, dominance, total market cap + risk assessment') and enumerates exactly what it aggregates. It is clearly distinguishable from siblings like yahoo_price or coin_analysis, which cover single symbols rather than the aggregate market frame.

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

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

Gives explicit trigger guidance ('Use this WHENEVER analyzing any cryptocurrency...'), including the altcoin case, and names the alternative workflow it replaces ('without chaining 2-3 separate yahoo_price + manual reasoning calls'). It stops short of stating when NOT to use it or where a sibling (e.g. coin_analysis) is preferred instead.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing the failure contract: a structured error envelope `{error: {code, retryable}}` on ANY failure. It does not cover pagination or ordering, but that is minor given the output schema.

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

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

Front-loaded with the core purpose in one sentence, then routing guidance, then the example, then a compact Args block. The long exchange list is dense but earns its place given zero schema coverage. The aside about the canonical tool name is mildly defensive but prevents a realistic hallucination.

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 4-parameter, zero-schema-coverage scan tool this is complete: purpose, routing, valid enum values, sensible defaults, error behavior, and return type are all present. An output schema exists, so return-value detail beyond `list[dict]` is not required.

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 parameter burden and does it well: it enumerates valid crypto and stock exchanges, lists the exact timeframe enum, supplies per-timeframe squeeze thresholds, states the bbw_threshold default and the limit cap (max 100). This is meaningfully richer than the bare schema 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?

States a specific verb and resource — scan a whole exchange for assets with low Bollinger Band Width — and explicitly scopes it as exchange-wide rather than per-symbol by naming `coin_analysis` as the single-symbol alternative. An agent can distinguish it from siblings like `coin_analysis` or `volume_breakout_scanner` without opening a schema.

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

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

Gives an explicit when-to-use (`scan a whole EXCHANGE`), an explicit when-not-to (`for the Bollinger read of ONE symbol, call coin_analysis instead`), and a concrete invocation example with filled arguments. It even pre-empts a likely hallucinated alternative tool name.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds one genuinely useful behavioral detail — the error's `listed_on` field for unsupported exchange/symbol pairs — but gives no sense of latency, rate limits, or result depth beyond a one-line 'all indicators and metrics'.

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?

Purpose, sibling disambiguation, and example are front-loaded in the first three sentences, which is the right structure. The exhaustive exchange roster is long and partly duplicative of the documented `listed_on` error field, so some tail text does not fully earn its place.

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

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

No output schema exists, and 'detailed analysis with all indicators and metrics' is thin for a tool whose entire value is the readout, so return shape is underspecified. Everything needed to invoke it correctly — symbol format, exchange, timeframe, error fallback — is present.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does add real value: bare-ticker format with per-exchange examples (EGX, BIST, SSE, TWSE…), an enumerated exchange list, and allowed timeframe values. However, the exchange enumeration is a flat prose dump rather than stating which symbol forms pair with which exchange, and the schema itself has no enums to cross-check.

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

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

States a specific verb+resource+scope ('detailed analysis for a specific asset (coin or stock) on specified exchange and timeframe') and explicitly differentiates itself by declaring it is the canonical single-symbol readout and naming the siblings it is not.

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 routes the agent: use `multi_timeframe_analysis` for trend alignment across timeframes and `combined_analysis` when news sentiment is also wanted, plus a worked call example. This is the when/when-not/alternative pattern in full.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds relative-cost context ('coin_analysis is faster'), implying this composite call is heavier, but it says nothing about latency, rate limits, or partial-failure behavior when one data source is unavailable. Adequate given annotations, 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?

Front-loaded with purpose, then usage routing, then a concrete call example, then Args. Every block earns its place. Minor waste in the 'POWER TOOL' framing and slight duplication of the title, but overall tight and well ordered.

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

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

With no output schema, the description still names the three output components the agent will receive (TA, sentiment, news), which is enough to know the return shape at a high level. It lacks detail on result structure or how the three sections are combined, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: symbol is a bare ticker with no exchange prefix (with concrete examples like 'THYAO', 'GDX'), plus enumerated exchange and timeframe values that the schema omits entirely. It does not clarify default behavior (exchange defaults to NASDAQ, timeframe to 1D) or what happens on an unsupported exchange/timeframe pair.

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

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

States a specific composite resource (TradingView technical analysis + news sentiment + financial news) and its scope: one symbol in a single call. It explicitly differentiates from siblings by naming coin_analysis and multi_timeframe_analysis and distinguishing what each covers.

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 it ('when you want TA AND sentiment AND news for one symbol in a single call') and routes to alternatives with the condition that selects them: coin_analysis for indicators only (faster), multi_timeframe_analysis for cross-timeframe trend alignment. No inference required.

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, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds genuine behavioral context beyond that: it runs a fixed set of 9 strategies and discloses a non-obvious warmup side effect (strategies silently yield zero trades on short periods). Return metric composition is still unstated.

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

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

The purpose sentence is front-loaded and tight. The args block is somewhat list-like, but given 0% schema coverage it is necessary rather than redundant. No wasted prose.

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 four-parameter tool with no output schema, the description covers invocation fully, including defaults and the warmup pitfall. What it does not describe is what the ranked leaderboard actually contains (which metrics, sort key), leaving the agent to infer the return shape.

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

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

Schema description coverage is 0%, so the description must carry the full burden — and it does, documenting all four parameters with types, examples (AAPL, BTC-USD, SPY), enumerated values for period and interval, and the $10,000 default. The warmup caveat ties a parameter value to a concrete outcome.

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

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

States a specific verb and resource ('Run all 9 strategies') and enumerates every strategy by name, then declares the output ('ranked leaderboard'). The comparison scope is inherently distinct from single-strategy siblings like backtest_strategy or walk_forward_backtest_strategy.

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

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

Gives real contextual guidance — 'period >= 1y recommended so rsi_pullback and triple_ema can complete SMA200 warmup; otherwise they contribute zero trades' — which steers correct invocation. It stops short of naming an alternative or an explicit when-not-to-use condition versus the sibling backtest 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered by structured fields. The description adds no extra behavioral context such as data source, latency, rate limits, result ordering, or how the pattern is evaluated, so it contributes nothing beyond the annotations for a network-scanning tool.

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

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

The pattern definition is front-loaded in the first sentence and the rest is an orderly args list with no filler sentences. The Args block partially duplicates schema field names, but it remains compact and scannable rather than padded.

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

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

With 6 parameters, no output schema, and no annotation elaboration of results, the definition should say more about what the scan returns (order, fields, count semantics) and how min_growth is measured. It is adequate to invoke the tool but leaves real gaps for correct interpretation of 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?

Schema description coverage is 0%, so the description carries the full parameter burden, and it does document all six parameters with meaning: pattern_type is disambiguated ('bullish' = growing, 'bearish' = shrinking), candle_count range (2-5) is given, and exchange/timeframe examples (BINANCE, KUCOIN; 5m, 15m, 1h, 4h) are supplied. It falls short of a 5 because min_growth's unit/format and limit's behavior are not fully clarified.

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

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

States a specific verb ('Scan for coins') and a concrete pattern resource ('consecutive growing/shrinking candles'), which is clear and actionable. It does not, however, distinguish itself from sibling scanners like advanced_candle_pattern or bollinger_scan, so an agent cannot tell when this is the right scanner versus another.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling scanners. It describes what parameters exist but never tells the agent under what market conditions or intent this tool should be selected.

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, destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that: no indication of data recency, latency, whether the swing high/low is computed from adjusted prices, or what happens for thin/illiquid EGX symbols.

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

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

One front-loaded purpose sentence followed by a compact Args block; no filler. The formatting is functional but the args are documentation-by-list rather than prose that explains the parameters' behavior.

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

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

No output schema exists, so the description should say what the analysis actually returns — retracement levels, ratios, entry/exit zones, or a chart reference — and it does not. For a 3-parameter analytical tool surrounded by overlapping EGX tools, the definition is minimally viable but leaves the agent guessing about output shape and tool selection.

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

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

Schema coverage is 0% and enums are absent, so the description is the only source for allowed values — and it delivers: symbol examples ("COMI", "TMGH", "FWRY"), the five valid lookback tokens plus the 52W default, and the seven timeframe tokens plus the 1D default. It stops short of explaining how lookback and timeframe interact (e.g., a 1D timeframe inside a 1M lookback), which is a meaningful gap for an analysis window parameter pair.

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

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

States a specific analysis type (Fibonacci retracement) scoped to a specific market (EGX stocks), which separates it from the crypto/futures/US siblings in the list. It does not, however, distinguish itself from other EGX analytical tools such as egx_trade_plan or egx_index_analysis, which may overlap in technique.

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 when-to-use guidance, no exclusions, and no pointer to any alternative tool. An agent cannot tell from this text whether to reach for this tool or for egx_trade_plan / multi_timeframe_analysis when a user asks about support levels.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a little behavioral context by indicating the response covers constituent performance with indicators, but says nothing about data freshness, rate limits, or what 'full indicators' concretely includes.

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

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

One lead sentence stating the purpose, then a compact argument block covering all three parameters. Every line carries information and nothing is padded.

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

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

With no output schema, the description must imply the return shape, and 'constituent performance with full indicators' is vague about structure and size. For an open-world analysis tool with zero required parameters, the definition is workable but leaves the response format underspecified.

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% and the schema exposes no enums, so the description carries the full burden — and it largely does, enumerating all six valid index names, all eight valid timeframes, and the limit cap of 100 with its meaning ('stocks to show in detail'). It only omits restating the index/limit defaults that the schema already provides.

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

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

States a specific verb and resource ('Analyse an EGX index') plus the scope of the output ('constituent performance with full indicators'). It is distinguishable from broad siblings like egx_market_overview or egx_stock_screener by its index-level focus, though it never explicitly contrasts itself with them.

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?

There is no guidance on when to choose this tool over egx_market_overview, egx_sector_scan, or egx_fibonacci_retracement, nor any stated prerequisites. The 'Args' block supplies accepted values but that is parameter syntax, not usage context.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false). The description adds a small behavioral nuance — that the default timeframe of 1D applies specifically to stocks — but says nothing about what the 'categories' are, whether data is delayed, or how results are scoped. With annotations carrying the safety burden, a 3 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?

Purpose sentence is front-loaded, followed by a compact Args block. No redundant restatement of the title or filler. Slightly raw docstring formatting, but every line earns its place.

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

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

For a read-only overview tool with no output schema, the description should convey what the overview contains — it mentions 'category' and 'stocks per category' but never names or characterizes those categories. Enough to invoke correctly, not enough to know what comes back or how it differs from market_snapshot.

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% and there are no enums, so the description carries the full parameter burden — and it largely does: it enumerates all seven timeframe values (5m through 1M) and caps limit at 20 stocks per category. Minor gaps remain (what happens above 20, whether the timeframe enum is validated) but this is meaningful compensation.

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

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

States a specific verb ('Get a comprehensive overview') and resource (Egyptian Exchange market), which is clearly broader in scope than siblings like egx_index_analysis or egx_sector_scan. It stops short of explicitly naming those narrower siblings, so it's clear but not maximally differentiated.

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

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

The description only documents arguments; it never says when to reach for this tool versus egx_index_analysis, egx_sector_scan, egx_sector_scanner, or market_snapshot. No prerequisites, no exclusions, no routing guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact (it lists all sectors when the sector arg is empty) and the hard cap of 50 per sector, but says nothing about rate limits, pagination, or ordering.

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

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

The scoping sentence is front-loaded and the docstring-style Args block is easy to parse. There is mild redundancy between 'Shows available sectors if none specified' and 'Leave empty to list all sectors', which says the same thing twice.

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 should hint at what a 'scan' actually returns (candles, indicators, ranked symbols?), but it never does. Parameters are fully covered, yet the return shape and sibling differentiation are missing, leaving real gaps for a scan tool.

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

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

Schema description coverage is 0% and no enums are declared in the schema, so the description carries the full burden. It compensates well by listing example sector keys, enumerating all valid timeframe values, and stating the max of 50 for limit.

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

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

The first sentence states a specific verb and resource ('Scan EGX stocks by sector') and names the exchange, so the agent knows exactly what operation this performs. However, it never distinguishes itself from the near-identically named sibling egx_sector_scanner, which an agent could easily confuse it with.

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?

'Shows available sectors if none specified' hints at the empty-input mode, but the description gives no when-to-use guidance relative to the many sibling scanners (egx_sector_scanner, egx_stock_screener, egx_market_overview). Usage is only implied, not contrasted against alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety and data-source profile is covered. The description adds that output ranks sectors and filters stocks by a score, but discloses nothing about return shape, latency, or that all parameters are optional. Adequate but not rich.

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

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

The purpose is front-loaded in the first sentence, followed by a compact Args block with no filler. The format is slightly mechanical (Python docstring style) but every line earns its place.

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

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

No output schema exists, so the description should clarify what comes back; it only loosely says 'hot/cold sectors and top picks' without describing the ranking or score fields. Given four parameters and no return documentation, an agent has enough to call it but not to interpret results confidently.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: it lists the full timeframe enum (5m–1M), numeric ranges for all three count/score params, and defaults. This is meaningfully more than the bare schema, which only supplies titles and 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?

States a specific verb+resource ('Sector rotation scanner for EGX') and the outcome ('identifies hot/cold sectors and top picks'). However, it never distinguishes itself from the sibling egx_sector_scan, which an agent could easily confuse with it.

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?

There is no when-to-use, when-not, or alternative guidance. The description only states what the tool does, leaving the agent to infer its role relative to egx_sector_scan and egx_market_overview without any explicit routing cues.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world). The description adds real behavioral value: bounded thread pool, the fact that unservable rows go to `skipped` and are 'never silently dropped,' and what is attached per row. This is meaningful disclosure beyond the annotations, though nothing is said about latency or rate-limit implications.

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

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

Front-loaded with the one-line purpose, then supporting workflow detail, then a compact args block. Every sentence earns its place; only minor slack in restating defaults that also appear in the schema.

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

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

With no output schema, the description does the needed work by explaining what each returned row contains (volume-flow composite score, banker decomposition, oscillator state) and how failures surface via `skipped`. Complete enough for correct invocation; only the exact ranking/tie-break semantics are unspecified.

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 and does so: it enumerates the index values, gives the default and max for `limit`, the window options for `period`, and the 0-100 range for `min_score`. Without this text the parameters would be opaque.

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

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

States a specific verb and scope: 'Rank EGX index constituents by smart-money accumulation evidence,' which is clearly distinct from the single-symbol smart_money_analysis sibling. It does not explicitly name or route against siblings like smart_volume_scanner, so it stops 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 implies usage by describing the underlying workflow ('runs the full smart_money_analysis per constituent'), so an agent can infer this is a batch/index-level scan rather than a single-symbol call. However, it never states when to choose this over smart_money_analysis or smart_volume_scanner, nor any exclusions or prerequisites.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that this is a 'production' scoring engine with a 0-100 score threshold, which gives useful framing, but says nothing about output shape, result freshness, or rate limits.

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

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

Front-loads purpose in one sentence, then a compact Args block that is easy to scan. Nearly every line earns its place, with only mild padding in the 'actionable setups' phrasing.

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

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

There is no output schema, so the description is the main contract, and it covers all four optional inputs with valid values and defaults. The remaining gap is that it never sketches the returned ranking structure or how scores are derived, which an agent would want for a screener.

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 and largely does: it enumerates timeframe values (5m through 1M), the min_score range and default, the accepted index_filter tokens, and the limit ceiling of 50. It omits the limit default (20 in the schema) and doesn't clarify units for min_score beyond 0-100, so it is strong but not exhaustive.

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

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

States a specific verb+resource: a ranking/screening engine for EGX stocks that surfaces 'strong stocks with actionable setups.' That separates it from the generic stock_screener and from the narrower egx_sector_scanner/egx_smart_money_scanner siblings, though it never names them. 'Strong stocks with actionable setups' is somewhat marketing-flavored rather than precise about the ranking criteria.

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

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

The description explains what the tool does but never says when to reach for it over the many sibling screeners (stock_screener, egx_sector_scanner, egx_smart_money_scanner, rating_filter). There are no exclusions, prerequisites, or comparative guidance, leaving the agent to infer selection from the name alone.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that: it does not say what a 'trade plan' contains, whether it depends on live market data, or any latency/coverage constraints for EGX symbols.

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 purpose sentence is front-loaded and the argument list is compact with zero filler. It is slightly verbose in a docstring style but every line carries information not present in the schema.

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

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

With no output schema, the description should say more about what the generated plan returns (entry, stop, targets, etc.), but it only names the action. Parameter documentation is adequate, so the definition is functional but leaves the return content undefined.

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, and it does document both parameters with symbol examples ('COMI', 'TMGH', 'FWRY') and the full timeframe enum (5m–1M), which the schema omits entirely. It falls short of explaining what the timeframe actually controls.

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

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

The description states a specific verb and resource: 'Generate a full trade plan for a specific EGX stock.' It is clearly distinguishable from most siblings by the 'full trade plan' output, though it never explicitly contrasts with related analysis tools like egx_fibonacci_retracement or multi_timeframe_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?

There is no when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer from the name alone that this is for producing a trade plan rather than raw indicators or screeners.

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, so the safety profile is covered. The description adds that data comes from a licensed external source (Marketaux) and is real-time, which is useful context, but says nothing about rate limits, latency, or result freshness/pagination.

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 one-line purpose is front-loaded and the Args block is terse with no filler. The Python-style docstring formatting is slightly informal but costs no extra 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?

For a read-only, open-world 3-parameter tool with an existing annotation profile and no output schema, the definition covers purpose, source, and all parameters. Missing pagination/limit-behavior details are minor given annotations already establish it as a safe read.

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 carry the burden, and it does: it explains symbol accepts tickers like "AAPL"/"BTC" with None meaning all news, enumerates category values, and clarifies limit as max items. It does not state the default values (10, "stocks") that appear in the schema.

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

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

States a specific verb+resource (financial news retrieval) and names the upstream provider (Marketaux) plus the 'real-time' quality. It is distinguishable from siblings like symbol_mentions or market_sentiment, though it never explicitly contrasts itself with them.

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?

Usage is only implied via the parameter notes ('optional symbol filter', 'None = all news'), which hints at when to filter vs. not. There is no statement of when to prefer this tool over sibling news/sentiment tools, nor any exclusions or prerequisites.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns OHLCV quotes for a 'standard watchlist' of contracts and names example symbols per category. It says nothing about how many contracts are returned, freshness/delay of quotes, or error behavior for an unknown category.

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 purpose sentence is front-loaded and the Args/Returns blocks are compact and scannable. The Returns section spends a little space on example symbols that partially duplicate the enum list in Args, but nothing is padded or redundant enough to be a real cost.

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 present, the description does the right thing by sketching the return shape (OHLCV quotes for a standard contract watchlist) rather than leaving it undefined. Combined with the enumerated category values, an agent has enough to invoke it correctly; counts, quote latency, and failure modes for bad categories remain unstated.

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% and the schema defines no enum for 'category', so the description carries the full burden — and it does: it enumerates all seven valid values (equity_index | energy | metals | agriculture | rates | forex | crypto_futures), meaning without it the agent could not know the accepted vocabulary. It omits the schema's 'energy' default, but that is a minor 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?

States a specific verb ('Quote') and a scoped resource ('all major front-month contracts in a specific futures category'), which separates it from generic siblings like market_snapshot or yahoo_price. It does not explicitly distinguish itself from the close siblings futures_watchlist, futures_top_movers, or futures_market_overview, 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?

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The reader must infer that this is the right call when they want a category-wide quote board rather than a personal watchlist (futures_watchlist) or a ranked list (futures_top_movers).

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, open-world, non-destructive behavior. The description adds valuable return details (total_available count, OHLCV, % change) and notes sorting/filtering behavior, though it omits data freshness or rate limits.

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

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

The description is front-loaded with purpose, then structured into Args and Returns sections. Every sentence earns its place, with no redundant or filler 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?

Given four parameters, no output schema, and annotations covering safety, the description is complete: it explains the tool's purpose, all parameter semantics, and the return structure. The only minor gap is the lack of explicit sibling comparison, which is handled in the usage dimension.

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 must carry the full burden. It does so thoroughly by listing all four parameters with allowed values, defaults, and filtering semantics (e.g., category enums, exchanges options, limit default 30, volume_min 0 = no filter).

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

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

States a clear resource and scope: top futures contracts sorted by trading volume. This sorting criterion implicitly differentiates it from siblings like futures_top_movers, but no sibling is named explicitly.

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

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

Provides detailed parameter options for filtering, effectively implying how to use the tool (e.g., by category or exchange). However, it offers no explicit guidance on when to choose this tool over alternatives such as futures_top_movers or futures_category_snapshot, nor any 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, destructiveHint=false and openWorldHint, so safety is covered. The description adds non-obvious behavior: volume_min defaults to 10 and specifically exists to filter illiquid contracts, and results are ranked by % change and carry OHLCV data. That is meaningful 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 core purpose is front-loaded in one sentence, followed by a tight Args/Returns block with no filler. Structure is functional and scannable, though the docstring formatting is slightly verbose for a 4-parameter tool.

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

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

There is no output schema, so the description correctly notes the return shape (list ranked by % change with OHLCV data). Combined with full parameter coverage and clear annotations, an agent has what it needs to call this tool correctly; only cross-tool routing is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it documents all four parameters. Critically it supplies the allowed values (gainers|losers, us|global) that the schema lacks, plus the meaning of the volume_min default; only minor format details are absent.

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

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

The first sentence states a specific resource and scope: futures contracts with the biggest percentage moves today. The 'futures' qualifier separates it from stock-oriented siblings like top_gainers/top_losers, though it never names an alternative explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, and no routing to siblings such as futures_market_overview, futures_category_snapshot, or futures_watchlist. The parameter list implies a screener use case but the description never states the conditions that select 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data; the description adds the useful fact that the result is a complete, categorized, front-month-only roster. It says nothing about result size, freshness, or whether symbols have associated metadata, so it stays at the annotated baseline rather than enriching it.

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

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

Three short lines: the action and scope first, the enumerated categories second, the follow-up tools third. No filler, and the most decision-relevant content (what it returns) leads.

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

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

There is no output schema, so the description carries the burden of describing the return value, and it does so by naming the seven category buckets an agent will receive. It stops short of specifying the symbol format or item shape, but for a static no-arg reference listing this is close to sufficient.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; the description correctly makes no parameter claims and instead spends its words on the return shape, which is the right allocation.

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

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

States a specific verb and resource ('Return the full categorized list of well-known front-month futures symbols') and enumerates the exact categories returned, which implicitly separates it from the user-owned my_watchlist/watchlist_add family. The only gap is that it never explicitly says 'this is not your personal watchlist', so an agent scanning sibling names must infer the distinction.

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

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

It gives downstream guidance ('Use these symbols with futures_category_snapshot or coin_analysis'), but frames this tool as a source of symbols rather than stating when an agent should call it versus, say, futures_market_overview or my_watchlist. Usage is implied (bootstrap a symbol list) rather than stated with conditions 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 cover the safety profile (readOnlyHint, destructiveHint false, openWorldHint), so the description adds the behaviors the annotations cannot: that the result opens as an interactive dashboard, that row clicks request charts/analysis, and that non-app clients can read the `summary` field. These are material invocation-shaping details beyond structured fields.

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

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

Front-loaded with purpose and triggers before coverage, exclusions, and interaction behavior. Each sentence carries distinct routing or behavioral information; the example utterances earn their space by supporting semantic selection.

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

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

With no parameters and an output schema present, the description need not document returns, yet it still tells the agent how output is surfaced (interactive board, `summary` fallback) and what the board contains. Nothing needed to call the tool correctly is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly adds no parameter guidance, and none is needed since the schema is empty and closed (additionalProperties false).

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

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

Names a specific resource ("the user's live market board") with a clear role statement ("Start here when they ask how the markets are doing in general") and enumerates its contents: watchlist, most-asked symbols, indices, VIX, crypto, commodities, FX. It distinguishes itself from sibling tools by name (market_snapshot, my_watchlist, per-symbol tools), so an agent can route without opening a schema.

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

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

Gives explicit trigger utterances, an explicit exclusion ("Don't also call market_snapshot for the same overview"), a rule for extending with other tools ("add other tools only for what the board doesn't show (futures, news, sectors)"), and a redirect for the single-symbol case. This is as complete a when/when-not/alternatives statement as the dimension allows.

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, so the safety profile is covered. The description adds the useful fact that sentiment comes from a licensed Marketaux source, but gives no return format, scoring range, or rate-limit 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 one-line purpose leads, followed by a compact Args block that spends no words on repetition. Every line is useful and the most important information is front-loaded.

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

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

With no output schema, the description carries the burden of describing the return and does not — an agent cannot tell whether it gets a single score, per-article sentiment, or an aggregate. Parameter and safety coverage are adequate, but the missing output shape leaves a real gap for a sentiment tool.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden and does so well: it gives concrete symbol examples ('AAPL', 'BTC'), the valid category values ('crypto', 'stocks', 'all') that the schemaless enum lacks, and defines limit as max articles to analyse.

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

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

States a specific verb+resource combination ('News sentiment for stocks and crypto') and even names the data provider (Marketaux entity sentiment). It is clear what the tool returns conceptually, but it does not differentiate itself from close siblings like financial_news or symbol_mentions.

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?

There is no explicit guidance on when to use this sentiment tool versus financial_news or symbol_mentions, nor any note on prerequisites or exclusions. Usage 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, openWorldHint=true and destructiveHint=false, covering the safety profile. The description only adds the upstream provider ('Powered by Yahoo Finance'), which is genuinely useful context about freshness/reliability, but it says nothing about quote delay, rate limits, or what a snapshot payload looks like.

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

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

Two short sentences, content front-loaded, zero filler or restatement of the title beyond what adds information. Nothing here could be cut without losing signal.

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 parameterless, no-output-schema read tool the description covers the returned asset classes and the data source, which is most of what an agent needs. It omits only operational details like quote delay or breadth limits, which are secondary for this 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly spends none of its words on inputs.

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

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

The description names the concrete content returned (major indices, top crypto, FX rates, key ETFs) and the data source, so an agent knows exactly what a snapshot contains without opening a schema. However, it does not distinguish itself from close siblings such as markets_dashboard, futures_market_overview, or bitcoin_market_pulse, so the agent must infer which overview to pick.

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?

There is no when-to-use guidance, no statement of exclusions, and no routing to alternatives. With a crowded sibling set of market-overview tools, the absence of any 'use this instead of X when Y' framing is a real gap.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior context by naming the three agent roles and summarizing the output as a debate culminating in a trading decision. It does not disclose latency, cost, or whether the run is synchronous, which matters for a multi-agent call.

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

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

Front-loads the purpose in one sentence, then structured Args/Returns blocks. The argument lists are dense but each entry is genuinely useful given the zero schema coverage, so little is wasted.

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

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

No output schema exists, and the description partially compensates by describing the return as a structured 3-agent debate ending in a trading decision. Combined with the annotation safety profile and thorough parameter documentation, an agent has what it needs, though runtime expectations are unstated.

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 carry the full parameter burden and it does: it gives per-exchange symbol examples (BTCUSDT, COMI, THYAO, 600519), enumerates valid exchanges across crypto and equities, and lists valid timeframe intervals. This is far more than the bare schema provides.

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

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

States a specific verb and resource: 'Run a multi-agent debate (Technical, Sentiment, Risk) for a specific symbol.' The agent composition and target (a symbol) make the operation concrete. It does not name or differentiate from siblings such as combined_analysis or market_sentiment, which keeps it 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?

There is no statement of when to prefer this debate tool over the many overlapping siblings (combined_analysis, multi_timeframe_analysis, market_sentiment). No prerequisites, exclusions, or cost/latency context that would help an agent choose between them.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds useful behavioral context: the exact timeframes analyzed and that the operation is scoped to a single symbol. It does not describe output format or latency, but with annotations carrying the safety profile this is solid.

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

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

Purpose and usage are front-loaded, followed by the canonical-name guard and an example. The Args section duplicates schema content somewhat, but every part (timeframes, routing, param formats) earns its place and the message stays readable.

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 2-parameter read-only analysis tool with no output schema and no nested objects, the description covers purpose, alternatives, parameter formats, and an invocation example. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the full burden and does: it documents the symbol format (bare ticker, no exchange prefix) with concrete crypto and multi-market stock examples, and enumerates the accepted exchange values, none of which appear in the schema. This fully compensates for the coverage 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?

Opens with a specific verb+resource and scope: 'Multi-timeframe alignment analysis (Weekly → Daily → 4H → 1H → 15m)' and 'cross-timeframe trend alignment on ONE symbol'. It explicitly names the sibling tools it is not (coin_analysis, combined_analysis), so an agent can route without opening schemas.

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

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

Provides explicit when-to-use rules and named alternatives: single-timeframe deep dive → coin_analysis, TA + sentiment + news → combined_analysis. The 'ONE symbol' constraint further clarifies fit, leaving nothing to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: by default it issues one batched live-quote request for every symbol, which tells the agent about latency and external-data dependency.

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

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

Three tight sentences, zero filler, and the primary action is front-loaded ahead of the secondary quote-fetching behavior and the routing triggers. Every sentence earns its place.

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

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

With no output schema the description should indicate what comes back; it does say the result includes the list plus live prices and daily % change. It leaves remaining details (pagination, ordering, empty-list behavior) unstated, which is a minor gap for a one-parameter read tool.

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

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

Schema description coverage is 100% for the single include_quotes parameter, so the schema already documents type and default. The description restates the default behavior in prose but adds no usage nuance (e.g., when to set it false to skip the quote fetch). Baseline 3 applies.

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

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

Specific verb+resource ("Show the user's personal watchlist") with an explicit scope statement about what else it fetches (live prices + daily % change). It is clearly distinguishable from watchlist_add, watchlist_remove, and futures_watchlist, which are a different operation and a different asset class.

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

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

Gives explicit user-phrase triggers ("my watchlist", "my list", "my coins/stocks") plus a routing instruction ("Start here"), which is strong positive guidance. It stops short of naming when-not conditions or pointing to the sibling tools (watchlist_add / watchlist_remove) that handle the non-read variants.

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

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: 15m charts auto-adjust longer periods to 5d and cap at 350 bars, bollinger overlays SMA20 ± 2σ and returns band values, and clients lacking interactive app support can fall back to the result's `summary` field. These are real behavioral traits (limits, fallbacks, output side-effects) that an agent cannot get from structured fields.

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

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

A single dense paragraph that front-loads the core action before moving to symbol types, parameters, and fallbacks. Every clause carries information, though the run-on format with inline value lists could be structured more scannably.

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 4-parameter tool with no output schema and no schema descriptions, the definition covers the important ground: what is rendered, symbol formats, parameter values, chart limits, and what the result contains. It is close to complete, with only the period/interval value inconsistency and lack of sibling routing as notable gaps.

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

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

With 0% schema description coverage, the description carries the full burden and mostly succeeds: it enumerates period values, interval values, explains the bollinger flag and its effect, and gives symbol format examples. One gap is that `5d` is presented as valid for 15m charts but is absent from the stated period list, leaving a minor inconsistency for the agent to resolve.

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

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

The description names a specific verb and resource ('Render an interactive candlestick chart for a symbol') and clarifies accepted symbol types (crypto pairs, stocks, Yahoo Finance symbols). It is clearly a visualization tool, distinguishable in kind from scanner/analysis siblings, though it never explicitly names an alternative such as yahoo_price or backtest_chart.

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?

Usage is implied through parameter context (period/interval combos, when 15m is appropriate), but there is no explicit 'use this when' guidance or routing against siblings that also surface price data (yahoo_price, stock_prices). An agent must infer that this is the charting option rather than a data-retrieval one.

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

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

Annotations already establish that this is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds value beyond them by disclosing the return contract and, notably, the structured error envelope with a 'retryable' flag, which tells the agent how to react to failure. It stops short of describing pagination or result ordering.

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

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

The one-line purpose is front-loaded, followed by a tight parameter list and a return note. It is close to minimal for the information conveyed, though the docstring-style 'Args:'/'Returns' formatting is slightly verbose.

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

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

With an output schema present, the description needn't detail return values, yet it still adds the error-envelope contract as a useful bonus, and all four parameters are documented. The one real gap is usage context – when to prefer this over sibling scanners.

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 and does so well: it names example exchanges, enumerates the valid timeframes, maps the -3..+3 rating scale to semantic labels, and states the max row limit of 50. This adds substantial meaning beyond the bare typed schema.

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

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

The description states a specific verb and resource: 'Filter coins by Bollinger Band rating,' which is clear and actionable. It does not, however, differentiate itself from the nearby sibling 'bollinger_scan', leaving some ambiguity about which of the two to pick.

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 is essentially a parameter list with no when-to-use guidance, no prerequisites, and no mention of alternatives. A reader cannot tell from this text why they would choose rating_filter over bollinger_scan or another scanner.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely valuable behavioral context beyond them: the data source (Yahoo Finance OHLCV) and the important caveat that these are documented formula variants, NOT actual institutional-flow data — preventing misuse/misinterpretation. It still omits rate limits or cost, so not a 5.

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

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

Front-loaded with purpose, then structured into labeled families and an Args block, so it is scannable. Some formula detail (RSI50/RSI40/RSI14 scaling, EMA(13)-smoothed 34-bar stochastic) is more granular than selection strictly needs, but it aids output interpretation rather than adding pure waste.

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

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

There is no output schema, so the description should convey return shape — and it does, stating each family's range (0-20, 0-100) and the consensus vote. Combined with the source and proxy caveat, an agent has enough to call and interpret it; only concrete field names/response structure are missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so well: it documents all four parameters, gives bare-ticker examples, explains exchange-to-Yahoo suffix mapping (.CA/.IS/.SR, else pass-through), and lists period/interval values with defaults. This fully compensates for the empty schema.

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

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

The description states a specific verb+resource ('Banker/hot-money proxy read for one symbol from price+volume history') and names the exact three indicator families computed. The 'for one symbol' scoping implicitly distinguishes it from scanner siblings like egx_smart_money_scanner, so an agent can route correctly.

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?

Usage is implied by describing what each family measures and how to interpret accumulation, but there is no explicit when-to-use, when-not-to-use, or named-alternative guidance. The agent can infer it's a single-symbol diagnostic but gets no routing rules against the many sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the return type (list[dict]) and the structured error envelope with code/retryable fields, which tells the agent how to react to failure. It does not cover rate limits or exchange availability.

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 purpose is front-loaded in one line, followed by a compact Args block and return note. Every section carries information, though the Args list is somewhat schema-like in form. No filler or repetition.

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

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

For a 5-parameter read-only scanner with an output schema, the description covers purpose, every parameter's meaning, and failure behavior. It does slightly restate return values that the output schema already defines, and it omits which exchanges are valid, but nothing essential for invocation is missing.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden and largely succeeds: it defines min_volume_ratio as a multiplier, min_price_change as a percentage, rsi_range with concrete bucket values (<30/30-70/>70/any), and limit as max 30. Only 'exchange: Exchange name' is left thin, with no list of valid exchanges.

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+resource: a scanner combining volume and technical (RSI) analysis. Combined with the parameter list, an agent can tell it finds volume-spike candidates filtered by RSI state. It never distinguishes itself from the similarly-named sibling volume_breakout_scanner or bollinger_scan, so differentiation is left to inference.

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

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

Usage is only implied through the parameter documentation (volume multiplier, price change %, RSI buckets), which conveys how to tune the scan but not when to choose it over volume_breakout_scanner or combined_analysis. No exclusions, prerequisites, or alternative routing are given.

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

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

Annotations only cover the safety profile (readOnly, non-destructive, open-world); the description adds genuinely non-obvious behavior: post_market is null during the regular session, weekend/holiday calls fall back to the latest print per window, and how the % change is anchored to reference_close vs. the regular close. That is exactly the context an agent needs to interpret a sparse-looking response.

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

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

Front-loaded trigger sentence, then example queries, then behavior and return shape — well ordered and mostly waste-free. The reference_close explanation ('before the open that is newer than previous_close') is dense and takes a re-read, which slightly undercuts clarity.

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

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

With no output schema, the Returns block is necessary and covers the field names, nullability, and change semantics, making the response interpretable. The remaining gap is error behavior for invalid or non-US symbols, which the description silently assumes away.

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 is a bare string with 0% description coverage, so the description must compensate; it does so with concrete accepted forms (AAPL, NVDA, TSLA, SPY, ^GSPC), which clarifies that indices/caret symbols are allowed. It does not say whether exchange-qualified or non-US symbols are rejected.

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

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

States a specific verb/resource pair ('real-time pre-market and after-hours prices for a US stock symbol') and bounds it to the extended session, so an agent can tell it apart from regular-session quote siblings like stock_prices or yahoo_price. It never names those siblings, so the differentiation is implicit rather than explicit.

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

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

Gives a concrete trigger condition ('when the user asks about a stock outside the regular 9:30am-4pm ET session') plus worked example phrasings such as 'what is X doing in after-hours?'. Clear about when to use, but never states the complement — i.e. which tool to reach for during the regular session.

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, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: the nearest-expiry default when no expiry is passed, and the error-plus-valid-dates response when an expiry does not match available_expiries. It omits rate limits or data freshness, hence not a 5.

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

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

Front-loaded with the one-line purpose, followed by usage triggers, Args, and Returns in clearly labeled blocks. The length is justified by the fact that there is no output schema, so the return-field enumeration must live here. No filler sentences.

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, no param descriptions, and no enums, the description compensates fully: it documents both parameters, the default/error behavior, and the exact shape of the returned calls/puts objects plus counts and underlying price. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 0%, so the description must carry the load and it does: symbol is defined as a US stock symbol with examples (AAPL, NVDA, TSLA, SPY), and expiry is defined as an optional ISO date (YYYY-MM-DD) that must match one of available_expiries. Both parameters are fully disambiguated beyond the bare schema 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?

States a specific verb and resource ('Full options chain (calls + puts)') scoped to a US stock symbol and a single expiry. This clearly distinguishes it from the sibling stock_options_unusual_activity, which serves a different purpose. An agent can identify it without opening the schema.

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

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

Gives concrete user-phrasing triggers ('what's the options chain for X?', 'show me AAPL puts expiring next Friday') and describes the no-expiry fallback (returns nearest expiry and asks the user). It does not name a distinguishing alternative like stock_options_unusual_activity, so it stops short of a full when-not/alternatives 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds real context beyond them: it scans only the soonest few expirations, filters strikes below min_volume, and returns sorted-by-V/OI results. It doesn't mention rate limits or latency, but the operational behavior is well disclosed.

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

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

Front-loaded with the core concept (V/OI ratio) and usage before the Args and Returns blocks. It is somewhat long, but the sectioning makes every line scannable and functionally useful, with little redundancy.

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

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

There is no output schema, but the description compensates with a detailed Returns block enumerating underlying_price, expiries_scanned, aggregate volumes, put_call_volume_ratio, and each contract field including moneyness. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 0%, so the description carries the full burden, and it does: symbol is defined as a US stock ticker with examples, top_n and expiries have their defaults and meaning explained, and min_volume is explained as a noise filter for illiquid strikes. Every parameter gains meaning 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?

States a specific resource and metric ('Top strikes by volume / open-interest ratio') rather than a vague 'options data' claim, and clarifies it is a positioning signal. An agent can distinguish it from the sibling stock_options_chain, which returns 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?

Gives explicit trigger phrasing ('any unusual options activity on X?', 'where is the smart money positioned...') and the use case (a V/OI screener). It stops short of naming the alternative tool (stock_options_chain) or stating when NOT to use it, so it is clear but not fully routing.

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

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

Annotations already cover readOnly/openWorld/non-destructive, so the bar is lower, and the description adds real operational context: a 2000-ticker ceiling, the fact that a full-size call is still one upstream request, the exchange-prefix requirement, and a not_found list for unrecognized tickers. That goes meaningfully beyond the annotation set, though it omits rate limits or update latency.

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

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

Front-loaded one-line summary followed by Args and Returns sections; every block carries information. The Args/Returns formatting is slightly heavier than the payload needs, but nothing is wasted.

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

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

No output schema exists, yet the description enumerates the return envelope fields (ticker, symbol, description, exchange, price, open, high, low, currency, change_percent) and the not_found list. Combined with the parameter detail, an agent has everything needed to call and consume the result.

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

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

Schema coverage is 0%, so the description carries the full burden and does so well: it specifies comma-separated EXCHANGE:SYMBOL syntax, gives a concrete example, states the 2000 max, and warns that the exchange prefix is mandatory because lookup is exchange-scoped. Essentially nothing about the single parameter is left ambiguous.

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

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

States a specific verb+resource+scope: 'Current price + daily % change for specific stock symbols.' The multi-symbol, exchange-scoped nature distinguishes it somewhat from single-ticker siblings like yahoo_price or price_chart, but those siblings are never named, so the agent must infer the boundary. Clear purpose, no explicit 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?

Implies usage via 'specific stock symbols' and the required EXCHANGE:SYMBOL format, which signals this is a direct lookup rather than a scan. However, it never says when to prefer this over yahoo_price, market_snapshot, or price_chart, and offers no exclusions or prerequisites beyond the format.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing ranking behavior (market-cap descending), the single-upstream-request/2000-row cap, the OTC-exclusion default and its interpretation nuance, local-currency pricing, and that open/high/low are the current session's daily bar. These are exactly the operational traits an agent needs and none are derivable from the structured fields.

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

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

Well-structured with front-loaded purpose followed by Args and Returns sections; each entry carries real information. It runs long and includes some editorializing (the TradingView twin framing, the market-cap caveat) that could be tightened, but nothing is truly wasted.

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 supplies the return envelope (total_matches, returned, rows) and every row field including currency and price-timeframe semantics. Combined with the fully documented args, an agent has everything needed to call and interpret the tool without further discovery.

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 carry the full param burden, and it does: country examples, stock_type allowed values (common|preferred), limit max and ranking, exclude_otc default and semantics, compact payload contents, and sort_by allowed values with their whole-market sort meaning. Essentially every parameter is fully specified with behavior the bare schema omits.

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

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

States a specific verb+resource ('Screen stocks by share type') and frames the exact semantic scope via the TradingView 'Common stock'/'Preferred stock' analogy, so an agent immediately knows what it selects. The multi-country list in the args clarifies it is a global screener despite the 'US Stock Screener' title, which sharpens rather than muddies the purpose. It is distinguishable from the Egypt-specific sibling egx_stock_screener by the country semantics, even without naming it.

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

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

Gives clear usage context: compact=True is for 'bulk price feeds', sort_by=dividend_yield with limit=20 yields the market's true top-20 payers, and exclude_otc clarifies that 'america' means US venue not US company. It does not, however, name any sibling or state when to prefer an alternative (e.g., egx_stock_screener vs this tool), so no explicit exclusions or routing 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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful framing (incremental typeahead, which venues are searched, EXCHANGE:SYMBOL result shape) but omits matching semantics such as prefix vs. substring and empty-query 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?

A single tight sentence that front-loads the core purpose and then scopes the exchange coverage and return format. 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?

An output schema exists, so return-value documentation is unnecessary, and annotations cover the safety profile. What remains missing is the typeahead matching contract (what an empty or no-match query yields), which matters for correct invocation of a search-style 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 single 'query' parameter has 0% schema description, so the description must carry the weight. 'Typeahead search' implies the query is the partial string to match, but it adds no detail on format, minimum length, or how the empty default is handled. Partial compensation for the coverage 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 gives a specific verb (typeahead search) and resource (tickers / @-mention symbols), plus the exact output format (EXCHANGE:SYMBOL) and covered exchanges (NASDAQ, NYSE, BIST, Binance). That clearly separates it from the surrounding analysis/scanner siblings. It stops short of 5 only because it does not name any sibling it might be confused with.

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?

Usage is implied by 'Typeahead search for @-mentions', suggesting it is meant to resolve a partial symbol as a user types. There is no explicit when-to-use vs. alternative, and no stated preconditions or exclusions. Adequate but relies on inference.

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

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

Annotations cover the safety profile (readOnly, non-destructive, openWorld), and the description adds useful behavioral detail: success returns list[dict], failures return a structured error envelope with code and retryable, and limit max is 50. It does not mention rate limits or auth, but the added error contract is 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?

Front-loads the purpose in the first sentence, then uses clear Args and Returns sections. The long exchange list is necessary given zero schema coverage, so no sentence is wasted.

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 annotations covering safety and an output schema present, the description fills the parameter gap and documents error behavior. It omits usage routing relative to sibling screeners, leaving a minor gap for an agent deciding between similar tools.

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 lists concrete allowed exchange values, timeframe options, and the limit maximum (50). This compensates completely for the bare schema and goes beyond it.

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

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

States a specific verb and resource ('Return top gainers') and scopes it to an exchange and timeframe, with a method (Bollinger Band analysis). It does not explicitly differentiate itself from many sibling scanners like bollinger_scan or volume_breakout_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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as top_losers or other screeners. The agent must infer usage solely from the tool name.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: it declares the success type (list[dict]) and, more valuably, that ANY failure returns a structured error envelope with code and retryable fields, telling the agent how to branch on failure.

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

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

Two short sentences, purpose front-loaded, then the return/error contract. No filler, though the success-type sentence is partly redundant against the existing output schema.

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

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

For a read-only, fully-defaulted 3-param screener with an output schema, the description covers purpose, valid venues, and error behavior adequately. The remaining gap is that timeframe and limit semantics are undocumented anywhere.

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% for all three parameters, so the description carries the burden. It partially compensates by enumerating valid exchange values (KUCOIN, BINANCE, MEXC, EGX, BIST, NASDAQ), which meaningfully constrains the 'exchange' param, but 'limit' and 'timeframe' (and their accepted formats/defaults of 25 and 15m) are left entirely unexplained.

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

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

The description states a specific verb and resource ('Return top losers for an exchange and timeframe'), which an agent can immediately distinguish from siblings like top_gainers or stock_screener. It stops short of explicitly naming a sibling it is not, so it lands at clear-but-not-differentiating.

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

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

It tells the agent which venues are valid (crypto vs stocks) but gives no when-to-use guidance, no comparison against top_gainers or the many screener siblings, and no prerequisites. The agent must infer selection criteria entirely from the tool name.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful semantics beyond that: the empty list strictly means 'no matches today,' total upstream failure returns an error envelope (ALL_BATCHES_FAILED), and rate-limit cliffs surface explicitly rather than silently.

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

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

Front-loaded with the purpose, followed by a clean Args list and a returns note; every element maps to something an agent needs. The trailing sentence about rate-limit cliffs is slightly verbose but earns its place by clarifying error behavior.

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

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

With an output schema present, the description needn't detail return shapes, yet it usefully clarifies the empty-list-vs-error distinction. Parameter documentation is complete enough to invoke correctly; the remaining gap is the absence of any usage guidance relative to the many sibling scanners.

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 parameter burden and largely does: it explains exchange examples, enumerates the valid timeframes, defines volume_multiplier as a multiple of normal volume, defines price_change_min as a percentage, and caps limit at 50. It omits the limit default (25) and gives no guidance on tuning thresholds, keeping it short of a 5.

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

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

The description opens with a specific verb and resource: 'Detect coins with volume breakout + price breakout,' which tells an agent exactly what the tool produces. It does not, however, differentiate itself from close siblings like smart_volume_scanner or volume_confirmation_analysis, so an agent cannot resolve the overlap from the text alone.

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?

There is no statement of when to use this tool, when not to, or which sibling to prefer for adjacent volume/breakout analysis. The Args block documents inputs but gives no usage context or prerequisites, leaving routing entirely to inference.

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, destructiveHint=false, and openWorldHint=true, so safety is covered structurally. The description adds nothing beyond that: it does not explain what 'volume confirmation' means, what the analysis returns, or that results depend on the chosen exchange/timeframe. For a read-only tool this is a thin but not contradictory 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?

Very short and front-loaded, with the purpose stated before the argument list. The 'Args:' block is docstring leakage, but given 0% schema description coverage it does carry some useful parameter glosses rather than pure waste.

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

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

For a three-parameter analysis tool with no output schema and no annotation caveats, the description is under-specified: it never defines the analysis, the valid timeframe/exchange domains, or what a caller gets back. An agent can guess at invocation but not at semantics.

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, yet it only restates parameter names with one-word glosses ('Exchange name', 'Time frame for analysis') plus a single example (BTCUSDT). It omits the defaults KUCOIN and 15m and gives no allowed timeframe values, leaving key invocation details undocumented.

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

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

States a specific verb+resource: 'volume confirmation analysis for a specific coin.' It is clear what the tool does, but it offers no differentiation from close siblings such as volume_breakout_scanner, smart_volume_scanner, or combined_analysis, so an agent cannot tell which volume tool to pick without opening schemas.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternatives. The description never tells the agent when this analysis is preferable to the many other volume/analysis tools in the sibling list.

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

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

Annotations already declare the safe read-only, non-destructive profile, so the bar is lower. The description adds real behavioral context beyond that: the fold/train-test methodology implied by overfitting detection, the SMA200 warmup constraint that excludes rsi_pullback and triple_ema, and the n_splits max of 10. It does not describe runtime cost or the shape of results, but the added methodology is substantive.

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

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

Front-loaded with the one-line purpose, then a clean Args block; no filler sentences. The block is long, but every line documents a parameter that the schema leaves completely undescribed, so the length is earned rather than padded.

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

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

For a 9-parameter, no-annotation-detail tool the description covers invocation fully. The one gap is that with no output schema, it never says what a walk-forward run returns (per-fold metrics, summary), which an agent would want before calling. Otherwise 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%, so the description carries the full burden and does: it enumerates all nine parameters with semantics, accepted strategy/period/interval values, defaults, and units (USD, %, fraction). It goes further with actionable guidance such as the '2y' recommendation and the per-fold capital interpretation.

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 opening line states a specific verb and resource ('walk-forward backtest') and immediately names the distinguishing purpose: detecting overfitting by validating on unseen data. This separates it cleanly from plain backtest_strategy/run_backtest siblings without opening either schema.

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

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

Gives concrete routing advice for unsupported strategies ('use run_backtest with period="2y"') and recommends period='2y'. It does not, however, state when an agent should prefer a walk-forward backtest over a simpler backtest_strategy or compare_strategies call, so the guidance is strong on exclusions but incomplete on positive selection.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false. The description adds genuine context beyond them: server-side storage that follows the API key, a 50-symbol limit, and that mixed asset classes are permitted. What happens when the cap is exceeded (error vs. truncation) is left unstated.

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

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

Two tight sentences; the core action leads, followed by the constraints and format. No filler, every clause carries operational information (storage model, limit, syntax, examples, mixing rule).

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

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

For a single-parameter tool with no output schema and annotations covering the safety profile, the description covers action, persistence, limit and input format. The only meaningful omission is behavior at the 50-symbol ceiling, which an agent may need to set expectations.

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

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

Schema coverage is 100% and the schema already says 'comma-separated EXCHANGE:SYMBOL list', so baseline is 3. The description rises above it by supplying concrete format examples across exchanges and explicitly noting that crypto, stocks, futures and FX can be mixed in one list, which removes real ambiguity in constructing the value.

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

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

States a specific verb (add) and resource (user's personal watchlist), and the scope is unambiguous against siblings like watchlist_remove and my_watchlist. An agent can distinguish this from the read/remove siblings without opening any schema.

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

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

Gives clear operating context: server-side persistence tied to the API key across MCP clients, and a hard cap of 50 symbols. It does not explicitly name when to prefer it over siblings (e.g. my_watchlist for reading, watchlist_remove for deletion), but the add semantics make the alternative 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 idempotentHint=true and destructiveHint=false; the description reinforces this with an explicit reversibility statement, which is useful reassurance for a mutation tool. It does not disclose what happens when a symbol is not present on the list, nor the response shape.

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

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

Three tight sentences: purpose first, format requirement second, reversibility last. Every sentence carries information; nothing is padding.

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

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

For a single-parameter, non-destructive, idempotent mutation with full schema coverage and annotations, the description supplies everything needed: what it does, exact input format, and recovery path. No output schema exists, so return values need not be described.

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

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

Schema coverage is 100% and the schema already names the parameter, but the description goes beyond it with the exact EXCHANGE:SYMBOL grammar and four concrete multi-exchange examples (crypto, equities, Turkish, futures), which materially reduce the chance of malformed input.

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

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

Specific verb (Remove) plus resource (symbols from the user's personal watchlist), and it is trivially distinguishable from the sibling watchlist_add. No ambiguity about what the tool operates on.

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

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

States the operation clearly and notes reversibility ('just add again'), which implicitly routes the agent to watchlist_add for the inverse action. It stops short of an explicit 'use watchlist_add to add symbols' pointer or any preconditions (e.g. symbol must already exist in the list).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety and external-data profile is covered by structured fields. The description usefully notes the data is 'real-time' and comes from Yahoo Finance, but says nothing about latency, rate limits, market-hours behavior, or whether a failed symbol returns an error.

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

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

The core purpose is front-loaded in one sentence, and the Args block is compact with no filler. The docstring-style formatting is slightly redundant for an MCP description but costs little.

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

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

With no output schema, the description carries the burden of explaining what a 'price quote' returns (last price, change, timestamp, currency?), and it does not. Symbol input is well covered, but the agent cannot predict the shape of the result.

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

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

Schema description coverage is 0% — the 'symbol' property has no description in the schema — so the description must carry the load, and it does: it gives concrete format examples across asset classes (AAPL, BTC-USD, SPY, ^GSPC, EURUSD=X, THYAO.IS). This is genuinely valuable disambiguation for exotic symbol syntax. It does not state case sensitivity or whether exchange suffixes are required in all cases, so it falls short of 5.

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

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

The description states a specific verb and resource ('Real-time price quote from Yahoo Finance') and enumerates the asset classes covered (stock, crypto, ETF, index), which helps separate it from narrow siblings like stock_prices or egx_index_analysis. It stops short of naming a specific sibling it replaces, so it lands at 4 rather than 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?

There is no guidance on when to prefer this tool over alternatives such as stock_prices, market_snapshot, or price_chart, nor any stated exclusions or prerequisites. The agent must infer usage from the name alone.

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